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

[Lev Serebryakov]

Hello, Kostik.
You wrote 27 ноября 2011 г., 22:41:20:

>> UFS?
> Because disabling reordering of the writes issued by UFS slows it down
> by a factor of 3-10 times.
  Any writes or SU/SU+J-related ones? Ok, let mark them with flag
"NOCACHE", which will hint, that they should not be delayed too much.

  BTW, I'm lost here. Above, you claim, that disabling reordering of
the writes impact performance. Below, you claim, that reordering of
writes could lead do security problems.

>>   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.
> Yous claims are not backed by any facts. Please inform us on the models
> and revisions of the firmware for the devices you declare are broken
> in the described ways. Also, please reference the documentation which
> states that devices behave in such a way.
  Some of RAID controllers ALLOWS to enable write cache without
batteries, with big warnings, that it is unsafe. I could not name
exact models (Ok, I don;t work with this hardware a much and I don't
have infinite memory, unfortunately), and they don't do it by default.

>> > 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.
> Software RAID5 might loose the checksum block due to kernel or power
> failure. This is not different from RAID1 declared inconsistent after
> the unclean stop.
> Your claim is not backed by facts, again.
   I speak about other aspect: performance. If you want to have descent
 write performance, you need to have write cache, or you'll end with
 N-2 reads for each write, and such RAID5 will be almost unusable
 (I've performed many tests here, in most cases several minutes on
 write cache almost guarantee on may workloads, that whole set of
 stripes is gathered and no reads to re-calculate cheksums will be
 needed). To support descent write cache, implementation needs to report
 cached data as written one.

>> > 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.
> I cannot understand how you answer is related to my statement.
   In case of crash, HDD could not be able to flush its hardware
 cache, and this security issue could arise. Without crash software
 cache, which reorders writes, are perfectly Ok, as any other cache
 (from security point of view).

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