Messages in this thread | | | Date | Tue, 30 Aug 2011 10:42:37 -0700 | From | Sunil Mushran <> | Subject | Re: [PATCH] xfstests 255: add a seek_data/seek_hole tester |
| |
On 08/27/2011 01:30 AM, Marco Stornelli wrote: > Il 26/08/2011 16:41, Zach Brown ha scritto: >>>> Hole: a range of the file that contains no data or is made up >>>> entirely of NULL (zero) data. Holes include preallocated ranges of >>>> files that have not had actual data written to them. >> >>> No for me. A hole is made up of zero data? It's a strange definition >>> for me. >> >> It's a very natural definition for me. It mirrors the behaviour of >> read() of sparse data inside i_size that file system authors already >> have to consider. >> >> It's also a reminder for people that this interface is about avoiding >> reading zeros. Systems that track contents can do this for files that >> had tons of zeros written. The data is there but the app is >> specifically asking us to skip it by using SEEK_DATA. >> >> - z >> > > I think we need to consider a hole and "data not present/not written yet" as two different cases even they are related. For example, if I do an fallocate without keep size option, then I do a read, I have the same behavior of sparse data inside i_size, but the blocks are allocated so no sparse data in this case. Simply there are no difference from app point of view.
Exactly. That's why seek_hole should identify them alike, if possible. But that should not be a requirement because the sole aim here is to improve performance. Identifying a hole as data is not the end of the world. In some cases it may be more efficient. We just have to ensure that we don't identify data as a hole.
BTW, we still have the fiemap interface that allows users to identify unwritten extents, etc. Use that if you want that kind of detail.
| |