Re: [linux-lvm] Why use thin_pool_autoextend_threshold < 100 ?

[Chris Murphy <lists@colorremedies.com>]

On Tue, Jul 31, 2018 at 7:33 PM, John Stoffel <john@stoffel.org> wrote:
>>>>>> "Chris" == Chris Murphy <lists@colorremedies.com> writes:
>
> Chris> On Fri, Jul 27, 2018 at 1:31 PM, John Stoffel <john@stoffel.org> wrote:
>>>
>>> Why don't you run quotas on your filesystems?  Also, none of the
>>> filesystems in Linux land that I'm aware of supports shrinking the
>>> filesystem while live, it's all a unmount, shrink FS, shrink volume
>>> (carefully!) and then re-mount the filesystem.
>
> Chris> Btrfs supports grow and shrink resizes only when mounted. It's
> Chris> not possible to resize when unmounted.
>
> That's... bizarre.  Good to know, but bizarre.  That does make it more
> appealing to use in day to day situations for sure.  Any thoughts on
> how stable this is in real life?

I've never heard of it failing in many years of being on the Btrfs
list. The resize leverages the same block group handling as balance
code, so the relocation of block groups during resize is the same as
you'd get with a filtered balance, it's integral to the file system's
operation.

The shrink operation first moves block groups in the region subject to
shrink (the part that's going away), and this is an atomic operation
per block group. You could pull the plug on it (and I have) in
progress and you'd just get a reversion to a prior state before the
last file system metadata and superblock commit (assumes the hardware
isn't lying and some hardware does lie). Once all the block groups are
moved, and the dev and chunk trees are updated to reflect the new
location of those chunks (block groups), the superblocks are updated
to reflect the new device size.

Literally the shrink operation changes very little metadata, it's just
moving block groups, and then the actual "resize" is merely a
superblock change. The file system metadata doesn't change much
because Btrfs uses an internal logical block addressing to reference
file extents and those references stay the same during a resize. The
logical block range mapping to physical block range mapping is a tiny
update (maybe 1/2 dozen 16K leaf and node writes) and those updates
are always COW, not overwrites. That's also how this is an atomic
operation. If the block group copy fails, the dev and chunk trees that
are used to translate between logical and physical block ranges never
get updated.


-- 
Chris Murphy