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

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 10 Jul 2006 19:11:26 -0400

> > 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.

> 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.

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.

> > 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 ?

> 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.

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Monday, July 10, 2006 4:33 PM
To: [email-masked]
Subject: Re: [nfsv4] Issue53 - Add data retention support

--- Brent Callaghan <[email-masked]> wrote:
Brent Callaghan <[email-masked]> wrote:

Brent,

Thanks for the fast feedback.

> 
> 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 ?

Mandatory. A client that doesn't know about the attribute doesn't get to
skirt the legal framework these attributes are intended to support.

Think of this as simulating a blank CD-R, only much more flexible.

> 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.

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. 

> 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 ?

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.
So I would prefer to see a general mechanism for changing a set of file
objects, versus a single mechanism for these two attributes.

> 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.

Yes. But the data still persists on the primary until there is a
disaster. 

Presumably the regulatory requirements would (or will someday) compel
the customers of this feature to have a disaster recovery plan in
compliance with Retention regulations. E.g. use archival/backup systems
that preserve the retention bit. It is beyond the scope of the NFSv4.1
protocol to enforce that.

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

I can delete archived backups, snapshots, etc., but short of violence
rendered upon the storage subsystem, I can't delete Retained data.
Thus Retention is aligned with legal requirements, and snapshots, etc.
are not. 

_______________________________________________
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: Mike Eisler <[email-masked]>
Date: Tue, 11 Jul 2006 04:32:32 -0700 (PDT)

> to distinguish between extend writes and writes that overwrite

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.

> active sharing) but that is an orthogonal issue.

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

> retain bit and time for the newly created file based on the

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: Benny Halevy <[email-masked]>
Date: Tue, 11 Jul 2006 07:38:21 -0400

> retention differently depending on file type?

There's no "delete data" operation on files.
Second, it occurs to me that a "retain" flag on ACEs would be
more flexible than an whole attribute and would allow the application
to choose what permissions it would to retain forever.

Benny

Mike Eisler wrote:

>>>>     files in a directory ?  Would it also apply to directories
>>>>        
>>>>
>>as
>>    
>>
>>>>     well as files ?
>>>>        
>>>>
>>>from having entries added or removed, but doesn't affect the
>>>      
>>>
>>contents 
>>    
>>

---

From: Benny Halevy <[email-masked]>
Date: Tue, 11 Jul 2006 07:39:42 -0400

> There's no "delete data" operation on files.

that is, partial delete of data course :-)

>>> 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.
>>>   
>>
>>
>> behind it find it cannot because the server will think it is an 
>> overwrite.
>> or overlapping offset at which to extend the file, and one gets an 
>> error. Again it requires a re-write of the client: