Hi all, I am currently running kernel 2.6.15 on an embedded mips system. I really would like to be able to use the ext4 file system. I can easily upgrade to kernel 2.6.22 but not any further. I would like to get the latest and greatest stable ext4 code onto this box. Is it possible to back-port the latest ext4 code to the 2.6.22 kernel? Or, is there a better way to go about it? Thanks, Nick Hennenfent Cisco IPTV -----Original Message----- From: linux-ext4-owner@xxxxxxxxxxxxxxx [mailto:linux-ext4-owner@xxxxxxxxxxxxxxx] On Behalf Of Theodore Ts'o Sent: Friday, April 03, 2009 3:01 AM To: torvalds@xxxxxxxxxxxxxxxxxxx Cc: Linux Kernel Developers List; Ext4 Developers List Subject: [GIT PULL] Ext3 latency fixes Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git ext3-latency-fixes I posted these patches a while back, and with your "overwrite.c" test case, I decided to see how they did. The results were spectacular enough (see below) that I've decided to request that they be included in 2.6.30. I've posted the critical patches below for review before, and Jan Kara has acked them, and there have been no complaints about them. I've also added two patches which add replace-via-truncate and replace-via-rename workarounds to ext3's data=writeback mode. They only change the behavior in the (currently non-default) data=writeback mode. The benchmark which I used was Linus's overwrite.c as the background workload, and my fsync-tester as the foreground tester. The fsync-tester writes a megabyte to a file and then times how long it takes to fsync that file, and then sleeps a second before repeating. Using an unpatched 2.6.29, fsync-tester shows the following times: fsync time: 3.4732 fsync time: 2.4338 fsync time: 5.9496 fsync time: 6.2402 fsync time: 4.3375 fsync time: 6.3283 fsync time: 3.6930 fsync time: 3.1848 fsync time: 3.3231 The final report of overwrite.c is: 1.984 GB written in 82.75 (24 MB/s) With these patches applied, the fsync-tester times are: fsync time: 1.4538 fsync time: 1.6328 fsync time: 1.4632 fsync time: 1.4550 fsync time: 0.2932 fsync time: 1.6986 fsync time: 0.3787 fsync time: 1.3380 fsync time: 1.8145 fsync time: 0.4050 fsync time: 1.3880 ... and the final report of overwrite.c is: 1.984 GB written in 93.77 (21 MB/s) By having the fsync-related I/O fixed to be posted using WRITE_SYNC, instead of WRITE, it prioritizes the fsync-related I/O so that it gets done ahead of the streaming write. This does slow down the background write process, but it speeds up the worst-case fsync() latency from 6.2 seconds to 1.8 seconds. (Measurements done on a 5400 rpm laptop drive.) All aside from the benchmark improvements, if the writes are coming from fsync(), they really are synchronous operations, and they should be marked that way just from a correctness point of view. - Ted Theodore Ts'o (4): block_write_full_page: Use synchronous writes for WBC_SYNC_ALL writebacks ext3: Use WRITE_SYNC for commits which are caused by fsync() ext3: Add replace-on-truncate hueristics for data=writeback mode ext3: Add replace-on-rename hueristics for data=writeback mode fs/buffer.c | 5 +++-- fs/ext3/file.c | 4 ++++ fs/ext3/inode.c | 3 +++ fs/ext3/namei.c | 6 +++++- fs/jbd/commit.c | 23 +++++++++++++++-------- fs/jbd/transaction.c | 2 ++ include/linux/ext3_fs.h | 1 + include/linux/jbd.h | 5 +++++ 8 files changed, 38 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
