[Top] [All Lists]

Re: [PATCH] xfstests 255: add a seek_data/seek_hole tester

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
In-reply-to: <4E58AB28.1080009@xxxxxxxxx>
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: 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.

- 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.

<Prev in Thread] Current Thread [Next in Thread>