Date: Mon, 12 Mar 2001 17:14:59 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: David Kelly <dkelly@hiwaay.net> Cc: Kevin Oberman <oberman@es.net>, Soren Schmidt <sos@freebsd.dk>, mobile@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Disk I/O problem in 4.3-BETA Message-ID: <20010312171459.P18351@fw.wintelcom.net> In-Reply-To: <200103130047.f2D0lte06674@grumpy.dyndns.org>; from dkelly@hiwaay.net on Mon, Mar 12, 2001 at 06:47:55PM -0600 References: <bright@wintelcom.net> <200103130047.f2D0lte06674@grumpy.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* David Kelly <dkelly@hiwaay.net> [010312 16:48] wrote:
> Alfred Perlstein writes:
> > * Kevin Oberman <oberman@es.net> [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-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010312171459.P18351>