[lxc-devel] [lxd/master] doc/storage: Typo and example fix

stgraber on Github lxc-bot at linuxcontainers.org
Fri Sep 6 18:26:21 UTC 2019

A non-text attachment was scrubbed...
Name: not available
Type: text/x-mailbox
Size: 370 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20190906/ae35df12/attachment.bin>
-------------- next part --------------
From 24b63d7c37c3d275f431e669542613470ed458f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?St=C3=A9phane=20Graber?= <stgraber at ubuntu.com>
Date: Fri, 6 Sep 2019 14:25:39 -0400
Subject: [PATCH] doc/storage: Typo and example fix
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Closes #6163

Signed-off-by: St├ęphane Graber <stgraber at ubuntu.com>
 doc/storage.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/storage.md b/doc/storage.md
index 505c5c60f8..ec13e5a3ab 100644
--- a/doc/storage.md
+++ b/doc/storage.md
@@ -80,7 +80,7 @@ The two best options for use with LXD are ZFS and btrfs.
 They have about similar functionalities but ZFS is more reliable if available on your particular platform.
 Whenever possible, you should dedicate a full disk or partition to your LXD storage pool.  
-While LXD will let you create loop based storage, this isn't a recommended for production use.
+While LXD will let you create loop based storage, this isn't recommended for production use.
 Similarly, the directory backend is to be considered as a last resort option.  
 It does support all main LXD features, but is terribly slow and inefficient as it can't perform  
@@ -256,7 +256,7 @@ lxc storage create pool1 ceph source=my-already-existing-osd
 lxc storage create pool1 btrfs
- - Create a btrfs subvolume named "pool1" on the btrfs filesystem `/some/path` and use as pool.
+ - Create a new pool called "pool1" using an existing btrfs filesystem at `/some/path`.
 lxc storage create pool1 btrfs source=/some/path

More information about the lxc-devel mailing list