Date: Sun, 10 Jan 2010 08:27:39 -0700 From: Scott Long <scottl@samsco.org> To: Alexander Motin <mav@freebsd.org> Cc: FreeBSD-Current List <freebsd-current@freebsd.org>, Jeff Roberson <jroberson@jroberson.net> Subject: Re: Help test softupdates journaling (SUJ) Message-ID: <83031A5C-87E5-4052-A4C7-6108FD5E2F36@samsco.org> In-Reply-To: <alpine.BSF.2.00.1001090007100.1027@desktop> References: <mailpost.1262998480.6342895.87899.mailing.freebsd.current@FreeBSD.cs.nctu.edu.tw> <4B4851FE.2020907@FreeBSD.org> <alpine.BSF.2.00.1001090007100.1027@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 9, 2010, at 3:12 AM, Jeff Roberson wrote: > On Sat, 9 Jan 2010, Alexander Motin wrote: > >> Hi. >> >> Jeff Roberson wrote: >>> I have been augmenting softupdates with a small journal that will be >>> processed in lieu of fsck in the event of a crash. I have written >>> some >>> about this project here: http://jeffr_tech.livejournal.com/ >> >> Sounds cool, but I have one question. Excuse my possible ignorance. >> >> I was looking for BIO_FLUSH consumers and haven't found UFS there. >> Unbacked write caching probably can make SoftUpdates unreliable, >> but it >> is bearable while foreground fsck is used. As I understand, journaled >> recovery is more dependent on data coherency, and so needs either >> unbacked write caching to be disabled, or BIO_FLUSH to be used in >> respective points by FS code. Am I right? So what's about BIO_FLUSH? > > Softupdates definitely relies on proper disk ordering. People who > want reliability in the face of power failure need to buy nice disks > and buy battery backup systems. Many cheap disks lie about flush > and this has bitten ZFS. SU+J will still work with foreground fsck > if you want to be absolutely certain of your data in the event of a > power outage. > > It would be possible to implement a flush barrier in between writing > the journal and permitting the meta-data modifications, and again > after metadata modifications and before journal free. SU+J would be > more tolerant to out of order filesystem operations following the > journal write than vanilla softupdates. However, I'm not sure how > much it will help, and it is not part of my current plans. It is > probably worthwhile to study further. > The write barrier here probably doesn't need to be as heavy-weight as the cache-flush that BIO_FLUSH tries to do. For devices that implement ordered tags (i.e. SCSI and SAS, not SATA), a barrier op would be preferable. This has been the source of recent arguments that I don't want to re-open on this discussion, but please let me know in private if you'd like to discuss it. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?83031A5C-87E5-4052-A4C7-6108FD5E2F36>