Re: [PATCH v2 3/5] storage: Handle readflags errors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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?

I personally didn't find the *_NOERROR to be that obvious, but I agree
adding IGNORE at least does make it obvious.

> ACK with the unused flags dropped.

Is it really that important to remove the SEEK and FILECON failure
checks? I added them mainly to be "complete".

Sure having them is overkill; however, it was pointed out the v1 was too
broad. Keeping them just means a change in the future won't have to add
them. I'm not sure I see the harm, but I'm ambivalent over having to
remove them for an ACK.

Tks -

John

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]