xfs
[Top] [All Lists]

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

To: Sunil Mushran <sunil.mushran@xxxxxxxxxx>
Subject: Re: [PATCH 1/4] fs: add SEEK_HOLE and SEEK_DATA flags
From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
Date: Mon, 22 Aug 2011 19:56:31 +0200
Cc: Josef Bacik <josef@xxxxxxxxxx>, linux-fsdevel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-btrfs@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, viro@xxxxxxxxxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XZbJGkRhsmNH2BkBSGJMFWNfDGJXkPb7TAkI1MSlb6U=; b=ZdyoikBkTv/qs6YKL8IRqa4FPissHUvsQvs4fYmtycYP1aLD/NrL+2o/dMRX8FYTo3 fMtqdDx88UBKh+seS9far40FiRtYSHJPJMgXSThyzOR+PSUSNwEAzTYdvCDprHqzlcMN 6j9pN5EH45LILyEL3JGjvQmZ2cYCo+JJKuxxw=
In-reply-to: <4E527C7F.9040807@xxxxxxxxxx>
References: <1309275199-10801-1-git-send-email-josef@xxxxxxxxxx> <4E4F814B.5070202@xxxxxxxxx> <4E4F865B.2010608@xxxxxxxxx> <4E4FD48B.8030101@xxxxxxxxxx> <4E4FE1B1.7010601@xxxxxxxxx> <4E51F24F.1050503@xxxxxxxxxx> <CANGUGtCi85Sgrr5R0E8iuN75ubbMX9txZMwnsvp4Wv3Xh+938g@xxxxxxxxxxxxxx> <4E527C7F.9040807@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; U; Linux i686; it; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11
Il 22/08/2011 17:57, Sunil Mushran ha scritto:
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/


Thank you very much!! I found another point. Your test fails with my implementation because here (http://www.austingroupbugs.net/view.php?id=415) says: "If whence is SEEK_DATA, the file offset shall be set to the smallest location of a byte not within a hole and not less than offset. It shall be an error if no such byte exists." So in this case I return ENXIO but the test expects another value. I have to say that there is a bit of confusion about the real behavior of this new feature :)

Marco

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