Re: Writeback threads and freezable

[Tejun Heo]

Hello, Dave.

On Fri, Dec 20, 2013 at 11:51:14AM +1100, Dave Chinner wrote:
> > Please note that there's no real "immediacy" in that it's inherently
> > racy and that the extent of the usefulness of such notification can't
> > reach much further than suppressing error messages.
> 
> So says you. What about btrfs, which might use such a notification
> to start replicating metadata and data to other devices to maintain
> redundancy levels? Or even XFS, which might have a real-time device
> go away - that's not a fatal error for the filesystem, but we sure
> as hell want the user to know about it and be able to set a flag
> indicating access to data in real-time files need to be errored out
> at the .aio_write level rather than some time later when writeback
> fails with EIO and the application cannot capture the IO error.

Hmmm... but shouldn't such facilities also kick in on other fatal
failure conditions?  I have no fundamental objection against adding
someway to distinguish / notify hotunplug events but am a bit worried
that it has the potential to branch out the hotunplug path
unnecessarily and it seems that such tendency has been shown amply in
this thread too.

As I've pointed out multiple times in the thread, hotunplug path
serves very well as the continual testbed for catastrphic failure
cases for the whole stack from filesystems all the way down to
low-level drivers and can be attributed for high ratio of error
handling improvements / bugfixes we made over the years, so even if we
add something to distinguish hotunplug for upper layers, I think it
should be something which at least doesn't encourage implementing a
completely separate path and preferably something more generic.

> Seriously, Tejun, you need to stop focussing on tearing apart
> micro-examples and consider the wider context of the issue that the
> examples are being used to demonstrate.  The notifications being

Dear Dave, would you please drop the attitude?  You've been
consistently wrong in this thread.  Being aggressively assertive is
okay.  Being wrong is okay too.  Continuing the combination of the two
is not.  That's actively harmful, especially when the one doing so
commands respect in the community - it has high chance of derailing
the discussion and/or leading to the wrong conclusions.  Should I
reiterate the messed up confusions you showed at each turn of this
very thread?

Let's please stay technical.  You apparently didn't have much idea how
things work in the lower layers, which is completely fine.  Just don't
over-extend your asssertiveness without substance.  If you just made
your technical input from the get-go when viewed from your side of the
stack, we could have been a lot more productive.

I still think there's something to be extracted from this thread - how
we should handle catastrophic failure scenarios and the shortcomings
of the current shutdown procedure, both of which are far from perfect.
I'm not yet convinced with the idea of handling hot-unplug as
something completely special for the reasons I've stated multiple
times now and curious about the specifics of what you have on mind
because I don't really know what would be convenient from the
filesystem side.

> talked about here are already being delivered to userspace because
> there are OS management applications that need to know about devices
> going away. Filesystems are no different - there's all sorts of
> optimisations we can make if we get such a notification.

I'm not sure that analogy is too relevant.  The notifications
delivered to userland aren't different for hot or warm unplugs and
they don't participate in any of the exception handling details, which
is what I'm really worried about.  Again, I'm not necessarily against
the idea of flagging / notifying upper layers but please do keep in
mind that hotunplug handling shouldn't deviate much from other parts
of exception handling, which at least from the discussions we had in
this thread doesn't seem to be what you had on mind.  There are other
exception cases which share many, if not most, characteristics making
such approach a natural fit and hotunplug is one of the best tools we
have in ensuring those paths are in a healthy shape.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/