File Size (EOF) and Allocation Size
sfrench at us.ibm.com
Wed Jul 30 02:38:03 GMT 2003
I noticed that set allocation size in smbd/vfs.c does not really set
anything (unless the file shrinks, in which case truncate is called).
This is probably the best that one can do on standard Unix-like OSs, but is
an interesting problem.
The man page for write (2) states that when writes are not sent
writethrough that certain "buggy implementations" sometimes do not reserve
space when writes occur (which can cause out of disk space to be reported
on close) due to write behind.
There are a couple of approaches clients could take for handling this
gracefully when files are oplocked.
When r/w oplock held, never send implicit file size changes except explicit
setattrs. When the file is closed at the client, the client will send
the writes (through the page manager on the client) which will set the file
size. This requires that the client never reset the file size from the
server (after the file has been oplocked) i.e. the client should not use
the file size that comes when the inode info is revalidated (from issuing
QPathInfo to the server) every few seconds or so - but the client should
not ignore uid & gid & mode because presumably changing those on the server
do not trigger an oplock break to the client so the client needs to
overwrite uid/gid/mode if they have changed.
The other approach is much uglier - change the file size explicitly if a
write would cause the file size to grow (still cache the write itself) -
this has the drawback that for a series sequential writes - extending the
filesize is almost as expensive as writing the data in the first place and
it is especially painful if the app is doing 1 byte writes repeatedly past
end of file (since without setting the file size explicitly on every write
the size would only be increased in 4K chunks - once each time a page is
written out which is a lot more efficient but unfortunately means that the
server space reserved for the file can be very, very stale leading to more
out of disk space risks)
Senior Software Engineer
Linux Technology Center - IBM Austin
email: sfrench at-sign us dot ibm dot com
More information about the samba-technical