Samba seems to behave incorrectly when writing beyond the current end of file

[David Collier-Brown]

Richard Sharpe wrote:
> After further testing, I have seen Win2K use the following strategy
> against Samba when writing a 12MB file in 64kB chunks (that is, the
> application was writing in 64kB chunks):
> 
> 1. Open File requesting OpLock, exclusive was granted.
> 2. Write 1 byte at offset 1114111
> 3. Query file standard info for EOF
> 4. Write 1 byte at offset 1114111+64kB
> 5. Query file standard info for EOF
> 6. Write 1 byte at offset 1114111+64kB+64kB
> ...
> 
> Now, it seems to me that Windows is using those 1 byte writes to provoke
> EXQUOTA and ENOSPC errors so they can be accurately reflected to the
> application. However, this is not going to work under default UNIX because
> it will write holes, and will probably only allocate one 4kB block per 1
> byte write.

	Hmmn, a while ago I did a one-off performance patch for the Sun
	"qfs" high-performance filesystem, which as an accidental
	side-effect would have written stripe-size, aligned blocks
	including the one-byte locations.

	The performance gain with the patch was non-trivial because qfs
	is sensitive to read/write alignment. So, by the way, is the
	future ZFS, if I read the description correctly.

	A short test with a pair of ordinary filesystems, ext2 and
	Solaris ufs, showed a good performance improvement with
	large, aligned read/write buffers, just not the improvement
	from pessimal to optimal I saw from qfs (;-))

	I'm wondering if a back-end which defaults to a 64 kB write
	size would both
	- cause file preallocation and
	- improve filesystem performance enough to offset the
	  cost of the file-filling...

	I have a Samba VFS in draft which does this kind of I/O,
	but Sun laid me off before I could finish testing  it (:-()

--dave
--
David Collier-Brown,  | Always do right. This will gratify
davecb at spamcop.net    | some people and astonish the rest
                       |                      -- Mark Twain