Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS!

[Lev Serebryakov]

Hello, Ivan.
You wrote 28 февраля 2013 г., 21:01:46:

>>   One time, Kirk say, that delayed writes are Ok for SU until bottom
>>  layer doesn't lie about operation completeness. geom_raid5 could
>>  delay writes (in hope that next writes will combine nicely and allow
>>  not to do read-calculate-write cycle for read alone), but it never
>>  mark BIO complete until it is really completed (layers down to
>>  geom_raid5 returns completion). So, every BIO in wait queue is "in
>>  flight" from GEOM/VFS point of view. Maybe, it is fatal for journal :(
IV> It shouldn't be - it could be a bug.
  I'll try to reproduce it on VM, but it could be hard, as virtual
 storage have very different (really -- much simpler) characteristics
 and behavior.

>>   And want I really want to see is "SYNC" flag for BIO and that all
>>  journal-related writes will be marked with it. Also all commits
>>  originated with fsync() MUST be marked in same way, really. Alexander
>>  Motin (ahci driver author) assured me, that he'll add support for
>>  such flag in driver to flush drive cache too, if it will be
>>  introduced.

IV> Hmmm, once upon a time I actually tried to add it:

IV> http://people.freebsd.org/~ivoras/diffs/fsync_flush.patch
  I have almost the same patch here :)

IV> This is from 2011, and was never really reviewed. Kirk said it was a
IV> good idea (meaning the implementation could be wrong, YMMV) :)
  It will be great to see this idea committed, really! Could I help
 somehow?

IV> I don't know whether it's significant, but ffs_softdep.c contains 6
IV> bawrite() calls (meaning buf async write), in softdep_process_journal(),
IV> softdep_journal_freeblocks(), softdep_fsync_mountdev(), sync_cgs(), and
IV> flush_deplist().
  As  far  as  I  understand  (I've  examined  this  code  when try to
 understand how to add this BIO_SYNC flag), ASYNC/SYNC here means
 something different. It is only about does caller want to sleep till
 operation is completed, and doesn't mean sync or async write...
   So, I'm not sure, which of these calls should be marked for flushing
 (or should be marked with new ORDERED/BARRIER flag at least).
   SU code is complicated enough without journal, and with journal it
  is much more complicated to simply understand it :(

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