Problems with Samba 2.2.0 on Solaris 8 with quotas

[Shirish Kalele]

David,

I have a fix for 2.0.9 based on the description. With the fix, samba does a
disk space check on every zero byte write. I've also fixed the
delete-on-close behaviour in 2.0: propagating delete-on-close flags to all
share mode entries for the file, setting it on a TRANS2
SET_FILE_DISPOSITION_INFO call, checking delete-on-close flags before doing
any oplock-processing on opens, sending delete-pending errors on opens etc.
Since there won't be further releases of the 2.0 tree, I was wondering if I
should check these fixes into 2.0?

Also, I don't know if Jeremy is okay with doing space-checks on zero-byte
writes.

Regards,
Shirish

----- Original Message -----
From: "David Collier-Brown" <davecb at canada.sun.com>
To: "Shirish Kalele" <kalele at veritas.com>
Cc: "Toni Verdu Carbo" <toni at silver.udg.es>;
<samba-technical at lists.samba.org>; "Fred Weigel"
<fredw at opcom-mail.canada.sun.com>
Sent: Thursday, June 14, 2001 7:21 AM
Subject: Re: Problems with Samba 2.2.0 on Solaris 8 with quotas


> Shirish Kalele wrote:
> > This might not be related to Toni's problem, but I also found some
> > redirectors that did this in such a scenario (nearing quota limits or
disk
> > space limits):
> >
> > 1. First they try doing a zero-byte write to an offset equaling the size
of
> > the file being written (copied).
> > 2. NTFS seems to allocate space at this point itself, so NT servers
return
> > an NT_STATUS_DISK_FULL error here.
>
> Yes, that's explicitly what we saw happening
> the first time I got involved with this.
>
> Jeremy and the team doped out the rest...
> > 3. The client then sets the delete-on-close flag on the file.
> > 4. Some RDRs then close the file. Others seem to try to open the file
again
> > and expect to see an NT_STATUS_DELETE_PENDING error denied them the
open.
> > This convinces them that the flag has been set and they then close the
file.
> >
> > Samba 2.2.0 currently returns a disk-full error when the actual data is
> > being written to the file and when this write fails with a
quota-exceeded or
> > no-space error from the OS.
> >
> > However, some redirectors that do the above seem to depend only on the
> > zero-byte write to decide if there is enough space or not. They don't
handle
> > failures at a later point (when the actual data writes occur). This
leaves
> > sparse files on the server.
>
> This is a lot better than the problem looked the
> first time we saw it: we suspected we'd have to
> either expand every file when asked, keep around
> a "free space left" datum from statvfs or fail.
>
> The description above would allow us to do one
> check (fstafvfs, for example) if and only if there
> was a zero-byte write at the end of the file,
> not have to keep any information, and just return
> a NO_SPACE failure...
>
> ...  a quick test with gethrtime on Solaris showed that
> the overhead of fstatvfs is extremely low, as the superblock
> is in memory . It's smaller that my timer's resolution!
>
> > I know Jeremy thinks doing space checking on zero-byte writes would slow
> > things down. But how frequent are these zero-byte writes?
>
> I don't know that, nor do I know the speed of the
> SGI/AIX/HPUX/whatever equivalents of fstatvfs. I
> suspect they're pretty blinding, but I don't know that.
>
> --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
>