Re: [nfsv4] sparse files support for NFS

["Muntz, Daniel" <Dan.Muntz at netapp.com>]

Compression could be treated as a form of encryption...  Reuse the
existing rpcsecgss infrastructure to implement it.  Or, less hackish,
create a similar mechanism for handling compression.

  -Dan

> -----Original Message-----
> From: Noveck, Dave 
> Sent: Monday, October 05, 2009 7:54 AM
> To: Nicolas Williams; Marc Eshel
> Cc: nfsv4 at ietf.org; Dean Hildebrand
> Subject: Re: [nfsv4] sparse files support for NFS
> 
> > Compression would also be nice.
> 
> The issue is going to be to define the compression/decompression
> algorithm.  There's going to be tradeoff's of decompression effort vs.
> compression intensity.  The other issue is going to be that there are
> are a number of on-disk compression schemes.  Obviously if 
> your on-disk
> compression matches the OTW compression your server's work is 
> minimized.
> That might make hard to reach a consensus on the compression format.
> 
> But I think there are important benefits and it would be good 
> if someone
> would take this on.  It is interesting.  Is there anybody out 
> there, who
> would be interested in coming up with an initial proposal, in the form
> of an individual draft?
> 
> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams at sun.com] 
> Sent: Friday, October 02, 2009 3:04 PM
> To: Marc Eshel
> Cc: nfsv4 at ietf.org; Dean Hildebrand
> Subject: Re: [nfsv4] sparse files support for NFS
> 
> On Tue, Sep 29, 2009 at 10:03:02AM -0700, Marc Eshel wrote:
> > The proposal is to modify the READ RPC to avoid reading the 
> holes in 
> > sparse file. First step a very simple one, instead of returning a 
> > block of zeros, just return a return code E_HOLE and avoid 
> > transferring a lock of zeros over the network. Step two can also 
> > provide additional information along with the E_HOLE return code to 
> > specify the offset of next data chunk and the length of it. 
> Step three
> 
> > would be to use pNFS layouts to describe the holes in the file and
> avoid reading them by the client all together.
> 
> Solaris has an lseek(2) extension for getting at hole layout
> information: a pair 'whence' values, SEEK_HOLE and SEEK_DATA that
> indicate that the system should seek to the next hole/non-hole.
> 
> A way to do that in NFS would be nice.
> 
> Compression would also be nice.
> 
> Nico
> --
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>