From: Phil Auld <pauld@egenera.com>
To: Christoph Hellwig <hch@infradead.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.4.19 revert block_llseek behavior to standard
Date: Mon, 12 Aug 2002 13:14:31 -0400 [thread overview]
Message-ID: <20020812131431.F27650@vienna.EGENERA.COM> (raw)
In-Reply-To: <20020812174634.A10106@infradead.org>; from hch@infradead.org on Mon, Aug 12, 2002 at 05:46:34PM +0100
Rumor has it that on Mon, Aug 12, 2002 at 05:46:34PM +0100 Christoph Hellwig said:
> On Mon, Aug 12, 2002 at 12:06:59PM -0400, Phil Auld wrote:
> > Hi Al,
> > I think this falls under the VFS umbrella, but I may be wrong.
> >
> > Below is a fix to make block_llseek behave as specified in the Single Unix Spec. v3.
> > (http://www.unix-systems.org/single_unix_specification/). It's extremely trivial but
> > may have political baggage.
>
> Have you tested when you actually seek over the size of a block device?
Yes. Later reads/writes fails as they should.
> Stupid standards aside: what is the purpose of this? blockdevices don't
It can be used to determine the size fo the device. Seek then read, if read fails
back off. That's where I first noticed it. The IOtest program from the Cerberus suite
does this.
As to the stupidity of standards, I'm not sure how to answer that. I am not the only
one to raise this issue though.
> grow bigger if you seek beyond them..
>
> Did any Linux implementation ever follow the standard (as you rewrite
> reverse)?
Yes. As far as I can tell this came in in 2.4.11. Earlier 2.4 kernels and at least 2.2.16
(I didn't check them all) don't have this problem. If it had always been this way it
probably wouldn't have come up. I'm not trying to pick nits on purpose. Something
used to work and then didn't.
> What's the behaviour of other unix systems when seeking
> beyond the end of block devices?
Unfortunately (or not), I don't have any others handy.
Remember there is no data transfer taking place to do the lseek.
There were a couple of exerpts from the standard in this thread:
http://marc.theaimsgroup.com/?l=linux-kernel&m=102889752209363&w=2
--
Philip R. Auld, Ph.D. Technical Staff
Egenera Corp. pauld@egenera.com
165 Forest St., Marlboro, MA 01752 (508)858-2600
next prev parent reply other threads:[~2002-08-12 17:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-12 16:06 Phil Auld
2002-08-12 16:20 ` Alan Cox
2002-08-12 16:36 ` Phil Auld
2002-08-12 17:14 ` Alan Cox
2002-08-12 17:57 ` Phil Auld
2002-08-12 18:06 ` Alan Cox
2002-08-12 18:14 ` Phil Auld
2002-08-12 18:06 ` Phil Auld
2002-08-12 16:46 ` Christoph Hellwig
2002-08-12 17:14 ` Phil Auld [this message]
2002-08-13 8:13 ` Helge Hafting
[not found] <266483518@toto.iv>
2002-08-12 22:25 ` Peter Chubb
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=20020812131431.F27650@vienna.EGENERA.COM \
--to=pauld@egenera.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®