On Tue, Dec 9, 2008 at 5:06 PM, Theodore Tso <tytso@xxxxxxx> wrote: > 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 > Its not as simple as "the redirector does it every 128k". the redirector does this but it varies from run to run and from client to client. It is very common to see this happening in 60-64kb strides and other strides as well. It is probably some interaction with how large the actual i/o that the application did internally to the cache and some other thing. but anyway, it varies a lot. it is not always 128k. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
