On 07/10/16 23:19, Jonathan Dowland wrote: > I don't know whether dirvish does something to improve matters, but with > hard link trees, if you have lots of little files (such as Maildir archives > of busy mailing lists like LKML), the amount of space consumed by the file > system metadata to represent the trees is very high, getting towards the > size used for the files themselves. This is compounded on some filesystems > (the ext family amongst them) that only ever increase the amount of space > for storing dirent metadata, never decrease it, so if you have a Maildir > which has high churn, and you move from having a large amount of mail to > a small amount, the storage allocated for metadata for the directory will > remain large.
The metadata you're talking about is merely the directory entries, right? I'm still searching, but haven't yet found info on how much space a directory entry takes up. Any pointers would be most welcome :-) I'm on xfs, btw. Regardless, in the trivial case where nothing has changed between backups, the directories in the new backup must take up exactly the same space as the ones in the old backup, where both point to the same files. So whether there's one set of links or several, it's still the case that for small files, the directory entries will take proportionately more space relative to the file - that's inevitable. I think I'm right in saying that in the dirvish (or similar) use case, the number of directory entries in a given directory will never decrease anyway - except in the odd case where I discover I've backed up something I shouldn't have (eg a huge or confidential file), and gone through purging it from all the backups. Richard
signature.asc
Description: OpenPGP digital signature
