Subject: RE: [nfsv4] Issue53 - Add data retention support

From: "Yoder, Alan" <[email-masked]>
Date: Mon, 10 Jul 2006 16:09:35 -0700

inline.... 

> -----Original Message-----
> From: Brent Callaghan [mailto:[email-masked]] 
> Sent: Monday, July 10, 2006 12:50 PM
> To: [email-masked]
> Subject: Re: [nfsv4] Issue53 - Add data retention support
> 
> 
> Interesting.  Some questions/comments:
> 
> o Would the retention attribute be advisory or mandatory ?
>     For instance, could a client (or server app) that doesn't know
>     of the attribute just blow the file away anyway ?

   There needs to be a way for servers not to support it
(per exported filesystem I would think), but in servers that do, 
and on "compliance filesystems", the bit is there precisely to
prevent clients or other apps from blowing away files.  Possibly
a new error code would be appropriate.
   The question of whether the bit should follow the file when
it's copied is more interesting.  At present we are thinking that
if a file were copied from one compliance volume to another, the
bit would be preserved; if you want a temporary copy, you have
to copy the file to a non-compliance volume, that doesn't know
about the bit.  But this is client-side behavior.  Can that be
written into the spec?

> 
> o If the file is in the form of a log, then you'd like to retain
>      previous entries, yet be able to add new ones.  The
>      retention attribute would preserve old entries, but prevent
>      the addition of new ones.

   A nice-to-have.  Servers aren't usually in the business of
supporting append-only semantics, are they?  If v4 has that,
then this would be easy.  Otherwise, normal practice is to write
the log, and when you roll over to a new log file, set the retention
stuff on the old one and lock it down.

> 
> o How would the attribute work with a collection of related
>      files in a directory ?  Would it also apply to directories as
>      well as files ?

   In the FCAS space there's no such thing as a directory, so
I don't think it makes that much sense to try and get this to
work with directories.

> 
> o A problem with any new attribute: the attribute is easily lost
>      if archived on a filesystem, archive or device that doesn't
>      know about it, i.e. the retention attribute wouldn't be retained.

   Yep.  Compliance is more involved than just a couple attributes on
a file.  There's a lot of auditing and chain-of-custody stuff that
has to be tracked to have a complete story.  But if the chain of
custody shows a file has always been locked down on a server that
understands these bits, then you can show you've preserved the
file unchanged to the best of your ability.  In the FCAS space
they use digests as a further proof.  In the v4 space a named
attribute could be used to store a digest or any other info that
is deemed necessary to show compliance, in addition to the proposed
attribute and retention time.

> 
> o  How is the attribute an improvement on existing data retention
>      policies, e.g. archival backup, snapshots etc.

   See question 1.  This stuff is based on Netapp experience with
our SnapLock and LockVault products.  Basically, if you want to keep
the stuff in the live filesystem, you need some way of locking it 
down and emulating true WORM storage, a la question 2.

Cheers,

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
===============================================================

