On Thursday, June 14, 2001 12:54:11 PM +0200 Dirk Mueller <[EMAIL PROTECTED]>
wrote:
> On Don, 14 Jun 2001, grobe wrote:
>
>> I have a significant loss of performance in bonnie tests. The "writing
>> intelligently"-test
>> e.g. gives me 20710 kB/s with reiserfs, while I get 24753 kB/s with ext2
>> (1 GB-file).
>
> well, when writing files, reiserfs has to do _journalling_, which
> requires some writes as well, so its pure natural that it is a bit
> slower. You can watch the HDD activity LED - if its constantly on then
> its the disc that is saturated and therefore the limiting factor and not
> reiserfs. If you want journalling, i.e. no fsck after boot, then you
> have to accept _somewhere_ a _slight_ disadvantage. The question is if
> its really common for your setup that the disc gets hammered with 100%
> write request. Experience shows that its usually 90/10 distributed, that
> means 90% reads and 10% writes. So we're talking about a performance
> drop of 2 percent for writes - something that you won't notice in
> real-life, not to mention that reiserfs is for reads and for
> creating/deleting files several magnitudes faster.
The performance depends on workload, but there is still room for
improvement in reiserfs read and write performance.
One issue is the journal code isn't taking advantage of the prepare_write,
and commit_write address space operations. We'll start a transaction
during prepare_write, close it, then end up starting another one during
commit_write to log the atime update.
This can be improved by allowing recursive transactions, which we also need
for a few other fixes...I hope to finish it today and get final testing
over the weekend. It's kinda cool.
Zam is already working on the block allocator, I'm sure it'll be cleaner
and faster when he's done.
>
> Chris Mason has lately written a patch to improve the performance of file
> writes (especially for concurrent writes as it removes some global kernel
> locks if I understand him correctly) performance. It is beta quality, as
> it was never included in any official kernel (nor -ac) yet, but I'm
> using it for a few weeks now without the slightest problem. You can find
> it in the mailing list archive (search for "pinned pages") or I can send
> it to you if you're adventorous enough to try it out - YOU've BEEN
> WARNED.
;-) This should be in the next ac kernel, a few others have tested it and
reported good results. But, I don't expect it to have a huge performance
impact on bonnie tests (where the inode is logged in commit_write anway).
-chris
