Re: [Re: Inodes]

Re: [Re: Inodes]

[Blesson Paul]

Hi J
                  You misunderstood my question. Let take an example.
Let I have a msdos partition. No msdos files has inode numbers, right. Let I
mount that msdos partition. Then what happens, That is my question. Will the
inode numbers are assigned to all msdos files at mounting time itself
Thanks for the reply
                   by
                      Blesson



J Sloan <jjs@mirai.cx> wrote:
Blesson Paul wrote:

> Hi
>                     This is an another doubt related to VFS. I want to know
> wheather all files are assigned their inode number at the mounting time
itself
> or inodes are assigned to files upon accessing only

er..

inode numbers are assigned at file creation time.

cu

jjs

-
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/


____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

Re: [Re: Inodes]

[H. Peter Anvin]

Followup to:  <20010514073547.12678.qmail@nwcst284.netaddress.usa.net>
By author:    Blesson Paul <blessonpaul@usa.net>
In newsgroup: linux.dev.kernel
>
> Hi J
>                   You misunderstood my question. Let take an example.
> Let I have a msdos partition. No msdos files has inode numbers, right. Let I
> mount that msdos partition. Then what happens, That is my question. Will the
> inode numbers are assigned to all msdos files at mounting time itself
> 

The inode numbers are "invented" by the MS-DOS filesystem driver.  In
the particular case of the "msdos" driver I believe it uses the
location of the directory entry (the functional equivalent of the
inode) on disk.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [Re: Inodes]

[Alan Cox]

> The inode numbers are "invented" by the MS-DOS filesystem driver.  In
> the particular case of the "msdos" driver I believe it uses the
> location of the directory entry (the functional equivalent of the
> inode) on disk.

They are generated basically at random with a uniqueness test and may change
once nobody is referencing the inode. Directory entry breaks across rename..

Re: [Re: Inodes]

[Andreas Dilger]

HPA writes:
> Blesson Paul <blessonpaul@usa.net> writes:
> > You misunderstood my question. Let take an example.  Let I have a msdos
> > partition. No msdos files has inode numbers, right. Let I mount that
> > msdos partition. Then what happens, That is my question. Will the
> > inode numbers are assigned to all msdos files at mounting time itself
> > 
> 
> The inode numbers are "invented" by the MS-DOS filesystem driver.  In
> the particular case of the "msdos" driver I believe it uses the
> location of the directory entry (the functional equivalent of the
> inode) on disk.

Just to clarify, this means that the "inode numbers" reported by an
msdos filesystem are a function of the disk-layout itself (i.e. they
are determined at mount time), and not numbers created when the file
is first accessed (AFAIK).

However, other filesystems are free to do this in other ways.  Reiserfs
has 64-bit "inode numbers" (actually "packing locality" + unique ID),
as does NTFS and XFS.  Network filesystems may do something completely
different (I have no idea what SMBFS does).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [Re: Inodes]

[Alexander Viro]

On Mon, 14 May 2001, Andreas Dilger wrote:

> Just to clarify, this means that the "inode numbers" reported by an
> msdos filesystem are a function of the disk-layout itself (i.e. they
> are determined at mount time), and not numbers created when the file
> is first accessed (AFAIK).

Wrong. open file. rename() it to another directory. truncate it to
zero. write to it. ->i_ino must have stayed they same. _Nothing_
on-disk that would be related to that file had stayed the same.
FAT simply doesn't allow inode numbers as functions of disk layout.

Re: [Re: Inodes]

[H. Peter Anvin]

Alexander Viro wrote:
> 
> On Mon, 14 May 2001, Andreas Dilger wrote:
> 
> > Just to clarify, this means that the "inode numbers" reported by an
> > msdos filesystem are a function of the disk-layout itself (i.e. they
> > are determined at mount time), and not numbers created when the file
> > is first accessed (AFAIK).
> 
> Wrong. open file. rename() it to another directory. truncate it to
> zero. write to it. ->i_ino must have stayed they same. _Nothing_
> on-disk that would be related to that file had stayed the same.
> FAT simply doesn't allow inode numbers as functions of disk layout.
> 

Correct.  At least at one time it used the offset of the directory entry
when that particular inode was last "seen" by the kernel... meaning that
when it finally dropped out of the inode cache, it would change inode
numbers.  I thought that was a reasonable (by no means perfect, though)
solution to a very sticky problem.

iso9660 also uses the offset of the directory entry, but iso9660
obviously doesn't have the problem of modifications.  It also means the
inode number is different if you mount a disk with Joliet (but not
RockRidge) or not, since Joliet uses a separate directory hierarchy.

	-hpa  

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [Re: Inodes]

[Alexander Viro]

On Mon, 14 May 2001, H. Peter Anvin wrote:

> Correct.  At least at one time it used the offset of the directory entry
> when that particular inode was last "seen" by the kernel... meaning that
> when it finally dropped out of the inode cache, it would change inode
> numbers.  I thought that was a reasonable (by no means perfect, though)
> solution to a very sticky problem.

Unfortunately it wasn't a solution. Look: you open a file and rename it
away. Now you want to create something in the old directory. Woops - can't
use the old entry of our file, since we'll get icache conflict that way.
So we get this lovely notion of reserved entries and there lies the
madness. It gets especially nasty when you consider rmdir of something
that used to be non-empty, but everything had been renamed away from it.
And stayes open. Moreover, at every moment you need both the "original"
location (inumber) and current one (for write_inode()). Better yet, you
get to deal with opened files that are not renamed, but removed. Yes,
all of that can be dealt with. The old driver didn't.

Re: [Re: Inodes]

[H. Peter Anvin]

Alexander Viro wrote:
> 
> On Mon, 14 May 2001, H. Peter Anvin wrote:
> 
> > Correct.  At least at one time it used the offset of the directory entry
> > when that particular inode was last "seen" by the kernel... meaning that
> > when it finally dropped out of the inode cache, it would change inode
> > numbers.  I thought that was a reasonable (by no means perfect, though)
> > solution to a very sticky problem.
> 
> Unfortunately it wasn't a solution. Look: you open a file and rename it
> away. Now you want to create something in the old directory. Woops - can't
> use the old entry of our file, since we'll get icache conflict that way.
> So we get this lovely notion of reserved entries and there lies the
> madness. It gets especially nasty when you consider rmdir of something
> that used to be non-empty, but everything had been renamed away from it.
> And stayes open. Moreover, at every moment you need both the "original"
> location (inumber) and current one (for write_inode()). Better yet, you
> get to deal with opened files that are not renamed, but removed. Yes,
> all of that can be dealt with. The old driver didn't.
> 

True enough.

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt