Date: Thu, 21 Sep 2000 10:25:00 +0200 (CEST)
From: Soren Schmidt <sos@freebsd.dk>
To: Stephen.Byan@quantum.com (Stephen Byan)
Cc: fs@FreeBSD.ORG, sos@FreeBSD.ORG, freeBSD-scsi@FreeBSD.ORG ('freeBSD-scsi@freeBSD.org')
Subject: Re: disable write caching with softupdates?
Message-ID: <200009210825.KAA98478@freebsd.dk>
In-Reply-To: <8133266FE373D11190CD00805FA768BF055BD1C9@shrcmsg1.tdh.qntm.com> from Stephen Byan at "Sep 20, 2000 07:24:44 am"
next in thread | previous in thread | raw e-mail | index | archive | help
It seems Stephen Byan wrote: > > > > Write caching should _never_ be enabled, unless you don't > > care about the data, or the drive reports the operation > > queueing and completion seperately, so that the OS knows > > the completion order; even then, the OS will have to be > > prepared to stall writing new data until completion has > > occurred at any given synchronizatin point, so that it is > > impossible for the drive to complete the requests out of > > the order permitted by the OS. > > > > With regard to "_never_": even a sync mounted FS will not > > be recoverable to a deterministic state if write caching > > does not guarantee completion in FIFO order, for obvious > > reasons -- it doesn't matter if you go async in the kernel, > > or async in the drive, either way your data gets screwed. > > Wouldn't it be acceptable to mark the meta-data writes as non-cacheable > (i.e. write though to the media before signalling completion), and let the > remaining writes (user data writes) be cacheable? I think this would improve > the performance of the file system. > > SCSI has supported this for years, in the form of the FUA bit in the CDB for > the write command. Somewhat similar behavior can be had in the newer flavors > of ATA by issuing a "flush cache" command after each meta-data write, and > waiting until the flush command completes before signalling the completion > of the non-cacheable write. OK, I played a bit with that, the only info I can see I get from the higher levels is the BIO_ORDERED bit, so I tried to flush the cache each time I get one of those, _bad_ idea, 10% performance loss... Suggestions are welcome :) -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009210825.KAA98478>