From owner-freebsd-stable Mon Mar 12 15:14:45 2001 Delivered-To: freebsd-stable@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 3C39F37B71B; Mon, 12 Mar 2001 15:14:38 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2CNDGY25125; Mon, 12 Mar 2001 15:13:16 -0800 (PST) Date: Mon, 12 Mar 2001 15:13:15 -0800 From: Alfred Perlstein To: Matt Dillon Cc: Kevin Oberman , Soren Schmidt , mobile@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Disk I/O problem in 4.3-BETA Message-ID: <20010312151315.F18351@fw.wintelcom.net> References: <200103122036.VAA99695@freebsd.dk> <200103122146.f2CLkLs08952@ptavv.es.net> <20010312140636.A18351@fw.wintelcom.net> <200103122310.f2CNANH77246@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103122310.f2CNANH77246@earth.backplane.com>; from dillon@earth.backplane.com on Mon, Mar 12, 2001 at 03:10:23PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matt Dillon [010312 15:11] wrote: > :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. > : > :-- > :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > :Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ > > It's actually worse. Someone, I forget who, ran some tests with > write-caching turned on and found that the IDE drive could hold a > pending write in its cache 'forever', even in the face of other writes, > as long as there was other disk activity going on. So we aren't just > talking about issuing I/O's out of order, we are talking about issuing > a sequence of writes and having some of them simply not ever commiting > to disk (not for a long, long time) in a heavily loaded environment. > That's bad news. Someone leaked the Linux austrailian elevator algorithm to the disk manufacturers? I was wondering why I got a Turbo Linux CDrom with my last disk purchase. Of course I'm only kidding... -- -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-stable" in the body of the message