Messages in this thread | | | From | safemode <> | Subject | Re: time tells all about kernel VM's | Date | Wed, 24 Oct 2001 14:36:19 -0400 |
| |
On Wednesday 24 October 2001 14:05, Luigi Genoni wrote: > On Wed, 24 Oct 2001, safemode wrote: > > ok. Reran e2defrag and got the same effect. > > This is the vmstat output by the second. It starts out with my normal > > load (but no mp3s playing). Then i start e2defrag with the same > > arguments as before and allow it to run all the way through. It ends but > > i dont close it until near the very end (which is seen by the swap > > dropoff. Then i let my normal load again be displayed a bit. One thing > > i did notice, however, was that the vm handled that quite a lot better > > than how it handled it after being up for 5 days even though it created > > the 600MB of buffer. > > If I do remember well e2defrag was working just with ext2 with 1k as block > size, and latest version compiled with 2.0.12 kernel, (I made also a patch > to compile with 2.0.X kernels after), then ext2 simply evolved and > e2defrag did not. (by the way e2defrag sources are really isstructive to > learn how a blockFS works).
e2defrag defaults to 4k blocks. Version 0.73pjm1 30 Apr 2001
> I used e2defrag since earlier versions, (just with old slow disk, now it > is almost useless, and I went to journaled FSes). If I do remember well, > the behavoiur you are telling was usual with 2.0 kernels. > If the pool is to big, i saw that e2dump shows a lot of inode that left > their group (sic!), and also there could be some FS corruption. > e2defrag was writter to use buffer cache, and now VM changed in details > this behaviour. It could be that what you see is due to those changes?
you say it is the same behavior as 2.0 yet you say that i could be seeing this problem due to _changes_ in the vm. So the comparison to 2.0 doesn't really tell us anything since it has nothing to do with what 2.0 was doing.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |