Re: udev and devfs - The final word

[Linus Torvalds <torvalds@osdl.org>]

On Sun, 4 Jan 2004, Daniel Jacobowitz wrote:
> 
> I think you two are talking straight past each other.  Andries is
> talking about the fsid, which is determined by the NFS server, based on
> its idea of the device number of the filesystem underlying the exported
> directory.  Right now, I can reboot my host system, and when it comes
> up then the NFS directories it exports to clients will have the same
> fsid.  With random device numbers it won't work; after rebooting the
> NFS server all clients will be forced to explicitly unmount and
> remount.

Ahh. I'll buy into that, and yes, this is an example of something that 
needs to be fixed. 

It shouldn't be fixed by saying "device numbers have to be stable across 
reboots", because the fact is, we're most likely going to have storage 
that is really really hard to enumerate in a repeatable fashion.

So the _proper_ thing to do is to have the NFS server not use the device 
number as part of fsid. It should use the _stable_ UUID of the filesystem 
or some similar label.

And it should do that exactly because the device number isn't as stable as 
NFS exporting would like it to be. Exactly because things like network- 
attached disks etc.  How would you otherwise export a disk that perhaps 
gets its address from DHCP? 

[ I incredulously asked a NetApp person why you'd ever want to expose the
  _disk_ over ethenet, rather than just have the NAS device export a
  filesystem of its own. It turns out that some people really want to just
  see a block device, either because Windows sucks at network filesystems
  or because they want to do things like databases onto them. The point
  being that once you do that, you'll likely want to export the thing as
  an SMB share from the thing that "owns" the disk. 

  So you would literally have a _disk_ whose IP address changed depending 
  on what other machines were booted on the same network. ]

Issues like this is also why Linux vendors have already started doing
things like "mount by label" - because disks have a nasty tendency to move
around, and specifying the fstab contents (or "root=xxx" on the kernel
command line) with physical location or similar just doesn't work all
that well. It happens today with things like USB2 or firewire disks. They 
get moved around, and they get a new device number.

It's still not _common_, but it's slowly getting there.

> Now, it seems to me that this isn't much of an argument against random
> device numbers.  Have userspace set a UUID for the device if you want,
> and use that in the fsid instead.  But that's the argument; it has
> nothing to do with the NFS server exporting its /dev.

I buy into that, and I agree 100% with you that this is just a case where 
you should use a UUID.

		Linus