On 12/04/2015 09:55 AM, Ján Tomko wrote:
> On Fri, Dec 04, 2015 at 09:44:20AM -0500, John Ferlan wrote:
>>
>>
>> On 12/04/2015 08:46 AM, Ján Tomko wrote:
>>> On Tue, Nov 24, 2015 at 03:57:14PM -0500, John Ferlan wrote:
>>>> Similar to the openflags VIR_STORAGE_VOL_OPEN_NOERROR processing, if some
>>>> read processing operation fails, check the readflags for the corresponding
>>>> error flag being set. If so, rather then causing an error - use VIR_WARN
>>>> to flag the error, but return -2 which some callers can use to perform
>>>> specific actions.
>>>>
>>>> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
>>>> ---
>>>> src/storage/storage_backend.c | 107 +++++++++++++++++++++++++++++++-----------
>>>> src/storage/storage_backend.h | 11 +++++
>>>> 2 files changed, 90 insertions(+), 28 deletions(-)
>>>>
>>>> diff --git a/src/storage/storage_backend.h b/src/storage/storage_backend.h
>>>> index aa9008e..e3ff306 100644
>>>> --- a/src/storage/storage_backend.h
>>>> +++ b/src/storage/storage_backend.h
>>>> @@ -179,6 +179,17 @@ enum {
>>>> VIR_STORAGE_VOL_OPEN_DIR = 1 << 4, /* directories okay */
>>>> };
>>>>
>>>> +/* VolReadErrorMode flags
>>>> + * If flag is present, then operation won't cause fatal error for
>>>> + * specified operation, rather a VIR_WARN will be issued and a -2 returned
>>>> + * for function call
>>>> + */
>>>> +enum {
>>>> + VIR_STORAGE_VOL_SEEK_ERROR = 1 << 0, /* don't error on (l)seek */
>>>
>>>> + VIR_STORAGE_VOL_READ_ERROR = 1 << 1, /* don't error on *read */
>>>
>>> This is the only flag used in this series.
>>>
>>> Also, naming it VIR_STORAGE_VOL_READ_NOERROR or VIR_STORAGE_VOL_READ_IGNORE_ERROR
>>> would make its meaning more obvious.
>>>
>>
>> I can rename flags to be:
>>
>> VIR_STORAGE_VOL_xxx_IGNORE_ERROR
>>
>> or
>>
>> VIR_STORAGE_VOL_IGNORE_xxx_ERROR
>>
>> Do you have a preference on order?
>>
>
> VIR_STORAGE_VOL_READ_xxx for VolReadErrorMode flags, similar to
> VIR_STORAGE_VOL_OPEN_xxx for VolOpenCheckMode flags.
>
OK, removing the flags causes changes to:
virStorageBackendUpdateVolTargetInfoFD effecting
src/storage/storage_backend.{c,h}
src/storage/storage_backend_{fs,gluster}.c
This affects patch 1 (to remove readflags from the API) and patch 3 to
remove the -2 return value comments from the API as well as adjustments
to other API's to touch up the 'readflags'.
I also needed to insert a new patch 2.5 which would handle errors in
virStorageBackendUpdateVolTargetInfo while processing the fd. If you
look at the code before my changes, failures from calls to lseek,
virFileReadHeaderFD, and virStorageFileGetMetadataFromBuf would result
in a virReportSystemError; however, the "ret" would remain what was
returned from the virStorageBackendUpdateVolTargetInfoFD (eg. 0 - zero).
Adding those "ignored" errors had also served the duplicate purpose of
actually returning an error code.
So would you like to see the whole series?
John
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list