RE: [nfsv4] Regular files and holes (non-contiguous)

bhalevy@panasas.com

From: "Benny Halevy" <bhalevy@panasas.com>
Subject: RE: [nfsv4] Regular files and holes (non-contiguous)
Message-ID: <LCEAJMHHKPKEPAIDBBEKOEPICAAA.bhalevy@panasas.com>
Date: Wed, 4 Feb 2004 22:28:17 -0500

Note also that when the file size is extended by SETATTR the protocol
is saying that the server is free to either allocate storage for
the extended byte range or leave it as a hole as long as the range
between the current end of file to the new end of file after SETATTR
is implicitly filled with zeroes as in:

   ... a size greater than the
   current size of the file causes logically zeroed data bytes to be
   added to the end of the file.  Servers are free to implement this
   using holes or actual zero data bytes. Clients should not make any
   assumptions regarding a server's implementation of this feature,
   beyond that the bytes returned will be zeroed.  Servers must support
   extending the file size via SETATTR.

> -----Original Message-----
> From: nfsv4-admin@ietf.org [mailto:nfsv4-admin@ietf.org]On Behalf Of
> Spencer Shepler
> Sent: Wednesday, February 04, 2004 22:18
> To: Erblichs
> Cc: nfsv4@ietf.org
> Subject: Re: [nfsv4] Regular files and holes (non-contiguous)
> 
> 
> 
> The protocol allows for writes to any offset within the server's
> support maximum file size.  Write do not have to be done
> contiguously; the same has been true of NFSv2/v3.
> 
> There is no protocol mechanism for determining if a hole exists
> in a particular file.  If the client reads a range of the file that is
> actually a hole, the client will be returned nulls for that data range.
> Again, this has been the case for NFSv2/v3.
> 
> You will also note that there is no way delete a range of a file
> or effectively punching a hole in the file.
> 
> On Feb 4, 2004, at 1:34 PM, Erblichs wrote:
> 
> > Hi group,
> >
> > 	I must be going blind, but I don't see the NFSv4 spec
> > 	covering how to do the opposite functionalities when
> > 	it comes to holes.
> >
> > 	FYI, holes are caused when a regular file has multiple
> > 	operations where a byte has been written at a specific
> > 	offset and then the offset has been increased and
> > 	additional writes are done.
> >
> > 	The creation of a hole is done to allow a regular file
> > 	object to be created that is larger than the FS itself
> > 	and/or to minimize the allotment of file system pages
> > 	for non contigous pages. These holes also should decrease
> > 	the amount of time for the writes to occur.
> >
> > 	However, if this hole is written with NULLs or whatever,
> > 	then a reservation mechanism is encountered as a secondary
> > 	effect.
> >
> > 	So, with the spec, am I missing something that allows me
> > 	to specify commit of previous writes to the regular file with
> > 	and without holes.
> >
> > 	Thanks,
> > 		Mitchell Erblich
> > 		Sr. Software Engineer
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nfsv4
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4