[lkml]   [2004]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: udev and devfs - The final word

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-18 23:46    [W:0.020 / U:34.480 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site