Hence my statement of
the aim is simply to return zero rather than EOPNOTSUPP [...]
which is quite reasonable
I think we are all getting a bit confused whether we are discussing
(a) EOPNOTSUPP return value,
or
(b) _all possible_ blkdev_issue_flush() error return values.
As I read it, you are talking about (a) and Jens responded to (b). But
maybe I am wrong.
So I have these observations:
1) fsync(2) should not return EOPNOTSUPP, if the block device does not
support cache flushing. This seems to agree with Linus's patch.
2) A Linux filesystem MIGHT care about EOPNOTSUPP return value, as that
return value does provide information about the future value of cache
flushes.
3) However, at present NONE of the blkdev_issue_flush() callers use
EOPNOTSUPP in any way. In fact, none of the current callers check the
return value at all.
4) Furthermore, handling lack of cache flush support at the block layer,
rather than per-filesystem, makes more sense to me.
But I am biased towards storage, so what do I know :)
5) Based on observation #3, the current kernel should be changed to
return USEFUL blkdev_issue_flush() return values back to userspace.
Fernando's patches head in this direction, as does my most recent
file_fsync patch.
Jeff
--
