On Fri, Feb 3, 2012 at 3:49 PM, Kazuya Mio <k-mio@xxxxxxxxxxxxx> wrote: > 2012/02/03 7:36, Andreas Dilger wrote: >>> >>> filesystem time(sec) call extX_mark_inode_dirty(times) >>> --- >>> ext3 220.5 50,338,104 >>> ext3 (patched) 196.3 25,169,658 >>> ext4 (*1) 190.3 28,465,799 >>> ext4 (*2) 201.5 27,963,473 >>> ext4 (default) 223.3 14,026,118 >>> >>> *1 disable ext4-specific options (delalloc, extent, and so on) >>> *2 disable only delalloc option >> >> This shows that ext4 with extents+delalloc is _slower_ than ext3, which >> is very strange. In other similar tests of write performance (see > > > One more thing is that ext4+delalloc is slower than ext4+nodelalloc. And according to the data, maybe ext4+extent is also slower than ext4+noextent. What's the size of the fs? and what kind of the tested device? Yongqiang. > > >> http://downloads.linux.hp.com/~enw/ext4/3.2/large_file_creates.html, >> showing multi-threaded 1GB file writes) ext4 is much faster than ext3. > > > I guess write buffer size of my test is different from ffsb's one. > My test calls write systemcall every time one block is allocated, > so it is close to the stress test I think. > > >> Looking at your original email, is ext4 being tested on a RHEL 5.5 >> (2.6.18) kernel, or a more recent kernel? It would be more useful >> to run this on a more modern kernel, since the ext4 code backported >> to RHEL5 was barely supporting delalloc at all, if I remember correctly. > > > I tested on the recent kernel (3.3-rc1). > I also tested on RHEL5.5, and its result showed that ext3 was much slower > than > the recent kernel's one. > > filesystem time(sec) > --- > ext3(RHEL5.5) 438.6 > ext3(3.3-rc1) 220.5 > > Regards, > Kazuya Mio > > -- > 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 -- Best Wishes Yongqiang Yang -- 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
