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 -- 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
