Messages in this thread | | | Date | Mon, 22 Aug 2011 08:57:51 -0700 | From | Sunil Mushran <> | Subject | Re: [PATCH 1/4] fs: add SEEK_HOLE and SEEK_DATA flags |
| |
On 08/22/2011 03:56 AM, Marco Stornelli wrote: > 2011/8/22 Sunil Mushran<sunil.mushran@oracle.com>: >> 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/
| |