On 2015-04-17 12:22, Jan Kara wrote:
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.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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
