On Sat 23 Jan 2021, Markus Grunwald wrote: > > For a good year, I'm using the attached set of patches that enable btrfs for > dirvish. I wouldn't use dirvish without it any more, because without the > patch the expiration stage takes ages. With the patch, it happens instantly.
Well, it seems to happen instantly. The actual cleanup in the background can still take hours. I have experimented with this, although that was a long time ago. At that point, the btrfs background cleanup / garbage collection started to take more that 24 hours so I ended up with not being able to write new backups because even though it looked like there was enough space, btrfs returned ENOSPACE. This was when just about the largest disks you could get was 750GB, and the backup volume was a RAID5 with 12 of those disks, backing up a large number of systems. So it was up against the IO limits anyway, and at that time, the userspace rm -r of the expired images on ext4 was faster than the btrfs snapshot cleanups. I fully understand that btrfs will have had significant changes in the meantime, so it's probably fine now. (However I still suffer from the stress from that time, so I'll never be using btrfs myself.). > ...with the following changes: > > - don't use rsync --inplace to prevent fragmentation > (also see http://www.spinics.net/lists/linux-btrfs/msg40354.html) The followup https://www.spinics.net/lists/linux-btrfs/msg40355.html contradicts a lot of the arguments against --inplace. Whether --inplace is useful or not probably depends on the sort of data being backupped. Perhaps that should be mentioned in the docs somewhere, so people can make an informed decision whether to add --inplace to the rsync options or not. I wonder whether anything smart with LVM snapshots together with dirvish could be done... Paul _______________________________________________ Dirvish mailing list [email protected] http://www.dirvish.org/mailman/listinfo/dirvish
