Howdy folks, I was working in implementing the suggested feature in my patch, about getting the next inode used after one is provided, and I hit something that I'm not really sure if this might be considered a bug, or just a work form. XFS_IOC_FSINUMBERS, is supposed to be called with a zeroed xfs_fsop_bulkreq.lastip, so at each call, kernel will update this number to the last inode returned, and, the next call will return in xfs_inogrp.xi_startino, the next existing inode after .lastip. So, I was expecting that, passing a non-zero .lastip at the first call, I would be able to get the next inode right after the one I passed through .lastip, but, after some tests and reading the code, I noticed that this is not the case. The problem (not sure if I can really say it's a problem), is that, if the inode number passed, happens to be somewhere in the middle of an inode chunk, the whole chunk will not be printed, only the next inode chunk will start to be printed, hiding all information of the previous one. I'm not sure if this is the desired behavior or not, but, I'd say that, if the inode passed in .lastip, is not the first in the chunk, the output should start for its own chunk, instead of the next one, but, I prefer to see you folks POV before starting to fix something that I'm not sure if it's actually broken :-) Cheers -- Carlos _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
