From owner-freebsd-mobile Tue Mar 13 0:59:37 2001 Delivered-To: freebsd-mobile@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0868C37B718; Tue, 13 Mar 2001 00:59:32 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2D8wBX10760; Tue, 13 Mar 2001 00:58:11 -0800 (PST) Date: Tue, 13 Mar 2001 00:58:11 -0800 From: Alfred Perlstein To: Helge Oldach Cc: oberman@es.net, sos@freebsd.dk, mobile@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Disk I/O problem in 4.3-BETA Message-ID: <20010313005811.J29888@fw.wintelcom.net> References: <20010312140636.A18351@fw.wintelcom.net> <200103130848.JAA08707@galaxy.de.cp.philips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103130848.JAA08707@galaxy.de.cp.philips.com>; from Helge.Oldach@de.origin-it.com on Tue, Mar 13, 2001 at 09:48:26AM +0100 X-all-your-base: are belong to us. Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Helge Oldach [010313 00:48] wrote: > Alfred Perlstein: > >* Kevin Oberman [010312 13:46] wrote: > >> How serious is the possible corruption issue, anyway. The loss in > >> performance is pretty drastic although it may be that dd is an > >> especially bad case, but I really don't like to corrupt my disks, > >> either. > > > >If basically running with blind write caching turned on is akin to > >running your filesystem in async mode. This is because write > >caching gives the drive license to lie about completing a write, > >the various ordering of writes are effectively bypassed. If you > >crash without these dependancies actually written to the disk, when > >you come back up you have a good chance of losing large portions > >of your filesystem. > > I'd say this is a bit too pessimistic. There is a fundamental difference > between softupdates and ATA write-cacheing: Softupdates holds the async > data in main RAM while ATA write-cacheing already has it in the (cache > memory of the) disk device. > > Obviously a power outage would affect both situations in a similar way. > But during just an operating system crash (assuming power stays up), > one should be better off with ATA write-cacheing, as the disk should be > able to dump the data from the cache chips to the physical medium. With > softupdates async data is just lost. > > Generally I'd say it's not a bad idea to have write caching on the disk > enabled - assuming that it is decently implemented. BTW, don't SCSI > disks use write cacheing as well? :-) I'm pretty sure you're wrong. I'm not 100% certain, but many people working with embedded systems have explained to me that it's no longer safe to assume that write cached data will be sync'd to the disk's media at crash time. First off, some disk caches are getting > 10megs, that's a lot of potnetial seeking after loosing power depending on the cache contents... (Also, Matt Dillon wrote how some disks can hold data in the write cache for indefinite amounts of time) Basically, from what's been explained to me, modern disks only retain enough charge/momentum to park (retract) the disk heads when a power outtage occurs, not to write out the cache contents. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message