Re: [RFC 1/4] fs: Add generic file system event notifications

On Fri 17-04-15 12:29:07, Austin S Hemmelgarn wrote:

On 2015-04-17 12:22, Jan Kara wrote:

quoted

On Fri 17-04-15 17:08:10, John Spray wrote:

quoted

On 17/04/2015 16:43, Jan Kara wrote:

quoted

On Fri 17-04-15 15:51:14, John Spray wrote:

quoted

On 17/04/2015 14:23, Austin S Hemmelgarn wrote:

quoted

For some filesystems, it may make sense to differentiate between a
generic warning and an error.  For BTRFS and ZFS for example, if
there is a csum error on a block, this will get automatically
corrected in many configurations, and won't require anything like
fsck to be run, but monitoring applications will still probably
want to be notified.

Another key differentiation IMHO is between transient errors (like
server is unavailable in a distributed filesystem) that will block
the filesystem but might clear on their own, vs. permanent errors
like unreadable drives that definitely will not clear until the
administrator takes some action.  It's usually a reasonable
approximation to call transient issues warnings, and permanent
issues errors.

  So you can have events like FS_UNAVAILABLE and FS_AVAILABLE but what use
would this have? I wouldn't like the interface to be dumping ground for
random crap - we have dmesg for that :).

In that case I'm confused -- why would ENOSPC be an appropriate use
of this interface if the mount being entirely blocked would be
inappropriate?  Isn't being unable to service any I/O a more
fundamental and severe thing than being up and healthy but full?

Were you intending the interface to be exclusively for data
integrity issues like checksum failures, rather than more general
events about a mount that userspace would probably like to know
about?

  Well, I'm not saying we cannot have those events for fs availability /
inavailability. I'm just saying I'd like to see some use for that first.
I don't want events to be added just because it's possible...

For ENOSPC we have thin provisioned storage and the userspace deamon
shuffling real storage underneath. So there I know the usecase.

The use-case that immediately comes to mind for me would be diskless
nodes with root-on-nfs needing to know if they can actually access
the root filesystem.

  Well, most apps will access the root file system regardless of what we
send over netlink... So I don't see netlink events improving the situation
there too much. You could try to use it for something like failover but
even there I'm not too convinced - just doing some IO, waiting for timeout,
and failing over if IO doesn't complete works just fine for that these
days. That's why I was asking because I didn't see convincing usecase
myself...

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR