On Fri, Apr 12, 2013 at 01:25:22PM -0400, Dave Hall wrote: > Stan, > > IDid this post get lost in the shuffle? Looking at it I think it > could have been a bit unclear. What I need to do anyways is have a > second, off-site copy of my backup data. So I'm going to be > building a second array. In copying, in order to preserve the hard > link structure of the source array I'd have to run a sequence of cp > -al / rsync calls that would mimic what rsnapshot did to get me to > where I am right now. (Note that I could also potentially use rsync > --link-dest.) > So the question is how would the target xfs file system fare as far > as my inode fragmentation situation is concerned? I'm hoping that > since the target would be a fresh file system, and since during the > 'copy' phase I'd only be adding inodes, that the inode allocation > would be more compact and orderly than what I have on the source > array since. What do you think? Sure, it would be to start with, but you'll eventually end up in the same place. Removing links from the forest is what leads to the sparse free inode space, so even starting with a dense inode allocation pattern, it'll turn sparse the moment you remove backups from the forest.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
