Date: Wed, 2 May 2001 11:45:16 +1000 From: "Andrew Reilly" <areilly@bigpond.net.au> To: Rik van Riel <riel@conectiva.com.br> Cc: Bruce Evans <bde@zeta.org.au>, Cejka Rudolf <cejkar@dcse.fee.vutbr.cz>, freebsd-current@FreeBSD.ORG Subject: Re: Experiences with new dir allocation on FFS? Message-ID: <20010502114516.C1059@gurney.reilly.home> In-Reply-To: <Pine.LNX.4.21.0104290047430.19012-100000@imladris.rielhome.conectiva>; from riel@conectiva.com.br on Sun, Apr 29, 2001 at 12:50:08AM -0300 References: <Pine.BSF.4.21.0104281418120.7618-100000@besplex.bde.org> <Pine.LNX.4.21.0104290047430.19012-100000@imladris.rielhome.conectiva>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 29, 2001 at 12:50:08AM -0300, Rik van Riel wrote: > For the people wanting to turn on write caching ... it WILL break > the write ordering needed by softupdates and journaling filesystems, > so don't do it unless you know what you're doing. > > I guess it would be better to do this kind of write caching at the > kernel level, because the OS has a much better idea of when to write > which data to platter than a harddisk can ever have. However, on ATA without tagged queuing, turning off write caching (on my own UDMA33 system) reduces write performance by a factor of two. From 12MB/s to 6MB/s on my system. That is almost certainly because (a) ATA limits individual transfers to 64k, and (b) you can't get the next 64k into the drive before you miss the opportunity to stream the data into the next sector, so you lose a revolution _every_ write. I think I'll rely on the power system and my nightly backups, and leave .wc=1, thanks. Sure, on my next system I'll either go back to SCSI or find some ATA tagged queuing drives, but at the moment, I have to use what I've got... -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010502114516.C1059>