linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] readdir mess
Date: Tue, 12 Aug 2008 14:24:04 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0808121415390.3462@nehalem.linux-foundation.org> (raw)
In-Reply-To: <20080812205943.GX28946@ZenIV.linux.org.uk>



On Tue, 12 Aug 2008, Al Viro wrote:
> 
> Um...  Here it would happen only on attempt to return an entry for file
> that really has an inumber not fitting into the field; what would you
> do in such case?

You'd truncate the inode number. What's the big deal? Inode numbers aren't 
that important - they're just about the _least_ important part of the data 
returned for a readdir. 

Sure, truncating the inode number may confuse some programs like old-style 
/bin/pwd, but the thing is, we effectively _already_ do that by generating 
essentially random numbers for filesystems that don't have UNIX-style 
inode numbers anyway, so what's the big deal really?

> open() on a huge file is a different story, since you would get a valid 
> opened file and that'd be it; the logics in case of open() is, IIRC, "I 
> guess your binary is old, so it'll probably do other things that would 
> really have to trigger -EOVERFLOW; better bail out right now". 

The thing is, the "probably" is likely "probably not". There's a lot of 
things that work quite well.  Sure, if you lseek() you get confused. If 
you do "stat()" and then mmap(), you'll get confused. But a lot of 
programs really do just read/write. Or use llseek(), in fact. O_LARGEFILE 
is actually a later thing tan llseek() was.

So the problem with EOVERFLOW is that it says that programs shouldn't do 
anything at all because they _may_ do bad things.

And don't get me wrong - I think EOVERFLOW was (and is) actually a good 
thing for the _transition_ period. Exactly because it breaks programs in 
obvious ways, and early. It's good to be annoying in order to find 
problems early and fix them.

But I also think that we're not in a transition period any more, and as a 
result the annoyance part is just annoying an doesn't help find and fix 
problems any more, it just makes legacy binaries not work even if they 
could otherwise work fine (and _maybe_ have problems).

So something that made sense five years ago may not make sense any more, 
is what I'm saying. These days, if somebody runs legacy binaries, they do 
it because of archeology reasons or similar..

			Linus

  reply	other threads:[~2008-08-12 21:24 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-12  6:22 [RFC] readdir mess Al Viro
2008-08-12 17:02 ` OGAWA Hirofumi
2008-08-12 17:18   ` Linus Torvalds
2008-08-12 18:10     ` Al Viro
2008-08-12 18:22       ` Al Viro
2008-08-12 18:37         ` Al Viro
2008-08-12 19:24           ` Al Viro
2008-08-12 20:02       ` Linus Torvalds
2008-08-12 20:21       ` Linus Torvalds
2008-08-12 20:38         ` Al Viro
2008-08-12 21:04           ` Linus Torvalds
2008-08-13  0:04             ` Al Viro
2008-08-13  0:28               ` Linus Torvalds
2008-08-13  1:19                 ` Al Viro
2008-08-13  1:51                   ` Linus Torvalds
2008-08-13  8:36               ` Brad Boyer
2008-08-13 16:19                 ` Al Viro
2008-08-15  5:06               ` Jan Harkes
2008-08-15  5:34                 ` Al Viro
2008-08-15 16:58                 ` Linus Torvalds
2008-08-24 10:10                   ` Al Viro
2008-08-24 11:03                     ` Al Viro
2008-08-25 16:16                       ` J. Bruce Fields
2008-08-24 17:20                     ` Linus Torvalds
2008-08-24 19:59                       ` Al Viro
2008-08-24 23:51                         ` Linus Torvalds
2008-08-25  1:33                           ` Al Viro
2008-08-25  1:44                             ` Al Viro
2008-08-12 19:45     ` OGAWA Hirofumi
2008-08-12 20:05       ` Linus Torvalds
2008-08-12 20:59         ` Al Viro
2008-08-12 21:24           ` Linus Torvalds [this message]
2008-08-12 21:54             ` Al Viro
2008-08-12 22:04               ` Linus Torvalds
2008-08-13 16:20                 ` J. Bruce Fields
2008-08-12 21:47         ` Alan Cox
2008-08-12 22:20           ` Linus Torvalds
2008-08-12 22:10             ` Alan Cox

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=alpine.LFD.1.10.0808121415390.3462@nehalem.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /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).