On Tue, Jul 31, 2018 at 7:33 PM, John Stoffel <john@xxxxxxxxxxx> wrote: >>>>>> "Chris" == Chris Murphy <lists@xxxxxxxxxxxxxxxxx> writes: > > Chris> On Fri, Jul 27, 2018 at 1:31 PM, John Stoffel <john@xxxxxxxxxxx> 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 _______________________________________________ linux-lvm mailing list linux-lvm@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
