On Sun, Apr 26, 2020 at 12:04:05PM +0200, Marc Lehmann wrote: > Hi! > > I have a quesion about a possible behaviour change. I have a multi-device > btrfs filesystem with metadatas profile raid1 and data profile single. > > With my current kernel (5.4.28), it seems btrfs is balancing writes to the > devices, which is nice for performance (it's kind of a best-effort raid0), > but not so nice for data recovery (files get sepasrated out on all kinds of > disks, which increases data loss on device failure). > > I remember (maybe wrongly!) that this behaviour was diferent with older > kernels (4.9, possibly 4.19), in that I feel that btrfs was mostly writing ot > a single disk until it was more or less full before switching to another > disk, which is worse for performance, but much better for data recovery. > > The reason I chose data=single was specifically to help in case of device > loss at the cost of performance. Make backups. That's the only way to be sure about this sort of thing. > So my question is: did the behaviour change (possibly I misinterpreted > what I saw weith older kernels), and is there a way to get the behaviour > I thought it had before, where it mostly stayed with one disk without > balancing writes? As far as I'm aware, the behaviour hasn't changed. With single data, *chunk allocation* will go to the device with the largest amount of unallocated space. If your data is WORM (write-once-read-many), then you'll get a gigabyte of contiguous space on one device, and then it'll switch to a different one. If you are also deleting or modifying files, then the FS may be placing newly-written extents within any free space in existing chunk allocation. This could be anywhere within the FS, and so could be on any device. There's no way to control this behaviour (either the chunk allocation or the extent allocation). Hugo. > (I can simulate this for my case using either btrfs resize or incremental > btrfs adds). > > Thanks a lot for any insights! > -- Hugo Mills | Someone's been throwing dead sheep down my Fun Well hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | Nick Gibbins
