On Fri 17-04-15 15:51:14, John Spray wrote: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?
On 17/04/2015 14:23, Austin S Hemmelgarn wrote:So you can have events like FS_UNAVAILABLE and FS_AVAILABLE but what use
For some filesystems, it may make sense to differentiate between aAnother key differentiation IMHO is between transient errors (like
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.
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.
would this have? I wouldn't like the interface to be dumping ground for
random crap - we have dmesg for that :).