The reason I decided to use -EOPNOTSUPP was that I wanted to keep
barriers and device flushes from entering the block layer when
they are not needed. I feared that if we pass them down the block
stack (knowing in advance they will not be actually submitted to
disk) we may end up slowing things down unnecessarily.
As you mentioned, filesystems such as ext3/4 will disable
barriers if they get -EOPNOTSUPP when issuing one. I was planning
to add a notifier mechanism so that we can notify filesystems has
been a change in the barrier settings. This might be
over-engineering, though. Especially considering that "-o
remount,barrier=1" will bring us the barriers back.
Aren't we risking slowing things down? Does the small optimization above
make sense (especially taking the remount trick into account)?
Maybe I am worrying too much about the possible performance penalty.
You are right, wbcflush is a pretty ugly name. I will use
"honor_cache_flush" in the next iteration of the patches.