A user reported on IRC that the new 32M default for target extent size
does not work. This happens because if there are no commandline options,
the v1 ioctl is used that does not do any fine grained defrag. As the v2
ioctl has been introduced 6 years ago (2010, kernel 2.6.33) we won't
keep backward compatibility anymore.
Signed-off-by: David Sterba <dsterba@suse.com>
In btrfs-filesystem(8), improved the documentation of snapshot unaware
defragmentation and included the exact kernel version numbers being affected as
well as the possible effects.
No longer use the word "unlink" which is easily understood as "deleting a file".
Moved the warning more to the beginning of "defragment" subcommand's
documentation where it's more visible to readers.
Added the same warning to the "autodefrag" option of btrfs-mount(5).
Signed-off-by: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
Previously in 'filesystem resize get_min_size', now
'inspect-internal min-dev-size'. We'd like to avoid cluttering the
'resize' syntax further.
The test has been updated to exercise the new option.
Signed-off-by: David Sterba <dsterba@suse.com>
Currently there is not way for a user to know what is the minimum size a
device of a btrfs filesystem can be resized to. Sometimes the value of
total allocated space (sum of all allocated chunks/device extents), which
can be parsed from 'btrfs filesystem show' and 'btrfs filesystem usage',
works as the minimum size, but sometimes it does not, namely when device
extents have to relocated to holes (unallocated space) within the new
size of the device (the total allocated space sum).
This change adds the ability to reliably compute such minimum value and
extents 'btrfs filesystem resize' with the following syntax to get such
value:
btrfs filesystem resize [devid:]get_min_size
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Resize of a filesystem image does not work as expected. This has been
confusing and can have bad consequences as people have reported,
resizing the wrong filesystem.
Signed-off-by: David Sterba <dsterba@suse.cz>
A few minor benefits:
* editors set highliting according to the extensions
* web access to the git repository (github) renders the .asciidoc
files:
* we can link to them from the wiki
* the files are editable via browser and such editations can be
submitted for merge easily
Signed-off-by: David Sterba <dsterba@suse.cz>
