linux (but not samba) quotas

[David Collier-Brown]

On Tue, 27 Mar 2001, Jim McDonough wrote:
> > Some time ago, someone presented an interesting situation...suppose the
> > local fs quotas, but not samba quota support, are enabled.  When an NT
> > client tries to write a file too large (say 1MB) to fit within the user's
> > quota (say 4K remaining), the file size is set, then the file is written.
> > An error is returned that the disk is full, but a (sort of) inconsistency
> > arises: the file size appears to be 1MB, but only 4K worth of data is in
> > the file.  Yeah yeah, sparse files and all that, but we've got folks
> > complaining about that.  Since quota support isn't enabled, we can't detect
> > that it won't fit, and we end up with this improper state.  I'd like to
> > propose the following patch that checks to see if the file write failed due
> > to quota limits and truncate the file at the current position.  I don't
> > feel that this is the "right" thing to do, although there may not be a
> > "right" answer.  [...]
 
David Lee wrote:
> In fact, I would suggest that if you have any quotas on any of your
> filesystems anywhere in sight (or even if you don't), you should strongly
> consider using "--with-quotas"  all the time.  Samba's quota support is
> designed to be safe:  if a particular filesystem has quotas, Samba will
> use them;  if it doesn't, then the Samba code will safely "fall through"
> to its usual usage of the "df"-like numbers of your diskspace.


	Regrettably, there is a previously-discussed bug with 
	quotas...  one of the comments in quotas.c is illuminating:

 /* Use softlimit to determine disk space. A user exceeding the quota
    is told that there's no space left. Writes might actually work for
    a bit if the hardlimit is set higher than softlimit. Effectively 
    the disk becomes made of rubber latex and begins to expand to
    accommodate the user :-)
   */

	This reproduces the symptom reported: a file is written,
	sometimes in odd orders, and when closed 
	- appears to be of the desired size, but
	- actually contains "large blocks of nulls" (i.e., is holey)

	There is an error reported to the user, but it seems
	to be one which the user can ignore, and therefor destroy
	their files.

	I've a VxFS site that has this problem, too, so it's not
	peculiar to UFS. I hope to follow up with the list
	when we hear back from the Veritas folks...

	In the meantime, if someone with UFS or ext2fs can reproduce it,
	that would be A Good Thing (;-))

--dave
-- 
David Collier-Brown,           | Always do right. This will gratify 
Performance & Engineering Team | some people and astonish the rest.
Americas Customer Engineering  |                      -- Mark Twain
(905) 415-2849                 | davecb at canada.sun.com