linux (but not samba) quotas
Cole, Timothy D.
timothy_d_cole at md.northgrum.com
Wed Mar 28 22:56:16 GMT 2001
> -----Original Message-----
> From: Cole, Timothy D.
> Sent: Wednesday, March 28, 2001 17:49
> To: 'David Collier-Brown'; Jeremy Allison
> Cc: David Lee; Jim McDonough; samba-technical at samba.org
> Subject: RE: linux (but not samba) quotas
>
> > -----Original Message-----
> > From: David Collier-Brown [SMTP:davecb at canada.sun.com]
> > Sent: Wednesday, March 28, 2001 17:01
> > To: Jeremy Allison
> > Cc: David Lee; Jim McDonough; samba-technical at samba.org
> > Subject: Re: linux (but not samba) quotas
> >
> > I've been thinking about this for some time,
> > and wonder, from the ongoing discussion,
> > if we could contrive to get the Windows
> > client to
> > a) fail on the write past the end IFF out of space/quota, or
> > b) feel that it's constrained to write the file
> > sequentially.
> >
> > (A) might be achieved by detecting that it's
> > an explicit extend-file operation or a
> > write at a location > (size + amount to be written)
> > and then seeing if it is about to exceed the
> > quote. Note that this assumes the quota/space
> > check is inherently cheap.
> >
> It also assumes that there are no earlier 'holes' in the file.
>
> You can't know much about the 'size' in your formula save that the
> actual space allocated on disk is <= that size.
>
Actually, (A) is just over-conservative. Which is OK (you don't
know whether the client intends to actually write to all the new blocks it's
allocated either anyway). But (B) is better, especially as Jeremey's
apparently nailed that down already.
More information about the samba-technical
mailing list