lkml.org 
[lkml]   [2001]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] 2.4.10 improved reiserfs a lot, but could still be better
Date
On Monday 24 September 2001 08:32 am, Matthias Andree wrote:
> On Mon, 24 Sep 2001, Beau Kuiper wrote:
> > Also, the performace problems seem to be very dependant on the
> > hardware being used. 5400rpm drives get hurt a lot, while 7200 rpm
> > drives seem to handle it better. Decent write caching on IDE
> > devices (like the 2meg buffer on the IBM) can completely hide this
> > issue.
>
> Decent write caching on IDE devices can eat your whole file system.
>
> Turn it off (I have no idea of internals, but I presume it'll still
> be a write-through cache, so reading back will still be served from
> the buffer). Do hdparm -W0 /dev/hd[a-h].

I'm sorry, but that's not acceptable.
Please note the dd timings at the bottom of this message.

This is consistant with real workload on my and other peoples systems,
200-300MB+ files, clear up to 1GB+ files are at times ROUTINE for
writing. This is esspecialy applicable if dealing with disk images, etc.
Disabling write cache creates times that are twice as large or more
than WITH write cache. Unless the system or drive has a serious,
SPECIFIC fault with its write cache, disabling it can cause an
unacceptable performance hit.

Yes, a typical desktop user isn't going to notice much, even a normal
webserver or fileserver not dealing with constant updates may not, but
certain workloads will. These workloads are real enough that telling
people to disable write caching out of hand is a bad idea.
There's no way in hell I'm going to accept having my performance cut in
half or more on my daily workload due to the remote possibility that
something may happen to my data/filesystem in mid-write. That's what
the cheap little UPS sitting beside my desk that gives me ample time to
power down is for.
Short of a catastrophic power supply, motherboard, or other component
failure (which often stands a good chance of destroying the drive
anyway), a power failure is the main problem here.
Keep in mind also, that you may be putting your data and filesystems in
more risk by not using a write cache as with using it.



(below timings are all on an IBM 75GXP DTLA-307045, 46.11BB("GB")
7200RPM ATA/100 drive on an off-board Promise Ultra/100 (ATA/100)
controller on an 800Mhz Athlon 100Mhz FSB PC100 RAM CAS3@100Mhz.)

root@c779218-a:/home/nnkk# hdparm -W0 /dev/hde

/dev/hde:
setting drive write-caching to 0 (off)
root@c779218-a:/home/nnkk# time dd if=/dev/zero of=test.zero bs=1024k
count=128
128+0 records in
128+0 records out

real 0m18.178s
user 0m0.000s
sys 0m1.740s
root@c779218-a:/home/nnkk# rm -f test.zero
root@c779218-a:/home/nnkk# hdparm -W1 /dev/hde

/dev/hde:
setting drive write-caching to 1 (on)
root@c779218-a:/home/nnkk# time dd if=/dev/zero of=test.zero bs=1024k
count=128
128+0 records in
128+0 records out

real 0m7.809s
user 0m0.020s
sys 0m1.890s
root@c779218-a:/home/nnkk# time dd if=/dev/zero of=test.zero bs=1024k
count=256
256+0 records in
256+0 records out

real 0m44.328s
user 0m0.010s
sys 0m3.510s
root@c779218-a:/home/nnkk# hdparm -W1 /dev/hde

/dev/hde:
setting drive write-caching to 1 (on)
root@c779218-a:/home/nnkk# rm -f test.zero
root@c779218-a:/home/nnkk# time dd if=/dev/zero of=test.zero bs=1024k
count=256
256+0 records in
256+0 records out

real 0m18.790s
user 0m0.000s
sys 0m3.780s
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.112 / U:3.348 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site