[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Re: Inode Sigs and tla on FAT/NFS (was: tla on nfs only

From: Stefan Monnier
Subject: [Gnu-arch-users] Re: Inode Sigs and tla on FAT/NFS (was: tla on nfs only)
Date: 14 Mar 2004 20:52:55 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

> Yes, I think that would fix the tla-on-fat problem too, but then you
> have the high risk of a corrupted library/pristine causing real
> problems.

The only serious source of corruption that I know of is the use of --link
which doesn't work on FAT anyway, so I wouldn't worry too much about it.

> problem on nfs is afaik that you can't even really rely on ctime, since
> it isn't consistent across timezones

Huh?  AFAIk it's completely timezone independent: the timezone-related
manipulation is all done locally when turning the "number of seconds since
the epoch" into a human-readable string.

> So on fat you could use filename, ctime and perhaps device numbers. On
> nfs you haven't got much left to work with. So basically there you'd
> have to check the file contents, if a corruption occured (given that my
> knownledge about nfs is correct and I didn't miss anything obvious).

If I remember the Linux discussions about it back then, it's difficult to
provide an efficient and reliable (with no odd corner case) NFS server
without exporting internal inode numbers.  [ IIRC the main reason is that
the NFS server must be able to crash&reboot and then keep working without
having to umount&remount on the client side ]
So most/all NFS servers just use the underlying FS's inode numbers which
ensures they are preserved across reboots and everything.  That's also one
of the main reasons why you can't export several partitions as a single
NFS mount point.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]