If i am understanding the NFS "problem" correctly it is as follows.
1. server is booted, drive is given a dynamic major/minor number
2. nfs server gives this out as part of a file handle
3. server is rebooted gets another dynamic major/minor number (not the
same one)
4. client then attemps to use the old file handle to access the file
<BOOM>
The fix for this as I seee it is that the nfs code should be modified to
not use the major/minor number but have some other method of storing the
info. As a reminder the file handle for nfs is supposed to be opaque, that
is it only has meaning for the server, the client cannot assume anything
about how it is structured.
Of course I may have missed the point of the argument, if so I know
someone will tell me :-)
David Lang
On 8 Jun 1999, david parsons wrote:
> Date: 8 Jun 1999 14:04:53 -0700
> From: david parsons <o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s>
> To: linux-kernel@vger.rutgers.edu
> Newsgroups: mlist.linux.kernel
> Subject: Re: Migrating to larger numbers
>
> In article <linux.kernel.19990608121009.D13308@hazel>,
> Raul Miller <rdm@test.legislate.com> wrote:
> >Richard Gooch <rgooch@atnf.csiro.au> wrote:
> >> However, for the sake of argument, let's say we write device drivers
> >> and make use of dynamic device numbers. I don't actually see where the
> >> problem is.
> >
> >Ok, consider this scenario:
> >
> >(1) Some application is using device files over NFS. [If this isn't
> >happening, there's no problem with 64 bit device numbers.] Let's use
> >your "exporting root to legacy machines" case...
>
> That application is probably using the device directory for the
> machine it's on, and if it does want to use the device directory
> for the server, sensible programming practice would seem to dictate
> being able to track changes to the devices, because servers will
> go down and have the hardware changed out from under you.
>
>
> >(3) The NFS server gets taken down for a few minutes and disks get added
> >to it. [This is the case where the semantics of the device numbers
> >become significant.]
>
> Do applications on other machines care what the devices on the server
> are?
>
> ____
> david parsons \bi/ Danger, will robinson!
> \/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
"If users are made to understand that the system administrator's job is to
make computers run, and not to make them happy, they can, in fact, be made
happy most of the time. If users are allowed to believe that the system
administrator's job is to make them happy, they can, in fact, never be made
happy."
- -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA '97)
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQEVAwUBN14lKT7msCGEppcbAQGTzggAmk62LsVW/SURL/s2Rio3fvU+eIH0xxzg
wiTwd9rqEC96qoiYJvFowWmYOk2L8+BBk6/hJhaZpWVaxsaMIe0xnft/CBEfab0y
4Hhl5WUYeZkcvHsyFeRiRa0znte5ZzCPCMdre+tSyOhjiJpXnwxeVu3hPtmVBxDy
NbWhRNzdHCaYvaDU8dBKIPP42WyjPTavOxDvDIkhvbkV4KCOuybrxF8OZCMXSlSI
GAQf0O4l93Wf/Ez2lPKGdffDdpCREkLnHNBj1Bcs7oUV1bSxDJnG7lUBSsvIT8NS
DiwSymZZ3bA+hD/RSEQJGFuzyxNDw9rk7vEPZ1jkXTf+Jkz+qHasyw==
=M9cE
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/