From: Paul F. <pg...@fo...> - 2006-03-07 17:20:12
|
> The depth isn't really the issue. It is that they are created under one > tree, and hardlinked to another tree. The normal FS optimization of > putting the inodes of files in a given directory near each other breaks > down, and the directories in the pool end up with files of very diverse > inodes. > > Just running a 'du' on my pool takes several seconds for each leaf > directory, very heavily thrashing the drive. > > If you copy a backup pool, either with 'cp -a' or tar (something that will > preserve the hardlinks), the result will either be the same, or the pool > will be more efficient and the pc trees will be very inefficient. It all > depends on which tree the backup copies first. to clarify -- in the "normal" case, where the backup data is usually not read, but only written, the current filesystems are okay, right? it's only when you want to preserve or copy your pool that there's an issue? (or am i neglecting something? i might well be.) if this is mostly true, then creating a better data copier might be productive. i thought there was work some time ago to allow listing the files to be copied in inode order, using an external tool that pre-processed the tree. what happened with that? > I still say it is going to be a lot easier to change how backuppc works > than it is going to be to find a filesystem that will deal with this very > unusual use case well. but having the backup pools exist in the native filesystem in a (relatively) transparent way is a huge part of backuppc's attraction. paul =--------------------- paul fox, pg...@fo... (arlington, ma, where it's 36.9 degrees) |