From owner-freebsd-mobile Mon Mar 12 17:16:27 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 544A437B71E; Mon, 12 Mar 2001 17:16:19 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2D1F0K29172; Mon, 12 Mar 2001 17:15:00 -0800 (PST) Date: Mon, 12 Mar 2001 17:14:59 -0800 From: Alfred Perlstein To: David Kelly Cc: Kevin Oberman , Soren Schmidt , mobile@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Disk I/O problem in 4.3-BETA Message-ID: <20010312171459.P18351@fw.wintelcom.net> References: <200103130047.f2D0lte06674@grumpy.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103130047.f2D0lte06674@grumpy.dyndns.org>; from dkelly@hiwaay.net on Mon, Mar 12, 2001 at 06:47:55PM -0600 X-all-your-base: are belong to us. Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * David Kelly [010312 16:48] wrote: > Alfred Perlstein writes: > > * 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. > > If I'm not mistaken when write caching is disabled the ATA drive does > not return from the write command until the data is on disc? And that > ATA drives can not overlap or queue pending commands so the pending > read/writes have to queue in the kernel? Is tagged queuing the solution > or is that something else? That would make the writes a bunch quicker... > The FreeBSD kernel has a built in daemon called syncer. It sounds like > a natural place to periodically issue a sync command to such storage > devices. Assuming such a command exists. This won't work. The syncer exists to: a) make sure data _eventually_ gets to disk. Basically without syncer, if your entire working set sat in cache and there was a crash, you might find yourself with data that's several days/weeks/months/whatever old! b) provide pressure on the filesystem to sync out data to free buffer space, although honestly this is mostly done by the buf_daemon now. You can't rely on the syncer to send out data ordered. (*) (*) well actually you can, but only as a side effect of the softupdates callback mechanism, when a buffer write happens and there's softdeps hung off it, a callback is made to back-out changes until the buffer is safe to write out. The problem is that you still have the writecaching going on so the ordering can get messed up. > My "purchased because they threw in a USB Zip-100 and ATA-100 PCI card" > 45G Maxtor is awfully impressive. 32000 blocks of 128k staring 8G from > the begining of the disk resulted in over 30MB/sec according to dd. I'm > stunned. Kernel from mid-Feb. > :P showoff... :) -- -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