[PATCH 1/1] btrfs-progs: docs: annual typo, clarity, & grammar review & fixups

[Nicholas D Steeves]

In one big patch, as requested

Signed-off-by: Nicholas D Steeves 
---
 Documentation/btrfs-balance.asciidoc  | 12 -
 Documentation/btrfs-check.asciidoc| 17 ++---
 Documentation/btrfs-convert.asciidoc  | 21 
 Documentation/btrfs-device.asciidoc   |  6 ++---
 Documentation/btrfs-filesystem.asciidoc   | 18 +++---
 Documentation/btrfs-find-root.asciidoc|  2 +-
 Documentation/btrfs-inspect-internal.asciidoc |  8 +++---
 Documentation/btrfs-man5.asciidoc | 36 ++-
 Documentation/btrfs-map-logical.asciidoc  |  2 +-
 Documentation/btrfs-qgroup.asciidoc   |  8 +++---
 Documentation/btrfs-quota.asciidoc| 18 +++---
 Documentation/btrfs-receive.asciidoc  |  2 +-
 Documentation/btrfs-replace.asciidoc  |  6 ++---
 Documentation/btrfs-rescue.asciidoc   |  2 +-
 Documentation/btrfs-scrub.asciidoc|  4 +--
 Documentation/btrfs-send.asciidoc | 11 
 Documentation/btrfs-subvolume.asciidoc| 15 +--
 Documentation/btrfs.asciidoc  | 14 +--
 Documentation/btrfstune.asciidoc  | 13 +-
 Documentation/fsck.btrfs.asciidoc |  8 +++---
 Documentation/mkfs.btrfs.asciidoc | 10 
 21 files changed, 119 insertions(+), 114 deletions(-)

diff --git a/Documentation/btrfs-balance.asciidoc 
b/Documentation/btrfs-balance.asciidoc
index cc81de91..f471be3b 100644
--- a/Documentation/btrfs-balance.asciidoc
+++ b/Documentation/btrfs-balance.asciidoc
@@ -21,7 +21,7 @@ filesystem.
 The balance operation is cancellable by the user. The on-disk state of the
 filesystem is always consistent so an unexpected interruption (eg. system 
crash,
 reboot) does not corrupt the filesystem. The progress of the balance operation
-is temporarily stored and will be resumed upon mount, unless the mount option
+is temporarily stored (EDIT: where is it stored?) and will be resumed 
upon mount, unless the mount option
 'skip_balance' is specified.
 
 WARNING: running balance without filters will take a lot of time as it 
basically
@@ -200,11 +200,11 @@ section 'PROFILES'.
 ENOSPC
 --
 
-The way balance operates, it usually needs to temporarily create a new block
+The way balance operates, it usually needs to temporarily create a new 
block
 group and move the old data there. For that it needs work space, otherwise
 it fails for ENOSPC reasons.
 This is not the same ENOSPC as if the free space is exhausted. This refers to
-the space on the level of block groups.
+the space on the level of block groups. (EDIT: What is the relationship 
between the new block group and the work space?  Is the "old data" removed from 
the new block group?  Please say something about block groups to clarify)
 
 The free work space can be calculated from the output of the *btrfs filesystem 
show*
 command:
@@ -227,7 +227,7 @@ space. After that it might be possible to run other filters.
 
 Conversion to profiles based on striping (RAID0, RAID5/6) require the work
 space on each device. An interrupted balance may leave partially filled block
-groups that might consume the work space.
+groups that might (EDIT: is this 2nd level of uncertainty necessary?) 
consume the work space.
 
 EXAMPLES
 
@@ -238,7 +238,7 @@ can be found in section 'TYPICAL USECASES' of 
`btrfs-device`(8).
 MAKING BLOCK GROUP LAYOUT MORE COMPACT
 ~~
 
-The layout of block groups is not normally visible, most tools report only
+The layout of block groups is not normally visible; most tools report only
 summarized numbers of free or used space, but there are still some hints
 provided.
 
@@ -298,7 +298,7 @@ data to the remaining blockgroups, ie. the 6GiB are now 
free of filesystem
 structures, and can be reused for new data or metadata block groups.
 
 We can do a similar exercise with the metadata block groups, but this should
-not be typically necessary, unless the used/total ration is really off. Here
+not typically be necessary, unless the used/total ratio is really off. Here
 the ratio is roughly 50% but the difference as an absolute number is "a few
 gigabytes", which can be considered normal for a workload with snapshots or
 reflinks updated frequently.
