I'll add the write caching into the test just for info. Until there
is a way to guaranty the data is safe I'll have to go with no write caching
though. I should have all this testing done by the end of the week.-----Original Message----- From: Chris Mason [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 6:00 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [reiserfs-list] fsync() Performance Issue On Fri, 2002-05-03 at 16:35, [EMAIL PROTECTED] wrote: > Chris, I have some quick preliminary results for you. I have > additional testing to perform and haven't run debugreiserfs() yet. If you > have a preference for which tests to run debugreiserfs() let me know. > Base testing was done against 2.4.13 built on RH 7.1 using the > test_writes.c code I forwarded to you. The system is a Tyan with single > PIII, IDE Promise 20269, Maxtor 160GB drive - write cache disabled. All > numbers are with fsync() and 1KB files. As I said, more testing, i.e. > filesizes, need to be performed. > 2.4.19-pre7 speedup, data logging, write barrier / no options > => 47.1ms/file Hi Wayne, thanks for sending these along. I expected a slight improvement over the 2.4.13 code even with the data logging turned off. I'm curious to see how it does with the IDE cache turned on. With scsi, I see 10-15% better without any options than an unpatched kernel. > 2.4.19-pre7 speedup, data logging, write barrier / data=journal > => 25.2ms/file > 2.4.19-pre7 speedup, data logging, write barrier / data=journal,barrier=none > => 27.8ms/file The barrier option doesn't make much difference because the write cache is off. With write cache on, the barrier code should allow you to be faster than with the caching off, but without risking the data (Jens and I are working on final fsync safety issues though). Hans, data=journal turns on the data journaling. The data journaling patches also include optimizations to write metadata back to disk in bigger chunks for tiny transactions (the current method is to write one transaction's worth back, when a transaction has 3 blocks, this is pretty slow). I've put these patches up on: ftp.suse.com/pub/people/mason/patches/data-logging > One question is will these patches be going into the 2.4 tree and > when? The data logging patches are a huge change, but the good news is they are based on the nesting patches that have been stable for a long time in the quota code. I'll probably want a month or more of heavy testing before I think about submitting them. -chris
