All I can say for non-btrfs-snapshot-send/receive use cases: Borg deduplicating archiver: block/chunk level deduplication, compression (lz4, zstd, ...) , encryption, remote backup/restore ...
https://www.borgbackup.org/ https://borgbackup.readthedocs.io/en/stable/ https://linoxide.com/borg-backup-linux-tool/ https://www.linux-magazine.com/Issues/2018/210/BorgBackup Tomas On Sat, 2022-01-01 at 18:19 -0800, Russell Senior wrote: > On Fri, Dec 31, 2021 at 10:48 AM Keith Lofstrom <[email protected]> > wrote: > > > Note for anyone using VERY LARGE hard drives for dirvish > > in this way: format the drive with a shit-ton of extra > > inodes, or you will use those up long before you run out > > of data sectors. Perhaps there are file system types that > > can reconfigure data space into extra inodes, and also > > reconfigure around emerging patches of failed disk; this > > would be handy to fill a large backup drive chock full. > > FWIW, the way rsync link-dest-based backups work is that unchanged > files are hardlinked, which means a new filename points at an > existing > inode to save space. That means that running out of inodes isn't such > a problem. For example, I have a 10TB RAID1 backup partition with > ext4 filesystem and despite having MANY, MANY backups, and being > about > 80% full with regard to storage space, I am only using (according to > df -i) about 31% of the available inodes. This was with the standard > number of inodes allocated from a plain jane mkfs.ext4.
