Monitoring filesystems / blockdevice for errors
Good morning,
currently, there is no way for an external application to monitor whether a filesystem or underlaying block device has hit an error condition - internal inconsistency, read or write error, whatever.
Short of parsing syslog messages, which isn't particularly great.
This is necessary for server monitoring in general.
I don't have a real idea how this could be added, short of adding a field to /proc/partitions (error count) or something similiar.
Comments?
Sincerely,
Lars Marowsky-Brée <[email protected]>
Signature · 6 lines
Perfection is our goal, excellence will be tolerated. -- J. Yahl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines
currently, there is no way for an external application to monitor whether a filesystem or underlaying block device has hit an error condition - internal inconsistency, read or write error, whatever.
Short of parsing syslog messages, which isn't particularly great.
what's wrong with it? reinventing /proc/kmsg and klogd would be tre gross.
Quoted 2 lines
I don't have a real idea how this could be added, short of adding a field to
/proc/partitions(error count) or something similiar.
for reporting errors, that might be OK, but it's not a particularly nice _notification_ mechanism...
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 2 lines · Mark Hahn
Quoted 1 line
Short of parsing syslog messages, which isn't particularly great.
what's wrong with it?
Because it means having to know about all potential messages the filesystems might dump out.
Quoted 1 line
reinventing
/proc/kmsgand klogd would be tre gross.
Well, only one process can read kmsg and get notified about new messages at any time, so that makes the monitoring depend on klogd/syslogd working, which given a write error by syslog might not be the case...
Quoted 4 lines
Quoted 2 lines
I don't have a real idea how this could be added, short of adding a field to
/proc/partitions(error count) or something similiar.for reporting errors, that might be OK, but it's not a particularly nice _notification_ mechanism...
Well, yes.
Sincerely,
Lars Marowsky-Brée <[email protected]>
Signature · 6 lines
Perfection is our goal, excellence will be tolerated. -- J. Yahl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
[Mark Hahn]
Quoted 1 line
Quoted 1 line
reinventing
/proc/kmsgand klogd would be tre gross.
[Lars Marowsky-Bree]
Quoted 4 lines
Well, only one process can read kmsg and get notified about new messages at any time, so that makes the monitoring depend on klogd/syslogd working, which given a write error by syslog might not be the case...
So rewrite klogd to do something much simpler for serious errors (yes they will be tagged as such) before trying to pass them on to syslogd. Or does it already do this? It's a userspace problem.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · Peter Samuelson
[Mark Hahn]
Quoted 1 line
Quoted 1 line
reinventing
/proc/kmsgand klogd would be tre gross.[Lars Marowsky-Bree]
Quoted 8 lines
Quoted 4 lines
Well, only one process can read kmsg and get notified about new messages at any time, so that makes the monitoring depend on klogd/syslogd working, which given a write error by syslog might not be the case...
So rewrite klogd to do something much simpler for serious errors (yes they will be tagged as such) before trying to pass them on to syslogd. Or does it already do this? It's a userspace problem.
Hmmm... Even if LMB and I are often of quite different oppinions, I think only modifying klogd is not enough. LMB stated that a userspace tool would need to know any possibly error messages that could possibly generated. Cleaning up all messages would be the first step to prepare for failure reports to userspace. Ie, what errors do re have?
- Sense errors (recoverable) \
- " " (unrecoverable) > for all kinds of devices
- Complete device failure (HDD is gone) /
- Data failure (wrong ext2 bitmaps) for all FS
- RAM's ECC/parity errors
- possibly some more;)
Cleaning up all error messages (maybe using exctly two lines: one for kind of failure, one for device/RAM/fs specific messages) could help a lot and doesn't hurt badly (code doesn't get really slower as these paths are more-or-less never taken; but there is a little bit more bloat...).
With such an infrastructure, klogd could pass those lines to an external helper (and additionally to syslog).
MfG, JBG
Signature · 4 lines
Fehler eingestehen, Größe zeigen: Nehmt die Rechtschreibreform zurück!!! /* Jan-Benedict Glaw <[email protected]> -- +49-177-5601720 */ keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB "insmod vi.o and there we go..." (Alexander Viro on linux-kernel)