btrfs-progs: Remove btrfs-debug-tree command

[platform/upstream/btrfs-progs.git] / Documentation / btrfs-receive.asciidoc

diff --git a/Documentation/btrfs-receive.asciidoc b/Documentation/btrfs-receive.asciidoc
index 822b268..cbd88e6 100644 (file)
--- a/Documentation/btrfs-receive.asciidoc
+++ b/Documentation/btrfs-receive.asciidoc
@@ -31,7 +31,7 @@ the stream, and print the stream metadata, one operation per line.
 
 3. default subvolume has changed or you didn't mount the filesystem at the toplevel subvolume
 
-A subvolume is made read-only after the receiving process finishes succesfully (see BUGS below).
+A subvolume is made read-only after the receiving process finishes successfully (see BUGS below).
 
 `Options`
 
@@ -66,7 +66,7 @@ tell us where this filesystem is mounted.
 --dump::
 dump the stream metadata, one line per operation
 +
-Does not require the 'path' parameter. The filesystem chanded.
+Does not require the 'path' parameter. The filesystem remains unchanged.
 
 BUGS
 ----
@@ -81,7 +81,7 @@ should be protected from access by users until the receive operation
 has completed and the subvolume is set to read-only.
 
 Additionally, receive does not currently do a very good job of validating
-that an incremental send streams actually makes sense, and it is thus
+that an incremental send stream actually makes sense, and it is thus
 possible for a specially crafted send stream to create a subvolume with
 reflinks to arbitrary files in the same filesystem.  Because of this,
 users are advised to not use *btrfs receive* on send streams from