Re: [PATCH] xfs_io: Implement inodes64 command - bug in XFS_IOC_FSINUMBERS?

[Carlos Maiolino <cmaiolino@redhat.com>]

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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs