Subject: RE: more recommended attributes?

From: "dshaffer" <[email-masked]>
Date: Mon, 23 Jul 2001 08:51:19 -0500

I am not clear if you are objecting to the entire draft of file
system attributes or just the ones applicable to NTFS. Adding the NTFS
attributes is no different than adding the "journal_data" attribute that
is applicable to only certain file systems. I believe one of the goals
for V4 was to have more robust file system support and not be quite so
'Unix centric' in this area. There is no compelling reason that I can
see to leave NTFS attributes out of this.

Dan

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Monday, July 23, 2001 8:34 AM
To: Martin Pool
Cc: [email-masked]
Subject: Re: more recommended attributes?

At 00:31 23/07/01, Martin Pool wrote:
>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.

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: RJ Atkinson <[email-masked]>
Date: Mon, 23 Jul 2001 10:31:10 -0400

At 09:51 23/07/01, dshaffer wrote:

>is applicable to only certain file systems. 

        Those for NTFS are different in that that is a single
vendor proprietary approach.  There are several different kinds
of journaling file systems, which can all use the journal_data
attribute even though they are different implementations from
different vendors with different properties.

        That noted, my druthers is to drop the whole draft.

>I believe one of the goals

        Operational complexity of NFSv4 is already very MUCH higher
than for NFSv3.  This draft significantly increases the operational
complexity.  We really ought NOT be doing this to NFS.  Vendors have
largely ignored user input like mine for a while now.  I just wonder
whether they realise how all this complexity will drive people towards
simpler operational approaches that do NOT involve NFS.

Ran
[email-masked]