Message-ID: <55780.67.8.218.172.1086786707.squirrel@webmail.krabbendam.net>
In-Reply-To: <40C6E07C.6060609@serice.net>
References: <40BD2841.2050509@serice.net>
    <54574.67.8.218.172.1086758675.squirrel@webmail.krabbendam.net>
    <40C6E07C.6060609@serice.net>
Date: Wed, 9 Jun 2004 09:11:47 -0400 (EDT)
Subject: Re: [PATCH] iso9660 Inodes Anywhere and NFS
From: "Eric Lammerts" <eric@lammerts.org>
To: "Paul Serice" <paul@serice.net>
Cc: linux-kernel@vger.kernel.org
User-Agent: SquirrelMail/1.4.2
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Importance: Normal
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1301
Lines: 29


> The second line of reasoning is that I do not know of any other common
> use of inode numbers in user space, and while posix says inode numbers
> shall be unique, BSD (at least NetBSD) appears to me to assign
> non-unique inode numbers for files by returning the lower 32 bits of
> the byte offset.

Tar uses inode numbers to determine which files are hardlinked. So if you
tar up a tree containing 0-byte files, then untar it somewhere, all 0-byte
files will end up being hardlinked to each other. The same happens when you
use cp -a.

> In conclusion, I just don't see much long-term difference in any of
> the inode numbering schemes, and the advantage of the scheme in my
> patch is that directories should always have unique inode numbers
> which to me is the important case.

Or take a hybrid approach: use your scheme for directories and my scheme for
files; use bit 0 or bit 31 to indicate what scheme is used. Then directories
have unique inode numbers, and files too as long as their directory records
are in the first 64Gb of the disc.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/