Re: Help test softupdates journaling (SUJ)

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