From: Chris Mason <mason@suse.com>
To: Stephen Lord <lord@sgi.com>
Cc: Jan Harkes <jaharkes@cs.cmu.edu>,
Alexander Viro <viro@math.psu.edu>,
"Peter J. Braam" <braam@clusterfs.com>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: BIG files & file systems
Date: 02 Aug 2002 08:17:59 -0400 [thread overview]
Message-ID: <1028290680.12670.199.camel@tiny> (raw)
In-Reply-To: <1028246981.11223.56.camel@snafu>
On Thu, 2002-08-01 at 20:09, Stephen Lord wrote:
> > > You _do_ need unique ->st_ino from stat(2), though - otherwise tar(1)
> > > and friends will break in all sorts of amusing ways. And there's
> > > nothing kernel can do about that - applications expect 32bit st_ino
> > > (compare them as 32bit values, etc.)
> >
> > Which is why "tar and friends" are to different extents already broken
> > on various filesystems like Coda, NFS, NTFS, ReiserFS, and probably XFS.
> > (i.e. anything that currently uses iget5_locked instead of iget to grab
> > the inode).
>
> Why are they broken? In the case of XFS at least you still get a unique
> and stable inode number back - and it fits in 32 bits too.
reiserfs is not broken here. It has unique stable 32 bit inode numbers,
but looking up the file on disk requires 64 bits of information.
-chris
next prev parent reply other threads:[~2002-08-02 12:13 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-31 19:16 BIG files & file systems Peter J. Braam
2002-07-31 19:26 ` Christoph Hellwig
2002-07-31 20:04 ` Matti Aarnio
2002-07-31 20:12 ` Christoph Hellwig
2002-08-02 17:26 ` Albert D. Cahalan
2002-08-02 22:14 ` Randy.Dunlap
2002-08-03 3:26 ` Albert D. Cahalan
2002-08-06 5:19 ` Andreas Dilger
2002-08-06 7:24 ` Albert D. Cahalan
2002-08-06 7:52 ` Andreas Dilger
2002-08-06 9:28 ` Matti Aarnio
2002-08-05 13:04 ` Stephen Lord
2002-08-05 13:42 ` Hans Reiser
2002-08-05 13:56 ` Randy.Dunlap
2002-08-05 14:21 ` Randy.Dunlap
2002-08-05 17:31 ` Albert D. Cahalan
2002-08-06 0:16 ` jw schultz
2002-08-06 9:48 ` Hans Reiser
2002-07-31 21:07 ` Jan Harkes
2002-07-31 21:13 ` Alexander Viro
2002-08-01 3:51 ` Jan Harkes
2002-08-01 12:01 ` Mark Mielke
2002-08-02 0:09 ` Stephen Lord
2002-08-02 12:17 ` Chris Mason [this message]
2002-08-02 12:33 ` Anton Altaparmakov
2002-08-02 13:56 ` Jan Harkes
2002-08-02 14:06 ` Steve Lord
2002-08-02 15:10 ` Hans Reiser
2002-08-02 15:39 ` Trond Myklebust
2002-08-02 17:01 ` Hans Reiser
2002-08-02 17:25 ` Nikita Danilov
2002-08-02 17:47 ` Trond Myklebust
2002-08-02 18:10 ` Nikita Danilov
2002-08-02 18:31 ` Hans Reiser
2002-08-02 18:48 ` Nikita Danilov
2002-08-02 18:59 ` Hans Reiser
2002-08-01 12:01 ` David Woodhouse
2002-08-01 20:33 ` Andrew Morton
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=1028290680.12670.199.camel@tiny \
--to=mason@suse.com \
--cc=braam@clusterfs.com \
--cc=jaharkes@cs.cmu.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=lord@sgi.com \
--cc=viro@math.psu.edu \
/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