Date: Wed, 20 Sep 2000 07:24:44 -0700 From: Stephen Byan <Stephen.Byan@quantum.com> To: fs@FreeBSD.ORG Cc: sos@FreeBSD.ORG, "'freeBSD-scsi@freeBSD.org'" <freeBSD-scsi@FreeBSD.ORG> Subject: RE: disable write caching with softupdates? Message-ID: <8133266FE373D11190CD00805FA768BF055BD1C9@shrcmsg1.tdh.qntm.com>
next in thread | raw e-mail | index | archive | help
Terry Lambert [mailto:tlambert@primenet.com] wrote: > > Isn't it safer (in the face of a power failure) to disable write > > caching on a hard disk when softupdates is in use? > > Yes. You _must_ guarantee that the drive does not complete > writes out of sequence that it reports having completed in > sequence. Hardware which lies is evil. > > > > The ata driver currenly always enables write caching. Perhaps > > there should be a sysctl knob to turn it on/off? > > 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. Regards, -Steve Steve Byan <stephen.byan@quantum.com> Design Engineer MS 1-3/E23 333 South Street Shrewsbury, MA 01545 (508)770-3414 fax: (508)770-2604 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?8133266FE373D11190CD00805FA768BF055BD1C9>