From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Tso Subject: Re: Samba speed Date: Tue, 9 Dec 2008 01:06:50 -0500 Message-ID: <20081209060650.GD10270@mit.edu> References: <20081208182114.GD29163@samba1> <20081208223924.GB2501@mit.edu> <20081208231233.GK29163@samba1> <20081208233802.GD2501@mit.edu> <20081209003701.GE16818@webber.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jeremy Allison , samba-technical@samba.org, linux-fsdevel , linux-cifs-client@lists.samba.org To: Andreas Dilger Return-path: Received: from BISCAYNE-ONE-STATION.MIT.EDU ([18.7.7.80]:61497 "EHLO biscayne-one-station.mit.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751073AbYLIGLk (ORCPT ); Tue, 9 Dec 2008 01:11:40 -0500 Content-Disposition: inline In-Reply-To: <20081209003701.GE16818@webber.adilger.int> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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