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
Hi!> 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?Twice a year I fsck my reiser drives, and yes there's some corruption there. So you are right, and its not paranoia. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
On Wed, 2004-03-03 at 18:41, Johannes Stezenbach wrote:> 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: >Jens just sent me an updated version of his IDE barrier code, and I'm adding support for reiserfs and ext3 to it this weekend. It's fairly trivial to add support for each FS, I just don't know the critical sections of the others as well. The SUSE 2.4 kernels have had various forms of the patch, it took us a while to get things right. It does impact performance slightly, since we are forcing cache flushes that otherwise would not have been done. The common workloads don't slow down with the patch, fsync heavy workloads typically lose around 10%. -chris