Date: Thu, 26 Sep 2002 12:21:15 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: freebsd-current@FreeBSD.ORG Subject: Re: Journaled filesystem in CURRENT Message-ID: <3D935E2B.6F50B1DB@mindspring.com> References: <200209251319.g8PDJYoD047918@ib.com.ua> <20020925111232.B3686@Odin.AC.HMC.Edu> <20020926111949.5c0da160.Alexander@Leidinger.net> <20020926090325.A24614@zardoc.esmtp.org> <3D93459B.E4405568@mindspring.com> <20020926113551.A11092@zardoc.esmtp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Claus Assmann wrote: [ ... out of order answer, not related to main topic ... ] > "Per domain" doesn't work easily if you have multiple recipients. > Anyway, the new design clearly distinguishes between the content > files and the data that is necessary for delivery. Actually, it works fine, since it performs queue entry splitting, in the case of multiple recipients. That yields a 100% hit rate for per domain queue traversals, since they contain only messages destined for the domain in question. But back to JFS... [ ... ] > I doubt it. The number of files in the queue directories was fairly > small during the runs. Moreover, ReiserFS showed fairly poor > performance, even though it should be "good" for directory lookups, > right? [ ... ] > Just as a small data point: I get message acceptance rates of > 400msgs/s on a journalling file system (using a "normal" PC) that > writes the data into the journal too. AFAICT that's due to the fact > that fsync() is much fast for this kind of storage. > > The important part for mailservers here is the rate at which content > files can by safely written to disk. From my limited experience > journalling file systems are here much better than softupdates. I didn't realize you qere running in "safe" mode; I should have realized that, since it was supposed to be the only possibility in a future revision, the last time I looked at the particular code in question. I guess I had a stale cache. 8-) 8-). Note that fsync() is a data operation, not a metadata operation, in this case, and what we are talking about is queue contents being committed to stable storage (prior to the "250 Accepted" response, presumably). Yes, soft updates does nothing of user data, it is a metadata technology. Journalling is implementation dependent; not all JFS implementations will journal data which is not metadata, so your results would depend on the JFS. Yes, if your data is journalled, too, then what it means is that an fsync() is, effectively, a noop, since the commit to the stable journal entry is (supposedly) guaranteed before the write call returns. That's a *big* "supposedly", though. Note that this is potentially not a real commit, though, and you would be better off testing with power disconnects on very large queues. The reason for this is that you need to verify that the drives are not, in fact, lying to you, by enabling write caching, and then returning that the data has been committed, when in fact it has not. The difference you are seeing might be attributable to the drive setting for write caching, in the various OSs (e.g. one with it disabled, the other with it enabled). Journalling does not always mean data integrity (it was only ever intended to mean transactional data integrity, in any case, meaning you can and sometimes do lose transactions in event of a failure). If you want to compare apples and apples, you should verify that the data is in fact journalled, that the fsync() actually does what it's supposed to do, if the data is not, and that the code path all the way to the disk supports real commits to stable storage (#1 thing here is: turn off drive write caching in all cases). Large queue testing would show the effects that I've discussed in other emails. I don't think large throughput with short queue depths is representative of mail servers (unless you are an open relay, of course ;^)). I understand the desire for this, though, if you are comparing a 2-file queue to a 1-file queue, given the other effects on deeper queues. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D935E2B.6F50B1DB>