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

[Austin S Hemmelgarn]

On 2015-04-17 12:22, Jan Kara wrote:
> On Fri 17-04-15 17:08:10, John Spray wrote:
> > On 17/04/2015 16:43, Jan Kara wrote:
> > > On Fri 17-04-15 15:51:14, John Spray wrote:
> > > > On 17/04/2015 14:23, Austin S Hemmelgarn wrote:
> > > >
> > > > > 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.
>
> 								Honza
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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature