Peter Nelson wrote: > Hans Reiser wrote: > > >Are you sure your benchmark is large enough to not fit into memory, > >particularly the first stages of it? It looks like not. reiser4 is > >much faster on tasks like untarring enough files to not fit into ram, > >but (despite your words) your results seem to show us as slower unless > >I misread them.... > > I'm pretty sure most of the benchmarking I am doing fits into ram, > particularly because my system has 1GB of it, but I see this as > realistic. When I download a bunch of debs (or rpms or the kernel) I'm > probably going to install them directly with them still in the file > cache. Same with rebuilding the kernel after working on it. OK, that test is not very interesting for the FS gurus because it doesn't stress the disk enough. Anyway, I have some related questions concerning disk/fs performance: o I see you are using and IDE disk with a large (8MB) write cache. My understanding is that enabling write cache is a risky thing for journaled file systems, so for a fair comparison you would have to enable the write cache for ext2 and disable it for all journaled file systems. It would be nice if someone with more profound knowledge could comment on this, but my understanding of the problem is: - journaled filesystems can only work when they can enforce that journal data is written to the platters at specifc times wrt normal data writes - IDE write caching makes the disk "lie" to the kernel, i.e. it says "I've written the data" when it was only put in the cache - now if a *power failure* keeps the disk from writing the cache contents to the platter, the fs and journal are inconsistent (a kernel crash would not cause this problem because the disk can still write the cache contents to the platters) - at next mount time the fs will read the journal from the disk and try to use it to bring the fs into a consistent state; however, since the journal on disk is not guaranteed to be up to date this can *fail* (I have no idea what various fs implementations do to handle this; I suspect they at least refuse to mount and require you to manually run fsck. Or they don't notice and let you work with a corrupt filesystem until they blow up.) Right? Or is this just paranoia? To me it looks like IDE write barrier support (http://lwn.net/Articles/65353/) would be a way to safely enable IDE write caches for journaled filesystems. Has anyone done any benchmarks concerning write cache and journaling? o And one totally different :-) question: Has anyone benchmarked fs performance on PATA IDE disks vs. otherwise comparable SCSI or SATA disks (I vaguely recall having read that SATA has working TCQ, i.e. not broken by design as with PATA)? I have read a few times that SCSI disks perform much better than IDE disks. The usual reason given is "SCSI disks are built for servers, IDE for desktops". Is this all, or is it TCQ that matters? Or is the Linux SCSI core better than the IDE core? Johannes _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
