Re: File Unique ID
- From: phil-news-nospam@xxxxxxxx
- Date: 29 Jul 2008 04:32:45 GMT
On Mon, 28 Jul 2008 13:56:59 -0700 (PDT) David Schwartz <davids@xxxxxxxxxxxxx> wrote:
| On Jul 28, 12:09?pm, Ambrose Silk <si...@xxxxxxxxxxxxxx> wrote:
|
|> No standard requires the device/inode combination to be
|> unique.
|
|> Can you give a reference?
|
| Can I give a reference for the absence of a requirement? No, of course
| not. Can you give a reference for any standard that requires device/
| inode pairs to be unique or every file to have a unique inode?
Can you give an example of an existing filesystem where this is an issue.
Does the MS-DOS filesystem count?
| Clearly, 32-bit inodes can't be guaranteed unique on filesystems that
| support more than 2^32 files.
Filesystems that support more than 2^32 files would not use 32-bit inodes
if they were an inode based design. Those that are not inode based would
have to use some other means to access the data from a name (some do have
inode meta information in directories themselves without having any kind
of inode number mapping layer we are so familiar with in Unix. But this
could be faked to a degree by structuring an index that can get to the
block that data is in, and down to the data entry itself. That should be
able to fit in a 64 bit integer unless the size of the filesystem exceeds
sizeof(file meta data struct)*2^64.
We must assume st_ino is at least 64 bits on systems that can support
filesystems with 64 bit inodes. Things break if st_ino is only 32 bits
in such systems.
| Also, consider "composite" filesystems that aggregate multiple devices
| into a single apparent filesystem. For example, consider an NFS share
| that contains subdirectories that are themselves imported by NFS. This
| will appear to be a single device to programs using it, but it is
| actually multiple devices, so there is no way to get the device
| identifier that, together with the inode, would form a unique
| identifier.
How would a filesystem actually carry out selecting the file when opened?
The unique information it has would have to be accessed via the inode.
Such a "composite" filesystem can establish tables of mappings and the
inode is a hash or index into it. That's just one possible way. There
are others. Be creative.
| Sorry, devices are not required to guarantee that their inodes are
| unique. In practice, it is impossible for many types of filesystems to
| provide that guarantee.
In practice is it possible to make an implementation go either way. The
wise developer makes it unique. Of course it might have been easier if
we could go beyond 64 bit for inode. The UNIX legacy is limiting in that
respect. Compare that to sockets where we can make rather long "names".
| How would you design an NFS<->SMB redirector such that it guarantees
| unique inodes on the NFS side when it gets unique GUIDs in the SMB
| side?
Sorry, I know not enough about SMB, or even NFS, to address that specific
case.
--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
.
- References:
- File Unique ID
- From: Bercea Gabriel
- Re: File Unique ID
- From: Jens Thoms Toerring
- Re: File Unique ID
- From: Scott Lurndal
- Re: File Unique ID
- From: Ambrose Silk
- Re: File Unique ID
- From: David Schwartz
- Re: File Unique ID
- From: Ambrose Silk
- Re: File Unique ID
- From: David Schwartz
- File Unique ID
- Prev by Date: good stuff on thread programming
- Next by Date: Re: performance implications of releasing resources and context switches
- Previous by thread: Re: File Unique ID
- Next by thread: Re: File Unique ID
- Index(es):
Relevant Pages
|
