On 08/22/2011 03:56 AM, Marco Stornelli wrote:
2011/8/22 Sunil Mushran<sunil.mushran@xxxxxxxxxx>:
On 08/20/2011 09:32 AM, Marco Stornelli wrote:
Thank. Yes the word "next" is not very clear. I re-read the proposal for
the standard, actually it's seems to me that if we are in the last hole we
should return the file size, if we are not in the last hole than it's ok the
same offset - "....except that
if offset falls beyond the last byte not within a hole, then the file
offset may be set to the file size instead".
Any proposal that differentiates between holes is wrong. It should not
matter where the hole is.
Think of it from the usage-pov.
doff = 0;
while ((doff = lseek(SEEK_DATA, doff)) != -ENXIO) {
hoff = lseek(SEEK_HOLE, doff);
read_offset = doff;
read_len = hoff -doff;
process();
doff = hoff;
}
The goal is to make this as efficient as follows. Treating the last
hole differently adds more code for no benefit.
Mmmm.....It seems that Josef has to be clear in this point. However I
looked for the seek hole test in xfs test suite, but I didn't find
anything. Btrfs guys, how have you got tested the implementation? What
do you think about this corner case? Al, what do you think about it?
The following test was used to test the early implementations.
http://oss.oracle.com/~smushran/seek_data/
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
