On Fri, 28 May 2010 16:55:33 +0200
Pozsar Balazs <pozsy@uhulinux.hu> wrote:
You have two block devices: dm-1 and dm-2.
Each block device has a data cache above some storage (or storage access
method).
I/O through /dev/dm-X goes through this cache.
When you create dm-1 as a mapping over dm-2, access to dm-1 are mapped
directly to the storage (or storage-access) of dm-2 completely bypassing the
cache. This is done for performance reasons - a second cache in the IO path
would bring no gain and significant cost.
So when you read from dm-2, the block containing the UUID is cached in the
dm-2 cache.
When you write to dm-1, the block goes to the storage without touching the
dm-2 cache (the dm-1 cache is changed of course).
'sync' doesn't flush caches, it just pushes any dirty cached data out. The
data in the dm-2 cache isn't dirty, so nothing happens to it.
You shouldn't really access dm-2 directly when dm-1 is mapped over it.
A number of access attempts will fail. e.g. if you try to mount it directly,
or open it with O_EXCL it won't work, as dm has claimed exclusive access of
dm-2.
But Linux, being based on Unix, gives you enough rope to shoot yourself in
the foot. You can access dm-2 if you really want to, and you can even write
to it. But doing so is not advised and may cause saw feet.
To ensure you get current data when reading dm-2, you can us the
'drop_caches' hack, though a better approach is
blockdev --flushbufs /dev/dm-2
which will flush all the buffers out of the dm-2 cache.
Hopefully you are now enlightened :-)
NeilBrown
--
