| 1 |
On 06/08/2013 02:11 AM, Sergei Trofimovich wrote: |
| 2 |
> On Fri, 07 Jun 2013 23:47:33 -0400 |
| 3 |
> Richard Yao <ryao@g.o> wrote: |
| 4 |
> |
| 5 |
>> When you use dm-crypt, block IO requests to a dm-* device will invoke |
| 6 |
>> dm_request_fn() -> map_request() -> crypt_map(). If a BIO is a write |
| 7 |
>> barrier, crypt_map() will return DM_MAPIO_REMAPPED to map_request(), |
| 8 |
>> which will immediately queue it to the device. |
| 9 |
>> |
| 10 |
>> If a few dozen IOs are queued in rapid succession with multiple write |
| 11 |
>> barriers, all write barriers will be executed before any actual write |
| 12 |
>> BIOs occur because the write IOs will be processed asynchronously in a |
| 13 |
>> work queue. Since the barriers will be long gone by the time the write |
| 14 |
>> IOs are queued, they can be queued in any order. |
| 15 |
>> |
| 16 |
>> Am I misunderstanding this or is dm-crypt ignoring proper write barrier |
| 17 |
>> semantics? |
| 18 |
>> |
| 19 |
> http://www.saout.de/pipermail/dm-crypt/2012-April/002441.html |
| 20 |
> http://lwn.net/Articles/400541/ |
| 21 |
> |
| 22 |
|
| 23 |
It might be worth stating that I thought flush was a synonym for |
| 24 |
barrier. It still looks like there is an issue, despite my incorrect |
| 25 |
terminology. |
Archives