[linux-lvm] LVM2/DM Mapping Tables Documentation
Angelo DiNardi
adinardi at slshs.org
Thu Jul 22 17:00:57 UTC 2004
I believe the command "sync" at a shell prompt will flush the cache to
disk. Someone correct me if I'm wrong.
--Angelo
Dave B wrote:
> This is still causing me headaches... Does anybody
> have any insight on this?
>
> --- bowmailtmp-lvm at yahoo.com wrote:
>
>>ok, i think i've got an idea what's going on here,
>>it
>>seems that the lvm cache may be the problem here.
>>it
>>seems like in some cases if i wait a couple
>>*minutes*
>>then the data magically shows up in the proper
>>physical sectors of the disk. in some cases it is
>>faster, some quite slow. can someone confirm this
>>for
>>me and give me an idea of the mechanics involved
>>with
>>the cache? also, is there a command to force the
>>cache to be flushed out? i'll keep looking through
>>the man pages for this.
>>
>>thanks,
>>dave
>>
>>--- bowmailtmp-lvm at yahoo.com wrote:
>>
>>>I have been having a very difficult time
>>
>>correlating
>>
>>>physical addresses to LVM2/DM addresses.
>>>
>>>for instance, if i do:
>>>dmsetup table /dev/mapper/avtest-vdisk2g
>>>
>>>the result is:
>>>0 4194304 linear 22:65 384
>>>
>>>from what i currently understand, this means
>>
>>logical
>>
>>>extent 0 (which is composed of 8192 512 byte
>>
>>sectors
>>
>>>in the default config) of this LV should start at
>>>physical sector 384 of device 22:65 (/dev/hdd1 on
>>
>>my
>>
>>>machine)
>>>
>>>after i've written to the logical device a couple
>>>times, it appears this correlation doesn't hold
>>
>>when
>>
>>>i
>>>access the physical sectors on hdd1 using dd.
>>>however, if i use dd to access the sectors through
>>>the
>>>LV, all the data appears as it should. i was
>>
>>under
>>
>>>the impression that the logical to physical
>>
>>mappings
>>
>>>was quite straightforward and intuitive, but i
>>
>>feel
>>
>>>that i am missing some key information. Can
>>
>>someone
>>
>>>help me out of is there decent developer
>>>documentation
>>>somewhere that explains the mappings?
>>>
>>>As a more complete example of my problem, if i do
>>>the
>>>following:
>>>
>>>dd if=/dev/zero of=/dev/avtest/vdisk2g count=1
>>>then do:
>>>dd if=/dev/avtest/vdisk2g of=tmpfile.out count=1
>>>then tmpfile.out contains 512 bytes of zeros.
>>>
>>>however, if I do:
>>>dd if=/dev/hdd1 of=tmpfile.out skip=384 count=1
>>>then tmpfile.out contains other data, not the
>>
>>zero's
>>
>>>i
>>>would expect from the output of the dmsetup table
>>>command above. I feel i'm missing something
>>
>>fairly
>>
>>>basic here, but I haven't had any luck tracking
>>
>>this
>>
>>>relationship down. I suppose there is always the
>>>sourc code :)
>>>
>>>
>>>Thanks a lot.
>>>
>>>
>>>
>>>_______________________________________________
>>>linux-lvm mailing list
>>>linux-lvm at redhat.com
>>>https://www.redhat.com/mailman/listinfo/linux-lvm
>>>read the LVM HOW-TO at
>>>http://tldp.org/HOWTO/LVM-HOWTO/
>>>
>>
>>_______________________________________________
>>linux-lvm mailing list
>>linux-lvm at redhat.com
>>https://www.redhat.com/mailman/listinfo/linux-lvm
>>read the LVM HOW-TO at
>>http://tldp.org/HOWTO/LVM-HOWTO/
>>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20040722/3613f16e/attachment.sig>
More information about the linux-lvm
mailing list