File Size (EOF) and Allocation Size

[Johannes Niess]

Steven French <sfrench at us.ibm.com> writes:

> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202396 and
> >http://lists.samba.org/pipermail/samba/2003-July/099663.html
> 
> Your postings seem to describe multiple issues -

Right. But from a client perspective they are percieved as one: "Samba
eats my files".

> 1) sparse files & exceeding quota (or getting disk full) - I find it
> interesting how Linux filesystems like JFS can automatically treat regions
> of files as sparse but this is normally transparent as long as the app
> doesn't get confused at the concept of getting out of disk space writing to
> the middle of a file.

W2k Explorer seem to be confused. W98SE Explorer does not. Other
client's have not yet been tested.

> 2) mapping POSIX to NT STATUS return codes properly on exceeding quota so
> explorer doesn't get confused copying files (it may turn out that the
> problem with explorer is actually not the return code mapping but failing
> deleting the target file after copy failure)

I've not yet tried moving files. But I'm afraid that it uses the usual
scheme: copy to target; remove source if no error. So you would loose
your only copy of that file.

If Steve is right, W2k Explorer has a "fire and forget" strategy after
"write the last byte". I'll do the samba log traces.

> 
> Although this is not something I have noticed it is fairly easy to
> experiment with by setting Quotas on Windows 200x and Samba and comparing
> network behavior on file copies.  In any case explicit support for setting
> quotas remotely was a feature that I want to add to the cifs vfs eventually
> and that would be a good chance to explore error mapping issues and also I
> need to educate myself on the issue of v2 versus v3 quotas in kernel and
> what Samba really supports.

Do you want level 5 traces against Samba 2.2.3a-debian servers, as
Steve Langasek suggested? I'll test today. I've never heard of v3
quotas. AFAIK we have:

v0: "traditional" 16-bit, accounitng in quota.user, 2.4-mareclos tree up to 2.4.22preX
v1: distribution specific hacks of v0
v2: 32-bit, aquota.user, 2.4-ac tree and latest marcelo-pre
v3: maybe you are taking about Kernel 2.6, it should be similar to v2.

> 
> On the issue of EOF and Allocation Size for the Linux client - I am testing
> the approach of:
> 1) for oplocked files - don't set the file size (except for explicit
> vfs_setatts) to the server.  Let the writebehind of the cache implicitly
> increase the file size
> 2) for oplocked files ignore the file size that comes back from the server
> on inode/dentry revalidates/lookups (trust the local view of the file size
> - it comes back from the NTCreateX open response and is updated when local
> cache write exceeds end of file)
> 3) Apps who desire immediate file size updates and more of a guarantee
> against ever getting "out of disk space on close" can always specify write
> through (which probably now has to be fixed in the cifs vfs code) or
> explicit sync (which does work).

Im my case I can't change the clients. Maybe there are Windows
Registry settings to change error handling?

Thanks a lot for your help.

Johannes Nieß