Stan,
I understand that this will be an ongoing problem. It seems like all I
could do at this point would be to ' manually defrag' my inodes the hard
way by doing this 'copy' operation whenever things slow down. (Either
that or go get my PHD in file systems and try to come up with a better
inode management algorithm.) I will be keeping two copies of this data
going forward anyways.
Are there any other suggestions you might have at this time - xfs or
otherwise?
-Dave
Dave Hall
Binghamton University
kdhall@xxxxxxxxxxxxxx
607-760-2328 (Cell)
607-777-4641 (Office)
On 04/12/2013 08:51 PM, Stan Hoeppner wrote:
On 4/12/2013 12:25 PM, 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?
The question isn't what it will look like initially, as your inodes
shouldn't be sparsely allocated as with your current aged filesystem.
The question is how quickly the problem will arise on the new filesystem
as you free inodes. I don't have the answer to that question. There's
no way to predict this that I know of.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
