Re: [PATCH 1/4] fs: add SEEK_HOLE and SEEK_DATA flags

[Sunil Mushran]

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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/