All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] block/raw-posix: Fall back to SEEK_HOLE/SEEK_DATA
Date: Tue, 06 May 2014 19:45:12 +0200	[thread overview]
Message-ID: <53691FA8.7060600@redhat.com> (raw)
In-Reply-To: <20140506114958.GE15810@stefanha-thinkpad.redhat.com>

On 06.05.2014 13:49, Stefan Hajnoczi wrote:
> On Mon, May 05, 2014 at 10:01:39PM +0200, Max Reitz wrote:
>> The current version of raw-posix always uses ioctl(FS_IOC_FIEMAP) if
>> FIEMAP is available; lseek with SEEK_HOLE/SEEK_DATA are not even
>> compiled in in this case. However, there may be implementations which
>> support the latter but not the former (e.g., NFSv4.2). In this case,
>> raw-posix should fall back to lseek with SEEK_HOLE/SEEK_DATA if FIEMAP
>> does not work.
>>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>> ---
>> As Linux does not yet implement NFSv4.2 (I don't even know whether the
>> specification is complete), I have no way of testing whether this
>> actually works for the proposed case. But as it doesn't break any of the
>> existing test cases, it should be fine.
>> ---
>>   block/raw-posix.c | 27 +++++++++++++++++++++------
>>   1 file changed, 21 insertions(+), 6 deletions(-)
>>
>> diff --git a/block/raw-posix.c b/block/raw-posix.c
>> index 3ce026d..e523633 100644
>> --- a/block/raw-posix.c
>> +++ b/block/raw-posix.c
>> @@ -146,6 +146,9 @@ typedef struct BDRVRawState {
>>       bool has_discard:1;
>>       bool has_write_zeroes:1;
>>       bool discard_zeroes:1;
>> +#if defined CONFIG_FIEMAP && defined SEEK_HOLE && defined SEEK_DATA
>> +    bool use_seek_hole_data;
>> +#endif
>>   } BDRVRawState;
>>   
>>   typedef struct BDRVRawReopenState {
>> @@ -1291,6 +1294,7 @@ static int64_t coroutine_fn raw_co_get_block_status(BlockDriverState *bs,
>>                                               int64_t sector_num,
>>                                               int nb_sectors, int *pnum)
>>   {
>> +    BDRVRawState *s = bs->opaque;
>>       off_t start, data, hole;
>>       int64_t ret;
>>   
>> @@ -1303,22 +1307,31 @@ static int64_t coroutine_fn raw_co_get_block_status(BlockDriverState *bs,
>>       ret = BDRV_BLOCK_DATA | BDRV_BLOCK_OFFSET_VALID | start;
>>   
>>   #ifdef CONFIG_FIEMAP
>> -
>> -    BDRVRawState *s = bs->opaque;
>>       struct {
>>           struct fiemap fm;
>>           struct fiemap_extent fe;
>>       } f;
>>   
>> +#if defined SEEK_HOLE && defined SEEK_DATA
>> +    if (s->use_seek_hole_data) {
>> +        goto try_seek_hole_data;
>> +    }
>> +#endif
> This is becoming hard to read due to the ifdefs and their relationships.
>
> A minor simplification is to change the bool field:
> #if defined CONFIG_FIEMAP
> bool use_fiemap;
> #endif
>
> ...
>
> #if defined CONFIG_FIEMAP
> if (s->use_fiemap) {
>      ...try fiemap...
> }
> #endif /* CONFIG_FIEMAP */
>
> use_fiemap is not dependent on SEEK_HOLE/SEEK_DATA.  That reduces the
> amount of ifdefs needed.
>
> A bigger cleanup is extracting the FIEMAP and SEEK_HOLE/SEEK_DATA
> implementations into their own static functions.  Then
> raw_co_get_block_status() becomes simpler and doesn't need ifdefs:
>
> ret = try_fiemap(...);
> if (ret < 0) {
>      ret = try_seekhole(...);
> }
> if (ret < 0) {
>      ...report every block allocated by default....
> }
>
> In other words, let normal C control flow describe the relationships
> between these code paths.  Use ifdef only to nop out try_fiemap() and
> try_seekhole().
>
> What do you think?

Great idea! I thought about using normal if's or something, but didn't 
think of this.

Max

      parent reply	other threads:[~2014-05-06 17:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-05 20:01 [Qemu-devel] [PATCH] block/raw-posix: Fall back to SEEK_HOLE/SEEK_DATA Max Reitz
2014-05-06 11:49 ` Stefan Hajnoczi
2014-05-06 12:27   ` Eric Blake
2014-05-06 17:46     ` Max Reitz
2014-05-06 17:55       ` Eric Blake
2014-05-06 17:45   ` Max Reitz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53691FA8.7060600@redhat.com \
    --to=mreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.