From owner-FreeBSD-users-jp@jp.freebsd.org  Sat May 19 20:08:19 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id UAA63559;
	Sat, 19 May 2001 20:08:19 +0900 (JST)
	(envelope-from owner-FreeBSD-users-jp@jp.FreeBSD.org)
Received: from research01.gate.nec.co.jp (research01.gate.nec.co.jp [202.247.6.220])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id UAA63554
	for <FreeBSD-users-jp@jp.freebsd.org>; Sat, 19 May 2001 20:08:19 +0900 (JST)
	(envelope-from hino@nwk.cl.nec.co.jp)
Received: from leek.nwk.cl.nec.co.jp (IDENT:IOhI25wm0Fzo/KGXmQYeCajx86dZWypD@leek.nwk.cl.nec.co.jp [10.56.32.7]) by research01.gate.nec.co.jp (8.9.3+3.2W/010410) with ESMTP id UAA23268 for <FreeBSD-users-jp@jp.freebsd.org>; Sat, 19 May 2001 20:08:18 +0900 (JST)
Received: from localhost by leek.nwk.cl.nec.co.jp (8.11.3/NWK_M-20010214) with ESMTP
	id f4JB8Iu15189 for <FreeBSD-users-jp@jp.freebsd.org>; Sat, 19 May 2001 20:08:18 +0900 (JST)
To: FreeBSD-users-jp@jp.freebsd.org
From: hino@ccm.cl.nec.co.jp
X-In-Reply-To: sf@FreeBSD.org's message of
	"Fri, 18 May 2001 23:58:12 +0900"
In-Reply-To: <86bsoq66wr.wl@cheerful.com>
References: <86bsoq66wr.wl@cheerful.com>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Message-Id: <20010519200818D.hino@nwk.cl.nec.co.jp>
Date: Sat, 19 May 2001 20:08:18 +0900
X-Dispatcher: imput version 980905(IM100)
Lines: 75
Reply-To: FreeBSD-users-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+010328
X-Sequence: FreeBSD-users-jp 61623
Subject: [FreeBSD-users-jp 61623] Re: too slow ata (Re: SOHO PC-RAID10)
Errors-To: owner-FreeBSD-users-jp@jp.freebsd.org
Sender: owner-FreeBSD-users-jp@jp.freebsd.org
X-Originator: hino@nwk.cl.nec.co.jp

>> On Fri, 18 May 2001 23:58:12 +0900, FUJISHIMA Satsuki <sf@FreeBSD.org> said:
:> softupdates$B$,(Bconsistency$B$rJ]>Z$7$F$$$k$N$K!$%G%#%9%/$,(Bwrite caching$B$7(B
:> $B$F$$$F$O0UL#$,$"$j$^$;$s$+$i!$!V%G%U%)%k%H$O0BA4$K$7$F$*$$$F!$%A%e!<%K(B
:> $B%s%0$O0UL#$rM}2r$7$F$+$i!W$H$$$&$3$H$G!$$o$6$o$6(Bwc=0$B$K$J$j$^$7$?!%%I%i(B
:> $B%$%P$NF0:n$KLdBj$,$"$C$?$o$1$G$O$"$j$^$;$s!%(B

Dillon$B$;$s$;$N(B-stable ML$B$X$N%]%9%H$rIU$1$F$*$-$^$9!#(B
$B$^!"%I%i%$%V%Y%s%@$r?.$8$-$l$k?M$@$1(Bwc=1$B$K$7$J$5$$!"(BFreeBSD$B$H$7$F$OA4(B
$B$F$N(BATA$B%I%i%$%V%Y%s%@$r?.MQ$9$k$3$H$O=PMh$J$$$+$i!"%f!<%6$N%G!<%?$r<i(B
$B$k$?$a$K!"%G%U%)%k%H$O(Bwc=0$B$H$9$k!"$H$$$&$3$H$G$7$g$&$M!#(B

$BF|Ln(B@NEC


Subject: Re: soft update should be default
From: Matt Dillon <dillon@earth.backplane.com>
To: Doug Russell <drussell@saturn-tech.com>
Cc: freebsd-stable <freebsd-stable@FreeBSD.ORG>
Date: Sat, 5 May 2001 11:29:39 -0700 (PDT)


:> Of course as Gordon writes above, all bets are off if your disk does 
:> write-caching.
:
:I still don't totally understand this.  In the case of a drive with WCE,
:aren't we always assuming that the drive will correctly write the data out
:eventually, even if the system crashes?
:
:This assumes that we aren't talking about a power failure, here, but if it
:is an external drive array with dual power supplies, at least one battery
:backed, it doesn't matter even if the compuer power is cut, the drive
:should still eventually flush out it's cache, shouldn't it?
:
:(Ideal world, of course, I know....  What if the SCSI bus wedges a drive?)
:
:> There is an excellent paper entitled, Soft Updates:  A Solution to the 
:> Metadata Update Problem in File Systems, by Gergory R. Granger and Yale 
:> N. Patt at EECS, University of Michigan.  The paper is at 
:> http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/.
:
:Sounds interesting...  I'm going to have to go take a look....
:
:Later.......						<Doug>

    Not only will the hard drive not be able to write the write-cached
    data to the media, but IDE hard drives will not guarentee write
    ordering either.  Someone did a test a while back and found that
    under heavy disk loads an IDE drive could hold some of the dirty data
    in its cache for an indefinite period of time without writing it out.
    i.e. it would write out some of the dirty data but also hold some of it
    indefinitely, unwritten.

    So turning on WCE is playing with fire.  WCE was mangled because 
    the drive manufacturers were more interested in posting high transfer
    rate numbers for benchmarks then in keeping people's data safe.  I
    remember when it happened... the day the drive manufacturers started
    using their lobotomized SCSI cores internally was the day they realized
    they could cache writes.

    Now, there is an IDE flush command.  Theoretically it would be possible
    to write out non-conflicting sectors with WCE turned on, then flush
    the cache, and repeat.  Theoretically it would be possible for a
    RAID system with its own battery backed cache to operate with WCE 
    turned on and flush the disks before the data would be lost from
    its own cache.

    Realistically, drive manufacturers rarely test the command set the
    drives are supposed to support beyond making sure it works with some
    idiotic windows driver, so these cool commands are as likely to crash
    the drive then to work as advertised.

						-Matt

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
