Subject: Re: [nfsv4] sparse files support for NFS

From: Nicolas Williams <[email-masked]>
Date: Fri, 2 Oct 2009 14:04:13 -0500

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 5 Oct 2009 10:54:11 -0400

> 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:[email-masked]] 
Sent: Friday, October 02, 2009 3:04 PM
To: Marc Eshel
Cc: [email-masked]; Dean Hildebrand
Subject: Re: [nfsv4] sparse files support for NFS

On Tue, Sep 29, 2009 at 10:03:02AM -0700, Marc Eshel wrote:
> 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.

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

---

From: sfaibish <[email-masked]>
Date: Mon, 05 Oct 2009 11:07:08 -0400

> That might make hard to reach a consensus on the compression format.
I should say that using Lempel-Ziv algorithm could get a consensus as we  
all use
it one way or another. As about the on-disk format the biggest question is
block size and if it is fixed or variable. And of course the biggest issue
I can see is the partial file decompression.

> would be interested in coming up with an initial proposal, in the form
I can give it a shot but I need some partners.

-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Network Storage Group

         EMC²
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 5 Oct 2009 10:18:05 -0500

> That might make hard to reach a consensus on the compression format.

As an answer to the sparse file issue, I'm afraid compression is not a
very good one.  Something like SEEK_DATA/SEEK_HOLE would be nicer.  One
could have compression that only works for holes too, I suppose (since
the server likely knows what is and is not a hole it could compress
holes without actually inspecting data block contents).

I see your point about consensus.  We have a filesystem with pluggable
compression functions, which means that whether we can send data blocks
compressed as on-disk will depend on whether the client knows the given
compression (and decompression) function for that filesystem.  The
protocol, if it aims to allow for re-use of on-disk compression, should
probably allow the compression function to be a file attribute, rather
than a filesystem attribute.  One's choice of compression function may
well be, and should be, driven by the type of data one wishes to
compress.  We'd need consensus not so much on a compression function as
on a _set_ of compression functions.  Still, that would be a win,
considering that servers that compress on-disk have to decompress on
READ, but would not have to do so for clients that support the given
compression function.

(What about on WRITE?  Should the client send compressed, and should the
server verify that the compressed data inflates?)

Nico
--

---

From: "Muntz, Daniel" <[email-masked]>
Date: Mon, 5 Oct 2009 11:34:24 -0700

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

> From: Noveck, Dave 
> Sent: Monday, October 05, 2009 7:54 AM
> To: Nicolas Williams; Marc Eshel

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 5 Oct 2009 13:32:46 -0500

> create a similar mechanism for handling compression.

We've discussed stackable GSS-API mechanisms to provide such features as
compression in the KITTEN WG.  It's certainly doable.  But as Dave
points out, the real trick is in re-using whatever compression is done
on-disk to reduce the CPU load ont he server.

(The same does not apply to encryption, for a variety of reasons.)