From: Nick Bowler <nbowler@elliptictech.com>
To: Eric Blake <eblake@redhat.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 11:02:27 -0400 [thread overview]
Message-ID: <20110425150227.GA10653@elliptictech.com> (raw)
In-Reply-To: <4DB17D5B.2090303@redhat.com>
Hi Eric,
On 2011-04-22 07:06 -0600, Eric Blake wrote:
> I've created a request to standardize SEEK_HOLE and SEEK_DATA in the
> next revision of POSIX; comments are welcome to make sure that everyone
> is happy with wording:
> http://austingroupbugs.net/view.php?id=415
Reading through your proposal, I think there is one thing that could be
clarified: the meaning of "the last hole" in the file. Consider the
following two file layouts -- in the "diagrams", a bar (|) indicates a
boundary between holes and non-hole data, and a double bar (||)
indicates end-of-file.
* 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. 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.
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.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
next prev parent reply other threads:[~2011-04-25 15:02 UTC|newest]
Thread overview: 25+ 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-22 4:47 ` Christoph Hellwig
[not found] ` <loom.20110422T001650-760@post.gmane.org>
[not found] ` <BANLkTiknb+hzFAjpwESwMcqMVtkFc0HFQQ@mail.gmail.com>
2011-04-22 4:50 ` Christoph Hellwig
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
[not found] ` <20110422112852.GB1627-tLCgZGx+iJ+kxVt8IV0GqQ@public.gmane.org>
2011-04-22 13:06 ` Eric Blake
2011-04-25 15:02 ` Nick Bowler [this message]
[not found] ` <20110425150227.GA10653-7BP4RkwGw0uXmMXjJBpWqg@public.gmane.org>
2011-04-25 15:48 ` Eric Blake
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=20110425150227.GA10653@elliptictech.com \
--to=nbowler@elliptictech.com \
--cc=coreutils@gnu.org \
--cc=eblake@redhat.com \
--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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).