diff --git a/Documentation/btrfs-check.asciidoc 
b/Documentation/btrfs-check.asciidoc
index fbf48847..b9f8bd60 100644
--- a/Documentation/btrfs-check.asciidoc
+++ b/Documentation/btrfs-check.asciidoc
@@ -22,10 +22,10 @@ by the option '--readonly'.
 
 *btrfsck* is an alias of *btrfs check* command and is now deprecated.
 
-WARNING: Do not use '--repair' unless you are advised to by a developer, an
-experienced user or accept the fact that 'fsck' cannot possibly fix all sorts
-of damage that could happen to a filesystem because of software and hardware
-bugs.
+WARNING: Do not use 

[PATCH 0/1] btrfs-progs: docs: annual typo, clarity, & grammar review & fixups

[Nicholas D Steeves]

Hi David,

I've marked the parts the require review like this: This paragraph
explains something but something is opaque (EDIT: reason why
it's unclear or needs to be updated).  Here is what I found this
year (@664dbbff6e72ffbdeb451b4f03f98dab3eabb1d1):

Nicholas D Steeves (1):
  btrfs-progs: docs: annual typo, clarity, & grammar review & fixups

 Documentation/btrfs-balance.asciidoc  | 12 -
 Documentation/btrfs-check.asciidoc| 17 ++---
 Documentation/btrfs-convert.asciidoc  | 21 
 Documentation/btrfs-device.asciidoc   |  6 ++---
 Documentation/btrfs-filesystem.asciidoc   | 18 +++---
 Documentation/btrfs-find-root.asciidoc|  2 +-
 Documentation/btrfs-inspect-internal.asciidoc |  8 +++---
 Documentation/btrfs-man5.asciidoc | 36 ++-
 Documentation/btrfs-map-logical.asciidoc  |  2 +-
 Documentation/btrfs-qgroup.asciidoc   |  8 +++---
 Documentation/btrfs-quota.asciidoc| 18 +++---
 Documentation/btrfs-receive.asciidoc  |  2 +-
 Documentation/btrfs-replace.asciidoc  |  6 ++---
 Documentation/btrfs-rescue.asciidoc   |  2 +-
 Documentation/btrfs-scrub.asciidoc|  4 +--
 Documentation/btrfs-send.asciidoc | 11 
 Documentation/btrfs-subvolume.asciidoc| 15 +--
 Documentation/btrfs.asciidoc  | 14 +--
 Documentation/btrfstune.asciidoc  | 13 +-
 Documentation/fsck.btrfs.asciidoc |  8 +++---
 Documentation/mkfs.btrfs.asciidoc | 10 
 21 files changed, 119 insertions(+), 114 deletions(-)

-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SLES 11 SP4: can't mount btrfs

[Adam Borowski]

On Sat, Oct 21, 2017 at 01:46:06PM +0200, Lentes, Bernd wrote:
> - Am 21. Okt 2017 um 4:31 schrieb Duncan 1i5t5.dun...@cox.net:
> > Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted:
> > 
> >> Is it generally possible to restore a btrfs partition from a tape backup
> >> ?
> >> I'm just starting, and I'm asking myself. What is about the subvolumes ?
> >> This information isn't stored in files, but in the fs ? This is not on a
> >> file-based backup on a tape.
> > 
> > Yes it's possible to restore a btrfs partition from tape backup, /if/ you
> > backed up the partition itself, not just the files on top of it.

Which is usually a quite bad idea: unless you shut down (or remount ro) the
filesystem in question, the data _will_ be corrupted, and in the case of
btrfs, this kind of corruption tends to be fatal.  You also back up all the
unused space (trim greatly recommended), and the backup process takes ages
as it needs to read everything.

An efficient block-level backup of btrfs _would_ be possible as it can
nicely enumerate blocks touched since generation X, but AFAIK no one wrote
such a program yet.  It'd be also corruption free if done in two passes:
first a racey copy, fsfreeze(), copy of just newest updates.

> > Otherwise, as you deduce, you get the files, but not the snapshot history
> > or relationship, nor the subvolumes, which will look to normal file-level
> > backup software (that is, backup software not designed with btrfs-
> > specifics like subvolumes, which if it did, would likely use btrfs send/
> > receive at least optionally) like normal directories.

If the backup software does incrementals well, this is not as bad as it
sounds.  While rsync takes half an hour just to stat() a typical small piece
spinning rust (obviously depending on # of files), that's still in the
acceptable range.  That backup software can be then be told to back every
snapshot in turn.  You still lose reflinks between unrelated subvolumes but
those tend to be quite rare -- and you can re-dedupe.

> i apprehend that i have just a file based backup.  We use EMC Networker
> (version 8.1 or 8.2), and from what i read in the net i think it does not
> support BTRFS.  So i have to reinstall, which is maybe not the worst,
> because i'm thinking about using SLES 11 SP3.
> 
> What i know now is that i can't rely on our EMC backup.
> What would you propose to backup a complete btrfs partition
> (https://btrfs.wiki.kernel.org/index.php/Incremental_Backup) ?
> We have a NAS with propable enough space, and the servers aren't used
> heavily over night.  So using one of the mentioned tools in a cronjob over
> night is possible.

> Which tool do you recommend ?

It depends on what you use subvolumes for.

While a simple file-base backup may be inadequate for the general case, for
most actual uses it works well or at least well enough.  Only if you're
doing something special, bothering with the complexity might be worth it.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. 
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] btrfs: avoid misleading talk about "compression level 0"

[Adam Borowski]

Many compressors do assign a meaning to level 0: either null compression or
the lowest possible level.  This differs from our "unset thus default".
Thus, let's not unnecessarily confuse users.

Signed-off-by: Adam Borowski 
---
 fs/btrfs/super.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index f9d4522336db..144fabfbd246 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -551,7 +551,9 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char 
*options,
  compress_force != saved_compress_force)) ||
