dm-crypt reordering BIOs across barriers?

dm-crypt reordering BIOs across barriers?

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

When you use dm-crypt, block IO requests to a dm-* device will invoke
dm_request_fn() -> map_request() -> crypt_map(). If a BIO is a write
barrier, crypt_map() will return DM_MAPIO_REMAPPED to map_request(),
which will immediately queue it to the device.

If a few dozen IOs are queued in rapid succession with multiple write
barriers, all write barriers will be executed before any actual write
BIOs occur because the write IOs will be processed asynchronously in a
work queue. Since the barriers will be long gone by the time the write
IOs are queued, they can be queued in any order.

Am I misunderstanding this or is dm-crypt ignoring proper write barrier
semantics?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] dm-crypt reordering BIOs across barriers?

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

On Fri, 07 Jun 2013 23:47:33 -0400
Richard Yao <ryao@gentoo.org> wrote:

> When you use dm-crypt, block IO requests to a dm-* device will invoke
> dm_request_fn() -> map_request() -> crypt_map(). If a BIO is a write
> barrier, crypt_map() will return DM_MAPIO_REMAPPED to map_request(),
> which will immediately queue it to the device.
> 
> If a few dozen IOs are queued in rapid succession with multiple write
> barriers, all write barriers will be executed before any actual write
> BIOs occur because the write IOs will be processed asynchronously in a
> work queue. Since the barriers will be long gone by the time the write
> IOs are queued, they can be queued in any order.
> 
> Am I misunderstanding this or is dm-crypt ignoring proper write barrier
> semantics?
> 
http://www.saout.de/pipermail/dm-crypt/2012-April/002441.html
http://lwn.net/Articles/400541/

-- 

  Sergei

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] dm-crypt reordering BIOs across barriers?

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

On 06/08/2013 02:11 AM, Sergei Trofimovich wrote:
> On Fri, 07 Jun 2013 23:47:33 -0400
> Richard Yao <ryao@gentoo.org> wrote:
> 
>> When you use dm-crypt, block IO requests to a dm-* device will invoke
>> dm_request_fn() -> map_request() -> crypt_map(). If a BIO is a write
>> barrier, crypt_map() will return DM_MAPIO_REMAPPED to map_request(),
>> which will immediately queue it to the device.
>>
>> If a few dozen IOs are queued in rapid succession with multiple write
>> barriers, all write barriers will be executed before any actual write
>> BIOs occur because the write IOs will be processed asynchronously in a
>> work queue. Since the barriers will be long gone by the time the write
>> IOs are queued, they can be queued in any order.
>>
>> Am I misunderstanding this or is dm-crypt ignoring proper write barrier
>> semantics?
>>
> http://www.saout.de/pipermail/dm-crypt/2012-April/002441.html
> http://lwn.net/Articles/400541/
> 

It might be worth stating that I thought flush was a synonym for
barrier. It still looks like there is an issue, despite my incorrect
terminology.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]