|To:||Marco Stornelli <marco.stornelli@xxxxxxxxx>|
|Subject:||Re: [PATCH] xfstests 255: add a seek_data/seek_hole tester|
|From:||Sunil Mushran <sunil.mushran@xxxxxxxxxx>|
|Date:||Tue, 30 Aug 2011 10:42:37 -0700|
|Cc:||Zach Brown <zab@xxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, Andreas Dilger <adilger@xxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Josef Bacik <josef@xxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-btrfs@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, viro@xxxxxxxxxxxxxxxxxx, dchinner@xxxxxxxxxx|
|References:||<1309275199-10801-1-git-send-email-josef@xxxxxxxxxx> <1309275199-10801-5-git-send-email-josef@xxxxxxxxxx> <20110825060632.GA9933@xxxxxxxxxxxxx> <20110825064039.GO3162@dastard> <0A267E55-7772-438D-B6A7-89B73020F311@xxxxxxxxx> <20110826013528.GW3162@dastard> <CANGUGtC1qk2Tkv42fvibUKiEJz_MnNiV-nQ7T-_woppVhjQK-Q@xxxxxxxxxxxxxx> <20110826144124.GA17519@xxxxxxxxxxxxxx> <4E58AB28.1080009@xxxxxxxxx>|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11|
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. - zI 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.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [PATCH 6/7] mm: vmscan: Throttle reclaim if encountering too many dirty pages under writeback, Mel Gorman|
|Next by Date:||[PATCH] xfsdump: remove unnecessary #ifdefs, Bill Kendall|
|Previous by Thread:||Re: [PATCH] xfstests 255: add a seek_data/seek_hole tester, Marco Stornelli|
|Next by Thread:||Re: [PATCH] xfstests 255: add a seek_data/seek_hole tester, Sunil Mushran|
|Indexes:||[Date] [Thread] [Top] [All Lists]|