From: Heinz Mauelshagen <heinzm@redhat.com>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: RHEL6.6 dm-cache and dm-era
Date: Thu, 25 Sep 2014 12:19:55 +0200 [thread overview]
Message-ID: <5423EC4B.5070904@redhat.com> (raw)
In-Reply-To: <5423B1E0.4000400@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4236 bytes --]
On 09/25/2014 08:10 AM, Romu Hu wrote:
> On 2014/9/24 12:10, Brassow Jonathan wrote:
>> On Sep 22, 2014, at 7:35 AM, Romu wrote:
>>
>>> I tried the following command to set up my era target but the
>>> command immediately panics the system and the system reboots.
>>>
>>> # dmsetup create MyEra --table "0 41941903 era
>>> /dev/mapper/VG-CacheDataLV_cmeta /dev/mapper/VG-OriginLV 4096"
>>>
>>> The metadata dev and the origin dev are all part of a LVM cache LV.
>>> VG-CacheDataLV_cmeta is the cache metadata LV on the smaller and
>>> faster device, VG-OriginLV is the origin LV on the faster and slower
>>> device, 41941903 is the total sector number of the device of
>>> OriginLV (the LV takes 100% space of the device), 4096 is the block
>>> size of OriginLV, I have run 'mkfs.ext4 /dev/mapper/VG-OriginLV'
>>> before running the dmsetup command.
>>>
>>> Below is the message in /var/log/messages after running the dmsetup
>>> comnmand:
>>>
>>> kernel: device-mapper: era: sb_check failed: magic 1623043: wanted
>>> 2126579579
>>> kernel: device-mapper: block manager: superblock validator check
>>> failed for block 0
>>> kernel: device-mapper: era: couldn't read_lock superblock
>>>
>>>
>>> Any idea?
>>>
>>
>> Sorry, I haven't used dm-era yet. However, it does appear that you
>> are perhaps specifying the wrong devices when creating the era
>> device? Looks like you might be allowing the era target and the
>> cache target to use the same metadata area at the same time - causing
>> them to corrupt each other's metadata area?
>>
>> brassow
>
> I think the dmsetup command to set up an era target should be
> something like this:
>
> # dmsetup create MyEra --table "0 sector_number era metadeta_dev
> origin_dev block_size"
>
> My questions:
>
> 1) How to calculate sector_number? According to
> https://www.kernel.org/doc/Documentation/device-mapper/era.txt, I
> guess it should be (4 * nr_blocks) bytes + buffers, but what is
> nr_blocks and what is buffers?
No calculation: it's the size of your era target in sectors. Typically
"blockdev --getsz origin_dev"
> 2) Any documentation for dmsetup tables?
Look for examples in the kernel source trees Documentaion/device.mapper.
table line syntax is: "start_sector length_in_sectors <target>
<target_arguments{0,N}>"
> 3) Both my metadata_dev and origin_dev are 10G partitions, is this all
> right?
Metadata device size is plenty but that depends on how many eras with
how many updates you want to have.
> 4) My origin_dev is a ext4 filesystem with a block size of 4096, so
> the block_size in the command line should also be 4096?
You may use 4096 = _8_ sectors, you used 4096 sectors = 2MB below.
It's the granularity the era target housekeeps blocks for.
>
> I tried the following command:
>
> # dmsetup create MyEra --table "0 160000 era /dev/mapper/mpathap1
> /dev/mapper/mpathbp1 4096"
May not be same physical device for data and metadata!
If it is, thta'd explain your oops.
# dmsetup create MyEra --table "0 $(blockdev --getsz
/dev/mapper/mpathbp) era whatever_disctinct_metadata_device
/dev/mapper/mpathbp1 8"
Would use 8 sector block size (which is tiny!) with disctinct metadata
and data devices (presumabyl your ext4 sits on /dev/mapper/mpathbp1)
Heinz
>
> It immediately panics the kernel (2.6.32-494.el6.i686) with the
> following info in /var/log/messages:
>
> Sep 24 22:44:22 localhost kernel: device-mapper: era: sb_check failed:
> magic 0: wanted 2126579579
> Sep 24 22:44:22 localhost kernel: device-mapper: block manager:
> superblock validator check failed for block 0
> Sep 24 22:44:22 localhost kernel: device-mapper: era: couldn't
> read_lock superblock
> Sep 24 22:44:22 localhost kernel: BUG: unable to handle kernel NULL
> pointer dereference at 00000008
> Sep 24 22:44:22 localhost kernel: IP: [<f7e9a3c7>]
> era_destroy+0x7/0x60 [dm_era]
> Sep 24 22:44:22 localhost kernel: *pdpt = 0000000001945001 *pde =
> 00000003ff97f067
> Sep 24 22:44:22 localhost kernel: Oops: 0000 [#1] SMP
> Sep 24 22:44:22 localhost kernel: last sysfs file:
> /sys/module/dm_mod/initstate
>
> Thanks
> Romu
>
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
[-- Attachment #1.2: Type: text/html, Size: 8463 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2014-09-25 10:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-15 2:24 RHEL6.6 dm-cache and dm-era Romu Hu
2014-09-15 20:25 ` Brassow Jonathan
2014-09-18 8:27 ` Romu Hu
2014-09-22 12:35 ` Romu
2014-09-24 4:10 ` Brassow Jonathan
2014-09-25 6:10 ` Romu Hu
2014-09-25 10:19 ` Heinz Mauelshagen [this message]
2014-09-25 14:02 ` Romu
2014-09-25 14:57 ` Heinz Mauelshagen
2014-09-26 3:16 ` Romu Hu
2014-09-26 10:33 ` Heinz Mauelshagen
2014-09-29 2:31 ` Romu Hu
2014-09-29 10:12 ` Heinz Mauelshagen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5423EC4B.5070904@redhat.com \
--to=heinzm@redhat.com \
--cc=dm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.