Does UFS2 send BIO_FLUSH to GEOM when update metadata (with softupdates)?

[Lev Serebryakov]

Hello, Kostik.
You wrote 26 ноября 2011 г., 12:41:51:

> on the operation end. In fact, there is inherited uglyness due to async
> nature, namely, the kernel-owned buffer locks. Getting rid of them would
> be much more useful then breaking UFS.
  Why do you name it breaking? How additional piece of meta-information could break
UFS?

> The non-broken driver must not return the 'completed' bio into the up
> queue until write is sent to hardware and hardware reported the completion.
 So, hold bio without completion for, say, 5 minutes, will be Ok?

> Raid controllers which aggressively cache the writes use nvram or
> battery backups, and do not allow to turn on write cache if battery is
> non-functional. I had not seen SU inconsistencies on RAID 6 on mfi(4),
  It is not always true. And it could be not true for network
attached storage, as here is too many variables in equation in such
case. Yes, good controller should do this, I could not agree more. But
it is not always possible, unfortunately.

> despite one our machine has unfortunate habit of dropping boot disk over
> SATA channel each week, for 2 years.
   Great! But even battery-backed (read: UPS) software realization is
 not protected from OS crashes. So, it is impossible to implement
 software RAID5, which plays nicely with UFS (in case of crash --
 until ehre is no crash, everyhting is perfect), now. Ok, you could
 say ``we don't need it at all,'' but I could not agree with this
 statement. Yes, I'm biased here. But, really, I see some interest to
 software RAID5 on FreeBSD now.

> You again missed the point - if metadata is not reordable, but user
> data is, you get security issues. They are similar (but inverse) to what
> I described in the previous paragraph.
  In case of crash -- yes. But, IMHO, in case of crash here could be
 scenario when some information is leaked in any case. If here is no
 crash, you haven't security issues. Because every read will return
 actual information, either from write cache, or from plates.
 Inconsistent cache implementation is bad thing, for sure, but it is
 orthogonal question to what we discuss here.

-- 
// Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>