From: Noveck, Dave (dave.noveck@netapp.com)
Date: 03/17/99-08:57:17 AM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA033034E3@TAHOE.netapp.com> From: "Noveck, Dave" <dave.noveck@netapp.com> Subject: RE: Finding all the exports for a server Date: Wed, 17 Mar 1999 06:57:17 -0800 Mike Eisler writes: > The motive for fsid.minor, fsid.major was previously discussed. But what is it? The document doesn't seem to give any indication about what fsid.major might be (i.e how the server should derive it and what the client should do with it). There is, on the other hand, plenty of information about what fsid.minor means in operational terms (i.e cross server mountpoints). If I'm a server why would I do anything else but always return a constant (e.g. 1) for fsid.major and if I'm a client, why would I not treat fsid.major concatenated with fsid.minor as a single 128-bit quantity. What is the split trying to tell me? > The > reason why they might need to each be 64 bits in length is that > each might be composed of say a UNIX style device number, and > the trend > is to make these numbers 64 bits in length, because even with 32 bit > numbers, there is pressure on the number space. With 32 bit > numbers, you > either have lots of majors (so lots of device types), or lots of > minors per major, but not both. This is tough on large servers that > uses logical devices to represent say TCP connections, pseudo ttys, > etc. Or tough on platforms that support lots of different ISVs > producing device drivers. I have no problem with fsid needing 64 bits. I was wondering about needing 128 bits for fsid. I wouldn't even have a big objection to 128 bits if someone thought they needed it. I just don't understand the point of two *separate* 64-bit quantities. It doesn't seem that the intention is to produce a single 128-bit quantity but I don't unserstand what it is.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:51 AM Z CST