(!btrfs_test_opt(info, COMPRESS) &&
 no_compress == 1)) {
-   btrfs_info(info, "%s %s compression, level %d",
+   btrfs_printk(info, info->compress_level ?
+  KERN_INFO"%s %s compression, level 
%d" :
+  KERN_INFO"%s %s compression",
   (compress_force) ? "force" : "use",
   compress_type, info->compress_level);
}
-- 
2.15.0.rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SLES 11 SP4: can't mount btrfs

[Lentes, Bernd]

- Am 21. Okt 2017 um 4:31 schrieb Duncan 1i5t5.dun...@cox.net:

> Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted:
> 
>> Is it generally possible to restore a btrfs partition from a tape backup
>> ?
>> I'm just starting, and I'm asking myself. What is about the subvolumes ?
>> This information isn't stored in files, but in the fs ? This is not on a
>> file-based backup on a tape.
> 
> Yes it's possible to restore a btrfs partition from tape backup, /if/ you
> backed up the partition itself, not just the files on top of it.
> 
> Otherwise, as you deduce, you get the files, but not the snapshot history
> or relationship, nor the subvolumes, which will look to normal file-level
> backup software (that is, backup software not designed with btrfs-
> specifics like subvolumes, which if it did, would likely use btrfs send/
> receive at least optionally) like normal directories.
> 
> --

Hi Duncan,

i apprehend that i have just a file based backup. We use EMC Networker (version 
8.1 or 8.2), and from what i read in the net i think it
does not support BTRFS. So i have to reinstall, which is maybe not the worst, 
because i'm thinking about using SLES 11 SP3.

What i know now is that i can't rely on our EMC backup.
What would you propose to backup a complete btrfs partition 
(https://btrfs.wiki.kernel.org/index.php/Incremental_Backup) ?
We have a NAS with propable enough space, and the servers aren't used heavily 
over night. So using one of the mentioned tools in a cronjob over night is 
possible.
Which tool do you recommend ?

Bernd

 

Helmholtz Zentrum Muenchen
Deutsches Forschungszentrum fuer Gesundheit und Umwelt (GmbH)
Ingolstaedter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrer: Prof. Dr. Guenther Wess, Heinrich Bassler, Dr. Alfons Enhsen
Registergericht: Amtsgericht Muenchen HRB 6466
USt-IdNr: DE 129521671

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Btrfs: remove redundant btrfs_balance_delayed_items

[Nikolay Borisov]

On 21.10.2017 02:53, Liu Bo wrote:
> In functions like btrfs_create(), we run both
> btrfs_balance_delayed_items() and btrfs_btree_balance_dirty() after
> the operation, but btrfs_btree_balance_dirty() is surely going to run
> btrfs_balance_delayed_items().
> 
> This keeps only btrfs_btree_balance_dirty().

Reviewed-by: Nikolay Borisov 

> 
> Signed-off-by: Liu Bo 
> ---
>  fs/btrfs/inode.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index 1bd9f01..da57b03 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -6599,7 +6599,6 @@ static int btrfs_mknod(struct inode *dir, struct dentry 
> *dentry,
>  
>  out_unlock:
>   btrfs_end_transaction(trans);
> - btrfs_balance_delayed_items(fs_info);
>   btrfs_btree_balance_dirty(fs_info);
>   if (drop_inode) {
>   inode_dec_link_count(inode);
> @@ -6680,7 +6679,6 @@ static int btrfs_create(struct inode *dir, struct 
> dentry *dentry,
>   inode_dec_link_count(inode);
>   iput(inode);
>   }
> - btrfs_balance_delayed_items(fs_info);
>   btrfs_btree_balance_dirty(fs_info);
>   return err;
>  
> @@ -6755,7 +6753,6 @@ static int btrfs_link(struct dentry *old_dentry, struct 
> inode *dir,
>   btrfs_log_new_name(trans, BTRFS_I(inode), NULL, parent);
>   }
>  
> - btrfs_balance_delayed_items(fs_info);
>  fail:
>   if (trans)
>   btrfs_end_transaction(trans);
> @@ -6833,7 +6830,6 @@ static int btrfs_mkdir(struct inode *dir, struct dentry 
> *dentry, umode_t mode)
>   inode_dec_link_count(inode);
>   iput(inode);
>   }
> - btrfs_balance_delayed_items(fs_info);
>   btrfs_btree_balance_dirty(fs_info);
>   return err;
>  
> @@ -10757,7 +10753,6 @@ static int btrfs_tmpfile(struct inode *dir, struct 
> dentry *dentry, umode_t mode)
>   btrfs_end_transaction(trans);
>   if (ret)
>   iput(inode);
> - btrfs_balance_delayed_items(fs_info);
>   btrfs_btree_balance_dirty(fs_info);
>   return ret;
>  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Btrfs: remove redundant btrfs_balance_delayed_items

[Lu Fengqi]

On Fri, Oct 20, 2017 at 05:53:41PM -0600, Liu Bo wrote:
>In functions like btrfs_create(), we run both
>btrfs_balance_delayed_items() and btrfs_btree_balance_dirty() after
>the operation, but btrfs_btree_balance_dirty() is surely going to run
>btrfs_balance_delayed_items().
>
>This keeps only btrfs_btree_balance_dirty().

Reviewed-by: Lu Fengqi 

-- 
Thanks,
Lu

>
>Signed-off-by: Liu Bo 
>---
> fs/btrfs/inode.c | 5 -
> 1 file changed, 5 deletions(-)
>
>diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
>index 1bd9f01..da57b03 100644
>--- a/fs/btrfs/inode.c
>+++ b/fs/btrfs/inode.c
>@@ -6599,7 +6599,6 @@ static int btrfs_mknod(struct inode *dir, struct dentry 
>*dentry,
> 
> out_unlock:
>   btrfs_end_transaction(trans);
>-  btrfs_balance_delayed_items(fs_info);
>   btrfs_btree_balance_dirty(fs_info);
>   if (drop_inode) {
>   inode_dec_link_count(inode);
>@@ -6680,7 +6679,6 @@ static int btrfs_create(struct inode *dir, struct dentry 
>*dentry,
>   inode_dec_link_count(inode);
>   iput(inode);
>   }
>-  btrfs_balance_delayed_items(fs_info);
>   btrfs_btree_balance_dirty(fs_info);
>   return err;
> 
>@@ -6755,7 +6753,6 @@ static int btrfs_link(struct dentry *old_dentry, struct 
>inode *dir,
>   btrfs_log_new_name(trans, BTRFS_I(inode), NULL, parent);
>   }
> 
>-  btrfs_balance_delayed_items(fs_info);
> fail:
>   if (trans)
>   btrfs_end_transaction(trans);
>@@ -6833,7 +6830,6 @@ static int btrfs_mkdir(struct inode *dir, struct dentry 
>*dentry, umode_t mode)
>   inode_dec_link_count(inode);
>   iput(inode);
>   }
>-  btrfs_balance_delayed_items(fs_info);
>   btrfs_btree_balance_dirty(fs_info);
>   return err;
> 
>@@ -10757,7 +10753,6 @@ static int btrfs_tmpfile(struct inode *dir, struct 
>dentry *dentry, umode_t mode)
>   btrfs_end_transaction(trans);
>   if (ret)
>   iput(inode);
>-  btrfs_balance_delayed_items(fs_info);
>   btrfs_btree_balance_dirty(fs_info);
>   return ret;
> 
>-- 
>2.9.4
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html