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

From: Erblichs <[email-masked]>
Date: Wed, 04 Feb 2004 11:34:09 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 4 Feb 2004 21:18:10 -0600

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.

---

From: "Benny Halevy" <[email-masked]>
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: [email-masked] [mailto:[email-masked]]On Behalf Of
> Spencer Shepler
> Sent: Wednesday, February 04, 2004 22:18
> To: Erblichs
> Cc: [email-masked]
> Subject: Re: [nfsv4] Regular files and holes (non-contiguous)
> 
> 
>