Date: Fri, 19 Mar 2004 16:16:43 -0600 From: Dan Nelson <dnelson@allantgroup.com> To: Claus Assmann <freebsd+fs@esmtp.org> Cc: freebsd-fs@freebsd.org Subject: Re: softupdates and two different MTAs Message-ID: <20040319221643.GA90277@dan.emsphone.com> In-Reply-To: <20040317060617.GA23526@zardoc.esmtp.org> References: <20040317060617.GA23526@zardoc.esmtp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Mar 16), Claus Assmann said: > | program | FS | writes | reads | > |---------------+------------------+---------+-------| > | sm8.12.11 | UFS, softupdates | 236 | 0 | > | sm8.12.11 | UFS, no su | 8100 | 1 | > | sm9.0.0.12 | UFS, softupdates | 3500 | 4 | > | sm9.0.0.12 | UFS, no su | 6300 | 0 | > > Question: why does sm8 use so few writes? Can softupdates eliminate > or cluster most writes including fsync(2)? Why doesn't this work for > sm9? I'm not sure I understand any of those values :) 1000 mails requires at least 3000 fsyncs, doesn't it, one each for qf, df, and tf? And each fsync should write two disk blocks (inode and data). Without softupdates, that should be 12 IO/s per message: create+2*fsync+unlink, once for each of df+qf+tf. Total 12000 I/Os With softupdates, it should be 6: 2*fsync, once for each of df+qf+tf. Total 6000 I/Os So something is either not fsyncing, or there is clustering going on behind the scenes. The sm8 softupdates count is disturbingly low, even assuming good clustering. > I had the following idea why there are so many writes for sm9 > compared to sm8: sm9 has only one SMTP server process and since > fsync(2) is synchronous the process has to wait for it to return. In > sm8 there are many processes which can proceed independently and > softupdates could reorder the operations and perform a "group > commit", i.e., schedule multiple fsync(2) operations together and > then a group of processes can proceed. Theoretically possible. If the files' inodes happen to be on the same disk block, or if they are small messages and the frags happen to be in the same disk block, then an fsync() on one may automatically sync the other files for free. I don't know enough about ffs or softupdates to be able to tell from looking at the source though. You might be able to demonstrate that it's clustering by creating an fsync() wrapper that gets read and write counts before and after the real fsync() call. If you ever call fsync but the I/O counts don't change, then you know that something else synced the file already. -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040319221643.GA90277>