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

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(a)redhat.com&gt; >> --- >> 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.