> 
> 	Brent
> 
> 
> On Jul 10, 2006, at 11:57 AM, Mike Eisler wrote:
> 
> > Here is an outline of a proposal, which is based on conversations
> > with Alan Yoder and Jay Moorthi of Network Appliance, who work on
> > NetApp's data retention feature. Errors are mine. I'm sure
> > Alan will correct me.
> >
> > My understanding is that Data Retention is a concept that
> > has been driven by legislation and regulations passed by
> > many countries in recent years.
> >
> > The rationale is political and other jurisdictions have
> > decided that some data (e.g. health records) must be retained for
> > a sufficient period of time in order for the stake holders 
> associated
> > with data to not be harmed due to deletion (unintended or otherwise)
> > of the data.
> >
> > I'm told it would be difficult to impossible to normalize all these
> > regulations and support a full range of retention attributes.
> > That seems more like the place for applications using
> > higher level APIs than what NFSv4 is intended to support,
> > such as the work that SNIA is doing (
> > http://www.snia-dmf.org/xam/faq.shtml ). That said,
> > the "low hanging fruit" consists of two attributes:
> >
> > - Retained. This is a boolean attribute. By default it is FALSE.
> >   Once it is TRUE, a file, its named attributes, and some other
> >   attributes, including modification time, change, meta data time,
> >   MUST NOT change, ever. The Retained attribute once set to TRUE,
> >   MUST stay true.
> >
> > - Retention Time. This is a time (date really) to which
> >   a file object (and its named attributes) are guaranteed to
> >   be retained. The value is provisional until Retained is set
> >   to TRUE, and thus has no meaning for compliance with
> >   retention regulations until Retained is TRUE. Once Retained
> >   is set to TRUE, the Retention Time MAY be changed, but it
> >   MUST not be set to a new value less than its current 
> value. Once the
> >   retention time is reached:
> >
> >   - the file MAY be deleted. However, individual named attributes
> >     MUST NOT be deleted.
> >
> >   - the contents of the file, its named attributes, and some
> >     other attributes MUST NOT change as long as the file exists.
> >
> > Normally only the owner of a file can set Retained or 
> Retention Time,
> > though the use of ACLs may extend modification rights for these
> > attributes to other principals. Just having attribute modification
> > rights to the file object does not guarantee the right to set
> > Retained or update Retention Time. NFSv4.1 server implementations
> > MAY support policies that allow the storage administrator to limit
> > the capability of users can set retention attributes (including
> > whether a user can set a retention attribute and the range
> > of retention times).
> >
> > I look forward to discussion on this mailing list. I see
> > I am on the agenda
> > (http://www3.ietf.org/proceedings/06jul/agenda/nfsv4.txt ) to
> > discuss this tommorrow, so I look forward to the discussion
> > in Montreal too.
> >
> >   -mre
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nfsv4
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 11 Jul 2006 07:51:15 -0400

> We don't treat the read or write permission bit attributes on 
> directories differently from regular files, why would we treat 
> retention differently depending on file type?

I'm not proposing that we do these differently.  This is in line
with my proposal about file extension.  The model I'm proposing
would handle both cases based on the destinction between adding
information and modifying it or removing it.

You're point is that these (add to directory and the allowing
appends) stand or fall together, and I agree with that.

I still think my approach is more correct but I can see that
it does add to the complexity of trying to get data retention
support into the protocol, so I'm going to withdraw my suggestion,
at least with regard to v4.1.

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 7:33 AM
To: [email-masked]
Subject: RE: [nfsv4] Issue53 - Add data retention support

--- "Noveck, Dave" <[email-masked]> wrote:

> > Yes that is an interesting point. On the other hand, to implement it

> > requires correct implementation of append writes, which we've punted

> > again for good reasons.
> 
> I don't agree.  What is required is for the simply for the server to 
> distinguish between extend writes and writes that overwrite existing 
> data.

In a one client scenario with parallel write behinds, what will happen
is that when a client goes to fill in a hole with a write behind it find
it cannot because the server will think it is an overwrite.
Of course the client could be changed to see that the
Retain-But-Allow-Extend bit is set, and so it could serialize all its
writes. Which costs performance, and is one of the reasons why we've
punted on correct append writes. But a client shouldn't have to be
re-written to simulate append just because this new attribute is
enabled. 

In a multi client scenario, two clients will choose the same or
overlapping offset at which to extend the file, and one gets an error.
Again it requires a re-write of the client:
- do synchronous, serial writes
- retry writes with a different xid, slot, and offset when it
  gets back the NFS4ERR_RETENTION_NO_OVERWRITE error

Interestingly, Retain-But-Allow-Extend is a way to force clients to do
correct append (assuming I haven't overlooked anything), but result is
bad performance at best and at worst broken clients.

> 
> A solution to the append-write problem would allow appends writes to 
> be successully implemented in a lot more case (where there is active 
> sharing) but that is an orthogonal issue.

Ok, we'll just have to agree to disagree on this one. 

> > As proposed, setting Retain on a directory prevents the directory 
> > from having entries added or removed, but doesn't affect the
> contents
> > of each directory entry. That said, I can see arguments for setting
> 
> > Retain on a group of files, whether it be identified by directory or

> > some other list identifier. However, these arguments could apply
> 
> > to setting of other attributes or other state change.
> 
> It would seem a more useful semantic to allow creation of new files 
> within the directory (but not removal or rename) while setting the 
> retain bit and time for the newly created file based on the attributes

> of the directory.

We don't treat the read or write permission bit attributes on
directories differently from regular files, why would we treat retention
differently depending on file type?

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 13 Jul 2006 15:11:45 -0400

As far as RemoveAt (multi-case attribute names, a v4.1 innovation :-),
while we don't want to specify the mechanisms, I think we can give
some indication that the mechanisms may be more thorough-going
than those for simple file removal.

We need to say something about the permissions model for these
new attributes.  Specifically that ACL may not apply (you can't
prevent adminstrators from setting these attribtes) and they
many not be definitive (there may be other security restrictions
that implementation apply including limitation on the principal,
the specific set of clients, security flavor).  We don't want 
to specify the restrictions but we want to indicate that 
implementations are free to and normally will impose them.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 3:32 AM
To: [email-masked]
Subject: Re: [nfsv4] Issue53 - Add data retention support

On Thu, Mike Eisler wrote:
> 
> 
> > In the case of remove at, the file is removed at the specified time 
> > given that it is greater than the retention time.
> 
> I'm not in favor of a RemoveAt that says the file MUST or SHOULD be 
> automatically deleted by the server. Bugs, administrative errors, etc.
> can lead to data being accidentally deleted in error, which defeats 
> the point of data retention. Also, mandated removal is sometimes 
> associated with regulations for electronic shredding, which is 
> something else we should avoid specifying.
> 
> However, a RemoveAt that just says: this is the date the file should 
> be removed, and leaving it up to mechanisms outside the
> NFSv4.1 specification to do the removal/shred is reasonable. 

This would be useful and fine with me.

Spencer