|Subject:||Re: [Qemu-block] [Qemu-devel] [PATCH v1 1/1] block: Add numeric errno field to BLOCK_IO_ERROR events|
|Date:||Mon, 8 Jan 2018 11:57:48 -0800|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0|
On 2017-12-22 05:52, Kevin Wolf wrote:
We have thousands of servers in our cloud, and would like to closely monitor for different kinds of disk errors without parsing the non-machine-readable error string.Am 22.12.2017 um 01:11 hat Jack Schwartz geschrieben:BLOCK_IO_ERROR events currently contain a "reason" string which is strerror(errno) of the error. This enhancement provides those events with the numeric errno value as well, since it is easier to parse for error type than a string. Signed-off-by: Jack Schwartz <address@hidden> Reviewed-by: Konrad Rzeszutek Wilk <address@hidden> Reviewed-by: Karl Heubaum <address@hidden>Apart from the technical details that Eric mentioed, I wonder what is your use case for this?
OK, found it. April of 2010.Exposing errors in a machine readable form was discussed earlier,
Upshot of discussion: exposing naked errnos are platform dependent.
Given the platform independence requirement, exposing errors to clients is not that simple given that different OSs use different errno values. Other options/considerations than exposing naked errno values:and the result was that nobody had an actual use for error codes other than presenting the right error message to the user - which the error string already achieves.
- Having a platform-independent enumeration of errors, as Eric suggested. This would have to explicitly set an enumerated value for each individual errno we are interested in. It would be returned in a field that ~parallels the "reason" string. This should be OK since for BLOCK_IO_ERROR events we could limit values to just storage device errors plus a default "other"; otherwise this could be hard to maintain.
- The strerror strings cannot be used because they can change with locale. (This also assumes the strings are identical for given errnos cross-platform, and that there are no typos - which are not automatically checked-for.)
P.S. Please excuse the delayed reply due to vacation / company shutdown.
The only exception so far was ENOSPC, which some management tools like oVirt respond to by increasing the volume size, so this was mapped into a bool. Kevin
|[Prev in Thread]||Current Thread||[Next in Thread]|