Kernel clear_cache mount option will only rebuild free space cache if
the used space of that chunk has changed.
So it won't ensure any corrupted free space cache get cleared.
So add a new option "--clear-space-cache v1|v2" to btrfsck, to
completely wipe out free space cache.
So kernel won't complain again.
Reported-by: Ivan P <chrnosphered@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
[ adjusted error messages, doc wording changes ]
Signed-off-by: David Sterba <dsterba@suse.com>
Quite a common sense for any RAID-like multi-device setup, just in case.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
For RAID5, 2 devices setup is just RAID1 with more overhead.
For RAID6, 3 devices setup is RAID1 with 3 copies, not what most user
want.
So warn user at mkfs time for such case, and add explain in man pages.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Some tools (check, select-super, dump-super) can use the alternate
superblocks, but the options are not consistent. To make it less
confusing, change the meaning of option -s in 'dump-super' to specify
the superblock copy, instead of taking the offset.
Though this is a change in UI, the old usage is detected and the result
would be the same, no breakage in existing scripts.
Signed-off-by: David Sterba <dsterba@suse.com>
Change the single-purpose option --low-memory to a generic option that
takes the mode. Currently supported are the original mode and the
low-memory in the same way.
Signed-off-by: David Sterba <dsterba@suse.com>
Introduce a new fsck mode: low memory mode.
Old btrfsck is working efficiently but uses some memory for each extent
item. This method will ensure extents are only iterated once at
extent/chunk tree check process.
But since it uses some memory for each extent item, for a large fs with
several TB metadata, this can easily eat up memory and cause OOM.
To handle such limitation and improve scalability, the new low-memory
mode will not use any heap memory to record which extent is checked.
Instead it will use extent backref to avoid most of uneeded checks on
shared fs/subvolume tree blocks.
And with the use forward and backward reference cross check, we can also
ensure every tree block is at least checked once.
Signed-off-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Currently, balance operations are run synchronously in the foreground.
This is nice for interactive management, but is kind of crappy when you
start looking at automation and similar things.
This patch adds an option to `btrfs balance start` to tell it to
daemonize prior to running the balance operation, thus allowing us to
preform balances asynchronously. The two biggest use cases I have for
this are starting a balance on a remote server without establishing a
full shell session, and being able to background the balance in a
recovery shell (which usually has no job control) so I can still get
progress information.
Because it simply daemonizes prior to calling the balance ioctl, this
doesn't actually need any kernel support.
Signed-off-by: Austin S. Hemmelgarn <ahferroin7@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
We can set not only btrfs mount point but also any path belong to
btrfs mount point as btrfs-receive's destination.
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add new options -q,--quiet to prevent printing messages on stderr, added
--verbose as alternative for -v. Moved 'Mode NO_FILE_DATA enabled'
message to stderr. The default verboisty level is 1 to keep some
backward compatibility.
Signed-off-by: M G Berberich <btrfs@oss.m-berberich.de>
[ minor adjustments in the options, help text and changelog, added
manual page text ]
Signed-off-by: David Sterba <dsterba@suse.com>
A short delay with a warning before starting a full balance should
improve usability. We have been getting reports from people who run full
balance after following some random advice and then get surprised by the
performance impact.
The countdown is done even when run from scripts, but as the whole
balance takes significanly more time, this shouldn't be an issue.
Signed-off-by: David Sterba <dsterba@suse.com>
David Sterba