Re: Samba speed

[Theodore Tso <tytso@MIT.EDU>]

On Mon, Dec 08, 2008 at 04:37:01PM -0800, Andreas Dilger wrote:
> On Dec 08, 2008  18:38 -0500, Theodore Ts'o wrote:
> > On Mon, Dec 08, 2008 at 03:12:33PM -0800, Jeremy Allison wrote:
> > > 
> > > Turns out that ext4 doesn't suffer from the slowdown in the
> > > first place. The paper is extremly interesting, I'm looking
> > > at the implications for our default settings (most users
> > > are still using Samba on ext3 on Linux).
> > 
> > I thought the paper only talked about ext3, and theorized that delayed
> > allocation in ext4 might be enough to make the problem go away, but
> > they had not actually done any measurements to confirm this
> > supposition.  Has there been any more recent benchmarks comparing
> > ext3, ext4, and XFS running Samba serving Windows clients?
> 
> It wouldn't be a bad idea to use this hint in the kernel to call
> fallocate(), given the fact that this is used by a number of apps
> (i.e. all of them) that predate fallocate().

What, a one byte write that extends a file should be translated into
an fallocate()?  How.... crude.  The question is, do we really want to
be encouraging Microsoft in that way?  :-)

Also, as it turns out, Microsoft is only doing this every 128k (i.e.,
touch one byte 128k after the end of the file, then write 128k of
data, then write another 1 byte of garbage 128k past the end of the
file, etc.), so ext4's delayed allocation algorithms seems to be able
to handle things just fine.

I also suspect that if someone tried recompiling a kernel changing the
value of EXT3_DEFAULT_RESERVE_BLOCKS from 8 to 32, or changing Samba
to use the EXT3_IOC_SETRSVSZ ioctl immediately after opening a file
for writing to set the block allocation reservation size for that
inode to 32 blocks (128k), this might also enough of a kludge to solve
most of the performance problems of Samba running on ext3 versus a
Windows XP client.  If someone *does* manage to try this experiment,
please us know if it works...

					- Ted