IMFS: yet another trouble.
joel.sherrill at OARcorp.com
Wed Nov 29 22:50:30 UTC 2000
Sergei Organov wrote:
> jennifer averett <jennifer.averett at oarcorp.com> writes:
> > > Oh, yes. As always I've already found it myself yesterday. Now everything
> > >works just great! I'd like to mention in addition that 'st_dev' and 'st_ino'
> > >fields of 'struct stat' should be set in the file-system 'fstat' routine to
> > >some unique values, otherwise 'getcwd()' doesn't work. It'd be fine to
> > >mention this fact in the documentation if it's not already there (at least I
> > >didn't find it).
> > >
> > >
> > This points to a problem in the IMFS, st_dev is only set if the node is a
> > device node. Looking at getcwd I have a question: This code is identifying
> > the root node by the combination of st_ino and st_dev. This implies that on
> > a given device no two nodes can have the same identity. We have no
> > guarantee of this. Currently each file system assigns its own node id, (in
> > the IMFS this id is based upon instance of the file system - therefore if
> > the file system were mounted twice there would be two nodes with the same
> > id).
> As far as I understand, the idea behind st_ino and st_dev pair is that in pair
> they identify a node uniquely.
I did not find this explicitly in POSIX although it seemed
implied by a Rationale I found. But it is pretty clear in
the UNIX98 standard. This leads us to the next set of comments
very naturally. :)
FYI Jennifer and I seemed to take a similar wandering path
in our discussion.
> Usually st_ino is block number on some device
> (unique within device)
Not necessarily a block number. It is similar a file sequencing
number. I think it should be guaranteed to be unique per
> and st_dev is device id (globally unique number).
> in memory file system, the st_dev could be some arbitrary unique number that
> is the same for all instances of IMFS (in fact it tells that device is RAM),
This is a possibility. It is also a possibility that it could have
a unique and arbitrary major number with the minor number indicating
the "instantiation" of the IMFS. First IMFS mounted is 0, 2nd is 1,
etc. This allows the st_dev to still start at 1 and simply
increment per instantiation of the IMFS.
> and st_ino could be just unique pointer, e.g. pointing to the beginning of
> particular file.
This would be OK when sizeof(void *)==sizeof(unsigned32). But it
promotes out something I am not sure is a good idea. Seems to
put an address in "user space" that is dangerous.
> The st_dev should change if IMFS instance is working on top
> of some device other than RAM, e.g., NVRAM or something that doesn't share
> address space with RAM and thus st_ino values on that device may match those
> in RAM by collision.
Right now, the scheme most discussed is adding a (void *) per filesystem
pointer to the mount() call (ala Linux). The IMFS has no way to
know what it is. It is possible to mount it twice with a NULL
I suppose it could be its mount table entry point also but that
has an odd chance of colliding/promoting out something.
> In fact, AFAIK, in most Unixes st_dev is also subdivided to major and minor
> device number. The major number then specifies a class of devices, and minor
> number -- particular device of the class. To mimic this it's possible to
> assign arbitrary unique major number to RAM, and use minor number 0 for
> current instances of IMFS because all of them operate on the same device, --
st_dev is the same for devices under the IMFS. stat() /dev/console
to check it out. :)
But the device number for what the IMFS is mounted on falls into a
huge black hole. It is meaningless but has to be unique. I like
the idea of an arbitrary major with minor indicating the instantiation
but see no particular strong case for any of the alternatives.
Discussions are open. ;)
> Best Regards,
> Sergei Organov.
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users