From: Eric Blake <eblake@redhat.com>
To: Nick Bowler <nbowler@elliptictech.com>
Cc: Markus Trippelsdorf <markus@trippelsdorf.de>,
Christoph Hellwig <hch@infradead.org>,
Josef Bacik <josef@toxicpanda.com>,
linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Coreutils <coreutils@gnu.org>
Subject: Re: [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags
Date: Mon, 25 Apr 2011 09:48:51 -0600 [thread overview]
Message-ID: <4DB597E3.7090600@redhat.com> (raw)
In-Reply-To: <20110425150227.GA10653@elliptictech.com>
[-- Attachment #1: Type: text/plain, Size: 2349 bytes --]
On 04/25/2011 09:02 AM, Nick Bowler wrote:
Hi Nick,
> * File A (sparse file created by lseek/write beyond end-of-file):
>
> data | hole 0 | data || hole 1 (virtual)
>
> * File B (sparse file created by truncate beyond end-of-file):
>
> data | hole 0 || hole 1 (virtual)
>
> Excluding the error description, the term "the last hole" is used in
> two places in your proposal:
>
> * (for SEEK_HOLE): if offset falls within "the last hole", then the
> file offset may be set to the file size instead.
>
> * (for SEEK_DATA): it shall be an error ... if offset falls within the
> last hole.
>
> I imagine that both of these conditions are intended to address the
> case where the offset falls within hole 0 in File B, that is, when
> there is no non-hole data beyond the specified offset but the offset
> is nevertheless less than the file size.
Correct.
> However, this looks (to me)
> like the penultimate hole in the file, not the last hole. Furthermore,
> these conditions are presumably *not* intended to apply to the
> penultimate hole in File A, which has data after it.
Good catch.
>
> I think my confusion can be avoided by talking about the last non-hole
> data byte in the file (which is unambigious), instead of by talking
> about the last hole. For instance, the SEEK_HOLE/SEEK_DATA descriptions
> could be written as follows:
>
> If whence is SEEK_HOLE, the file offset shall be set to the smallest
> location of a byte within a hole and not less than 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. It shall be an error if
> offset is greater or equal to the size of the file.
>
> 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.
>
> plus a corresponding update to the ENXIO description:
>
> ... or the whence argument is SEEK_DATA and the offset falls beyond
> the last byte not within a hole.
I've added your improved wording as a comment at
http://austingroupbugs.net/view.php?id=415
--
Eric Blake eblake@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Eric Blake <eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Nick Bowler <nbowler-7BP4RkwGw0uXmMXjJBpWqg@public.gmane.org>
Cc: Josef Bacik <josef-DigfWCa+lFGyeJad7bwFQA@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Markus Trippelsdorf
<markus-xp2qqqlHh3xzoYq+O6RWwA@public.gmane.org>,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-btrfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Coreutils <coreutils-mXXj517/zsQ@public.gmane.org>
Subject: Re: [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags
Date: Mon, 25 Apr 2011 09:48:51 -0600 [thread overview]
Message-ID: <4DB597E3.7090600@redhat.com> (raw)
In-Reply-To: <20110425150227.GA10653-7BP4RkwGw0uXmMXjJBpWqg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]
On 04/25/2011 09:02 AM, Nick Bowler wrote:
Hi Nick,
> * File A (sparse file created by lseek/write beyond end-of-file):
>
> data | hole 0 | data || hole 1 (virtual)
>
> * File B (sparse file created by truncate beyond end-of-file):
>
> data | hole 0 || hole 1 (virtual)
>
> Excluding the error description, the term "the last hole" is used in
> two places in your proposal:
>
> * (for SEEK_HOLE): if offset falls within "the last hole", then the
> file offset may be set to the file size instead.
>
> * (for SEEK_DATA): it shall be an error ... if offset falls within the
> last hole.
>
> I imagine that both of these conditions are intended to address the
> case where the offset falls within hole 0 in File B, that is, when
> there is no non-hole data beyond the specified offset but the offset
> is nevertheless less than the file size.
Correct.
> However, this looks (to me)
> like the penultimate hole in the file, not the last hole. Furthermore,
> these conditions are presumably *not* intended to apply to the
> penultimate hole in File A, which has data after it.
Good catch.
>
> I think my confusion can be avoided by talking about the last non-hole
> data byte in the file (which is unambigious), instead of by talking
> about the last hole. For instance, the SEEK_HOLE/SEEK_DATA descriptions
> could be written as follows:
>
> If whence is SEEK_HOLE, the file offset shall be set to the smallest
> location of a byte within a hole and not less than 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. It shall be an error if
> offset is greater or equal to the size of the file.
>
> 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.
>
> plus a corresponding update to the ENXIO description:
>
> ... or the whence argument is SEEK_DATA and the offset falls beyond
> the last byte not within a hole.
I've added your improved wording as a comment at
http://austingroupbugs.net/view.php?id=415
--
Eric Blake eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]
next prev parent reply other threads:[~2011-04-25 15:49 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-21 19:42 [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags Josef Bacik
2011-04-21 19:42 ` [PATCH 2/2] Btrfs: implement our own ->llseek Josef Bacik
2011-04-21 20:45 ` [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags Theodore Tso
2011-04-21 21:29 ` Sunil Mushran
2011-04-22 3:23 ` Matthew Wilcox
2011-04-21 22:28 ` Eric Blake
2011-04-22 1:22 ` Josef Bacik
2011-04-22 4:50 ` Christoph Hellwig
2011-04-22 11:28 ` Markus Trippelsdorf
2011-04-22 11:28 ` Markus Trippelsdorf
2011-04-22 11:28 ` Markus Trippelsdorf
2011-04-22 11:50 ` Eric Blake
2011-04-22 16:28 ` Sunil Mushran
2011-04-22 16:40 ` Eric Blake
2011-04-22 16:57 ` Sunil Mushran
2011-04-22 17:03 ` Eric Blake
2011-04-22 17:08 ` Sunil Mushran
2011-04-22 18:06 ` Andreas Dilger
2011-04-22 23:33 ` Sunil Mushran
2011-04-24 17:49 ` Jamie Lokier
2011-04-25 12:37 ` Eric Blake
2011-04-25 14:15 ` Jamie Lokier
2011-04-22 13:06 ` Eric Blake
2011-04-22 13:06 ` Eric Blake
2011-04-25 15:02 ` Nick Bowler
2011-04-25 15:48 ` Eric Blake [this message]
2011-04-25 15:48 ` Eric Blake
2011-04-22 11:41 ` Eric Blake
2011-04-22 4:47 ` Christoph Hellwig
2011-04-22 20:10 ` Jonathan Nieder
2011-04-22 20:49 ` Sunil Mushran
2011-04-25 3:11 ` Valdis.Kletnieks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DB597E3.7090600@redhat.com \
--to=eblake@redhat.com \
--cc=coreutils@gnu.org \
--cc=hch@infradead.org \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markus@trippelsdorf.de \
--cc=nbowler@elliptictech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.