Help test softupdates journaling (SUJ)
Scott Long
scottl at samsco.org
Sun Jan 10 15:27:43 UTC 2010
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
More information about the freebsd-current
mailing list