# Re: selective block polling and preadv2/pwritev2 revisited

- List: linux-api
- 2 messages, 2 authors
- Page: https://ratatoskr.run/linux-api/2016/01/104044/t

## Re: selective block polling and preadv2/pwritev2 revisited

- From: Martin K. Petersen \<hidden\>
- Date: 2016-01-06 22:49:33 
- Message: https://ratatoskr.run/linux-api/2016/01/104044.md

```text
>>>>> "Sagi" == Sagi Grimberg [ref] writes:

>> The idea that was floated aroud a few times was to have a flag where
>> the first half of the vectors would be the data, and the second half
>> the metadata.

Sagi> This means that the user would need to pass iovec entries of 8
Sagi> bytes correct? Seems like a waste for large IOs (sorry for
Sagi> diverging from the subject)

The assumption was that there would be a 1:1 mapping between the number
of data buffers and the metadata ditto. But nothing says that a data
iovec entry is limited in size to a single sector.

The other option to have a single iovec at the end representing the
metadata for all data buffers. I think there are valid use cases for
either approach and we may end up having to support both via a flag.

-- 
Martin K. Petersen	Oracle Linux Engineering
```

## Re: selective block polling and preadv2/pwritev2 revisited

- From: Sagi Grimberg \<hidden\>
- Date: 2016-01-07 14:41:38 
- Message: https://ratatoskr.run/linux-api/2016/01/104043.md

```text
Hi Martin,

> Sagi> This means that the user would need to pass iovec entries of 8
> Sagi> bytes correct? Seems like a waste for large IOs (sorry for
> Sagi> diverging from the subject)
>
> The assumption was that there would be a 1:1 mapping between the number
> of data buffers and the metadata ditto. But nothing says that a data
> iovec entry is limited in size to a single sector.

Yea... I meant 1:1, I got confused on the 8 bytes comment...

> The other option to have a single iovec at the end representing the
> metadata for all data buffers. I think there are valid use cases for
> either approach and we may end up having to support both via a flag.

Either approach presents limitation, but I guess user-space can deal
with it...
```