Subject: more recommended attributes?

From: Martin Pool <[email-masked]>
Date: Fri, 20 Jul 2001 16:58:54 +1000

It might be nice if there were standard numbered attributes in NFSv4
to hold the extended bits present on some Unix filesystems.  

For example, Linux and many BSDs have the "immutable" and
"append-only" bits.  (I thought Solaris had them too, but since I
can't find them in docs.sun.com I might be wrong.)  NT and some other
systems have "compressed".

I'm not sure what a good representation would be: perhaps one bit per
attribute, like the "system" and "archive" bits, or perhaps all packed
into a bitmap.  Since they're only semi-standardized the former method
might work better by allowing each filesystem to support only a subset
of bits.

For example, ext2/3 on Linux supports (from chattr(1)):

       The letters `ASacdijsu' select the new attributes for  the
       files:  don't  update  atime (A), synchronous updates (S),
       append only (a), compressed (c), no  dump  (d),  immutable
       (i),  data  journalling  (j),  secure  deletion  (s),  and
       undeletable (u).

http://www.linuxcentral.com/linux/man-pages/chattr.1.html

Although many of them have to be enforced on the server ('a' ,'i'),
and some are only meaningful on the server, like 'j' or 's'.  But
still it would be useful to allow the client to read and modify them
through the NFSv4 interface.  Some of these, like 'A' are useful to
the client kernel.

I'm not sure if the spec authors will consider this too
platform-specific, but I thought I'd throw it into the mill.  If NFSv4
is successful I think they will be wanted sooner or later, so to my
mind they might as well go in while the spec's relatively young and
elastic.

Yours,
-- 
Martin 
VA Linux Systems

---

From: Brent <[email-masked]>
Date: Fri, 20 Jul 2001 00:10:15 -0700

> might work better by allowing each filesystem to support only a subset

Seems perfectly reasonable to me.  I agree with one bit per attribute.

Want to write a more formal proposal that would insert easily into
the spec ?

	Brent

---

From: Martin Pool <[email-masked]>
Date: Mon, 23 Jul 2001 14:31:17 +1000

> Want to write a more formal proposal that would insert easily into

Here's a draft.  I've tried to make the definitions broad enough that
they would cover all systems with similar functionality.  Please let
me know what you think.

NTFS has some other attributes, including 'encrypted', 'offline',
'temporary', and 'sparse'.  I would rather let somebody more
experienced with NTFS comment on whether they ought to be exported as
well.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/hh/winbase/filesio_6c8i.asp

At the moment I don't mention inheritance of these attributes from
directories to files.  I'm not sure that should be server-defined or
not.

--------------------

[Text in square brackets is commentary and not for the new draft.]

Proposal is to insert attributes into the table of "Recommended
Attributes - Definitions" in section 5.5 of RFC3010 to support
extended file attribute bits on Linux, NT, and other systems.

no_atime_update		boolean

	The access time on files with the 'noatime' attribute is not
	updated by accessing or modifying the file.  The access time
	may be explicitly updated by SETATTR.

append_only	boolean

	Data within the file may not be overwritten: all writes must
	append to the file or they will fail with NFS4ERR_PERM.

	[This is a little problematic because Linux enforces the
	restriction based on whether O_APPEND was specified when the
	file is opened, which does not directly map into NFS4.
	Nevertheless it seems useful to at least make the bit visible
	if only so that people can see why the access failed.  Servers
	may need to map appending WRITES into opens of the file in
	append mode.]

compress       boolean

	The 'compress' bit advises the server that the file should be
	automatically compressed on disk.  Compression is transparent
	to the client, and the server may choose any mechanism.
	Reading the file returns uncompressed data, and writes to the
	file compresses the data before storing it.

	The 'size' attribute of the file should reflect the
	uncompressed size, and the 'space_used' attribute the number
	of bytes used to store the compressed form.

no_dump		boolean

	The 'nodump' bit advises the server that the file should be
	excluded from backups.

immutable	boolean

	A file with the 'immutable' attribute cannot be modified, even
	by the superuser: it cannot be deleted or renamed, no link can
	be created to this file and no data can be written to the
	file.  All these operations should fail with NFS4ERR_PERM.

	The server may impose restrictions on which users, if any, can
	set or clear this bit.  On Unix systems normally only the
	superuser can modify the immutable bit, and then only in
	certain securelevels.

journal_data	boolean

	If the server filesystem uses a journal, then a file with the
	'journal_data' bit set should have all its data written to the
	journal.

secure_delete	boolean

	The 'secure_delete' bit advises the server that it should try
	to erase the blocks of the file when it is deleted.  This is a
	'best-effort' flag: supporting this bit is not a guarantee by
	the server that it will not be possible to recover deleted files.

sync		boolean

	When a file with the 'sync' attribute set is modified, the
	data and metadata are written synchronously to the disk
	without waiting for a COMMIT operation.

undelete	boolean

	The 'undelete' bit advises the server that the file should be
	saved to support recovery after deletion through some
	mechanism outside of NFSv4.  This is a 'best-effort' flag:
	supporting this bit is not a guarantee by the server that it
	will be possible to recover deleted files.

These attributes will be numbered sequentially starting either at 55,
or at a higher value if some other ammendment adds attributes before
this is accepted.  This means that the attribute names will no longer
be in alphabetical order, but it avoids disrupting existing
implementations.

--------------------

-- 
Martin 
VA Linux Systems

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 23 Jul 2001 09:34:14 -0400

>experienced with NTFS comment on whether they ought to be exported as

Forgive me, but I really do NOT want any further tweaks of the
public vendor-neutral NFS specification to support any firm's
proprietary protocols.  If folks want to run those proprietary
protocols, that is fine and their choice.  However, we ought NOT
be standardising mods to a vendor-neutral IETF specification
that are created solely for one vendor's proprietary implementation.

This kind of gorp is making NFSv4 harder and harder to deploy and
make work successfully in the Internet.  Please don't go there.

Ran
[email-masked]

---

From: Eric Werme USG <[email-masked]>
Date: Mon, 23 Jul 2001 10:20:09 -0400

append_only	boolean

This may be a lot problematic.  NFS client's biods can moderately
scramble write order unless the client only does one write at a time
(e.g. no biods) or the server serializes writes (e.g. some write
gathering implementations).  Another potential out is to define
hole filling as an append, but that would be a tough case to make
as it could impact server FS code.  However, there are worse issues.

The last discussion about this (which I guess assumed synchronous writes
and maybe file locking) centered around guaranteeing "at most once"
semantics.  See
http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2001/0190.html
for lots more.

It also includes discussion about sending append-only access in OPEN,
which would address the Linux O_APPEND issue.

	-Ric Werme

---

From: Brent <[email-masked]>
Date: Mon, 23 Jul 2001 14:52:23 -0700

> make work successfully in the Internet.  Please don't go there.

I think we've already gone there.

The WG charter says "Better cross-platform interoperability"
which is widely interpreted to mean "Better UNIX/Windows
interoperability".  Hence, we have a Windows-style OPEN
with locking and we support Windows-style ACLs.

My (perhaps naive) hope was that NFSv4 would something lighter,
smarter, the intersection of UNIX and Windows feature sets.
But it's hard to deny full feature sets to both UNIX and
Windows users, who expect remote file access to behave like
local file access.  NFS has a difficult time supporting
divergent APIs (POSIX and Win32).  On the other hand, it's
much easier to build a protocol like WebDAV which is not
bound by existing APIs.

When it comes to complexity, I think we're stuck between
a rock and a hard place.  It's difficult to be vendor-neutral
and support Windows.

	Brent

---

From: Eric Werme USG <[email-masked]>
Date: Tue, 24 Jul 2001 10:23:32 -0400

Brent wrote:
   
   RJ Atkinson wrote:
   > proprietary protocols. 

   

Also better WAN support.  NFS V3 won't be going away any faster than V2.
I wouldn't be surprised if we wind up using NFS V3 for LANs, NFS V4 for
WANs.  There's a lot to be said for stuff like passing around binary UIDs &
GIDs when your NIC runs at Gigabit (or higher) speeds and Windows is
something you use at home.

V4 addresses some significant problems, especially with Unix/Windows
interoperability.  Windows isn't going away any time soon, and it's
unlikely Windows will strive for better Unix/Windows interoperability
except to sell more Windows.  (Of course, V4 is meant to help vendors
sell more Unix & filers, so it goes both ways.)

	-Ric Werme

---

From: Brent <[email-masked]>
Date: Fri, 27 Jul 2001 17:32:37 -0700

Hello,

I have attached the draft agenda for London IETF meeting
of the NFSv4 WG.

Make sure you review the working group documents before you come.
The first two rows of the room seating will be reserved for those
who have read the docs!  (document links are available via the
WG web page at

http://www.ietf.org/html.charters/nfsv4-charter.html

Please submit any agenda changes/additions or requests to present to me
([email-masked]) before next Tues, July 30th.

    Brent

8< --------------------------------------------------------

Network File System Version 4 (nfsv4)
-------------------------------------
 
Chair(s):

    Brent Callaghan <[email-masked]>
    Brian Pawlowski <[email-masked]>

Document Editor:

    Spencer Shepler <[email-masked]>

AGENDA:  Monday August 6th: 3:30pm - 5:30 (2 hours)

    Welcome and Introduction            (Callaghan)        5 min

    ONCRPC Standards Update             (Callaghan)        5 min

    Bakeoff at CITI                     (Shepler)         10 min

    Updates to v4 Spec                  (Shepler)         50 min
 
    Working Group Recharter             (Pawlowski)       10 min
 
    Replication and Migration           (Pawlowski)       20 min
 
    General discussion                  (Pawlowski)       15 min
 
    Wrapup                              (Pawlowski)        5 min

-------------------------