Subject: RE: Mount point crossing & space_avail

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 20 Mar 2002 07:59:07 -0800

The results in your example depend on the details of what happens
when the ls is done.  If the client, when sending the READDIR,
includes fsid among the attributes he requests (for READDIRPLUS-
style caching or just to get a better view of fs configuration),
it would be in a position to note the other file system and get
the df information.

This doesn't help for deeper export points though.

> But I suppose an EXPORTS operation in v4 will have to wait until 4.1, 
> even if we agree on that it's a Good Thing?

I think we're at the stage in which we'd have to agree that it's
an Essential Thing for us to put it in v4.0.

-----Original Message-----
From: Peter Åstrand [mailto:[email-masked]]
Sent: Wednesday, March 20, 2002 10:35 AM
To: [email-masked]
Subject: Mount point crossing & space_avail

Suppose we have a server S with three local filesystems:

/dev/disk1  /
/dev/disk2  /export/  (2 MiB bytes free)
/dev/disk3  /export/pictures/  (2 GiB bytes free)

The /export tree is exported via v4. The /export directory contains one
directory called "documents" (in addition to "pictures", where disk3 is
mounted). 

Client C mounts S:/export on /mnt. On the client, it looks like this:

$ cd /mnt
$ ls
documents  pictures
$ 

User U at client C is planning to copy 500 MiB of data to /mnt/pictures
and first checks if there is enough room for it:

$ df
Filesystem            Size  Used Avail Use% Mounted on
...
S:/export             ...   ...     2M  ... /mnt

User U, which is totally unaware of the servers disk configuration, fsids 
and "All That Jazz :-)" screams and think it's time to buy more disks. U 
cannot now that "pictures" actually is on another filesystem. Or have I 
forgotten something?

Wouldn't it be nice to have some way of querying the server of exported
filesystems, e.g. add the functionality of the MOUNT protocols EXPORT
procedure into v4? Some person asked if there was similiar functionality
in v4 at Cthon, and if I remember it correctly the answer was "No, but
most people will continue to run MOUNTD even with v4". I don't think
that's a good solution.

If v4 had some way of querying the server for exported fs's, an
NFSv4-aware df program could be a bit more intelligent:

$ df
Filesystem            Size  Used Avail Use% Mounted on
...
S:/export             ...   ...     2M  ... /mnt
S:/export/pictures    ...   ...     2G  ... (not mounted)

(Maybe it's a bad idea with a df program fetching information not only by
calling statfs(2) but also by contacting server S over the network, but at
least it would be possible.)

But I suppose an EXPORTS operation in v4 will have to wait until 4.1, 
even if we agree on that it's a Good Thing?

-- 
Peter Åstrand                Telephone: +46-13-21 46 00
Cendio Systems               E-mail: [email-masked]
Teknikringen 3
583 30 Linköping
Sweden

---

From: Jim Rees <[email-masked]>
Date: Wed, 20 Mar 2002 14:56:06 -0500

Yes, of course.  I am just arguing that "list exports" is not useful enough
to justify adding it to the protocol.

  This command then walks the entire directory tree, right?

No, it returns df info for the directory only.  It is intended to answer the
question, "what's the largest file I can create in this directory?"

---

From: Peter Åstrand <[email-masked]>
Date: Tue, 26 Mar 2002 23:09:03 +0100 (CET)

> > Yes, that is an option. Do you think there are other properties than fsid
> > that would lead to an "interesting" directory? I can't think of any right
> > know.
> 
> While we may not be able to think of a large list of properties that may
> be useful, it would be unfortunate to lock ourselves into just fsid's. 

Adding a GETEXPORTEDFS'S operation would not prevent a separate
database/nameservice mechanism.

Maybe it's not that useful to debate this more right now: No new ops can
go into NFSv4.0 anyway. When it's time for 4.1, we probably know if the
lack of a GETEXPORTEDFS'S op is a major problem or not.

Thanks for all comments.

---

From: Jim Rees <[email-masked]>
Date: Tue, 26 Mar 2002 19:16:23 -0500

I think you are confusing nfs v4 with some earlier, insecure version of nfs.