Thanks for the quick reply,
But still if we see the writes happening at the end of I/O for each we see that ext2 dispatches in terms of 1024 sectors only which least need to be merged, But the ext3 produces I/O in 4 sectors that are eventually merged to form a bigger IO. This can been seen from the merged
count in ext2 and ext3. I doubt if it was been writing journal at that time the I/O could not be merged.
But we see that happening in case of ext3.
Please allow me to know if I am wrong.
Thanks
Dinesh K B
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, May 30, 2007 at 12:48:22PM +0530, Dinesh K B wrote:
> I am novice kernel programmer. My name is Dinesh and I am from India.
> Well last day I was experimenting with blktrace utility benchmarking
> current file system. I had a strange observation with regarding ext2 and ext3.
> With the latest blktrace dated 21-May, the I obtained following logs
> for
> ext2 and ext3.
[...]
> Even if the I/O queued and dispatched are almost same for both ext2
> and ext3, the number of commands queued and dispatched is different for both.
>
> For ext3 Number of writes queued = 11,419 K, writes dispatched = 97,257.
>
> For ext2 Number of writes queued = 316,003, writes dispatched = 104,976.
>
> I am not able to understand why ext3 filesystem is queuing so many I/Os.
ext3 might have the same on-disk structure as ext2, but it is a different filesystem. Things that will make a difference:
- - journalling
- - htree directory index
I guess writing the journal will make the largest difference: every write that changes metadata will have to go through the journal.
Erik
- --
They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGXVnB/PlVHJtIto0RAnA+AJ9YjVghmR3jEAeQ4p4tHpwc4eyhMwCfY4KM
sui/t0E+Ghga6HC2HJmqAw0=
=grHF
-----END PGP SIGNATURE-----
