[dm-devel] dm-cache fs corruption

[Vladimir Smolensky]

Okay, I'm trying to reproduce the problem using cache_restore, so far with
no luck. The hardware setup is the same as the original.

kernel 3.10.11-gentoo


Cache raid, 1 is meta, 2 data;

# parted /dev/sdc unit b print
Model: DELL PERC H700 (scsi)
Disk /dev/sdc: 2397799710720B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start        End             Size            File system  Name
Flags
 1      1048576B     1024458751B     1023410176B                  primary
 2      1024458752B  2397798662143B  2396774203392B               primary

Origin:

# parted /dev/sdb unit b print
Model: DELL PERC H700 (scsi)
Disk /dev/sdb: 20973392756736B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start     End              Size             File system  Name
Flags
 1      1048576B  20973391708159B  20973390659584B  xfs          primary

According to /dev/sda2 size, number of blocks should be

571435, with block size 4MiB( 8192 sectors)

Generating fake meta, I leave 5 blocks free

cache_xml create --nr-cache-blocks 571430 --nr-mappings 571430 0  >
/root/meta.xml

I edit the xml to set block size 8192 since there is no option for this.

cache_restore -i /root/meta.xml -o /dev/sdc1

dmsetup create storage --table '0 40963653632 cache /dev/sdc1 /dev/sdc2
/dev/sdb1 8192 1 writeback default 0’


mkfs.xfs /dev/mapper/storage

mount //dev/mapper/storage /mnt

Then I run fio with following setup:

[test1]
loops=10000
randrepeat=1
directory=/mnt/fio/data/
new_group
group_reporting=1
size=100g
rwmixread=70
rw=randrw
numjobs=12
ioengine=sync
#direct=1
bs=1M
nrfiles=3000

This is the status so far:

# dmsetup status storage
0 40963653632 cache 1719/249856 93161125 11990840 93713813 27533087 307339
307344 571435 306978 0 2 migration_threshold 10000000 4 random_threshold 4
sequential_threshold 10000000

There are ~300k demotions with no crash so far.
So probably filling the cache/demotions are not the only factor here.

regards.




On Thu, Nov 14, 2013 at 10:22 PM, Vladimir Smolensky <arizal at gmail.com>wrote:

> Okay, a little correction here. The problematic setup was with 2.3TB
> cache, not 3TB. The mistake comes from the fact that at the time of the
> writing I was dealing with another server which has 8x480GB ssd's in raid5,
> which is little over 3TB. Obviously the number was floating in my head.
>
>
> On Thu, Nov 14, 2013 at 5:21 PM, Vladimir Smolensky <arizal at gmail.com>wrote:
>
>> ./cache_restore -V
>> 0.2.8
>>
>>
>> On Thu, Nov 14, 2013 at 4:38 PM, Joe Thornber <thornber at redhat.com>wrote:
>>
>>> On Wed, Nov 13, 2013 at 06:39:37PM +0000, Mears, Morgan wrote:
>>> > On Wed, Nov 13, 2013 at 11:29:26AM -0005, Vladimir Smolensky wrote:
>>> > > Hello,
>>> > > I'm compiling the for-linus branch, it shows 3.12.0-rc5, that's ok
>>> right?
>>> > >
>>> > > Where can I get cache_restore, cache_dump, etc. and info how to use
>>> them.
>>> >
>>> > Hi Vladimir,
>>> >
>>> > git clone https://github.com/jthornber/thin-provisioning-tools.git
>>> > cd thin-provisioning-tools
>>> > autoreconf
>>> > ./configure --enable-testing
>>> > make
>>> > sudo cp cache_check cache_dump cache_restore cache_repair /usr/sbin
>>> > cache_check --version
>>> >
>>> > This is mostly distilled from README.md in the repo; there are some
>>> > additional dependencies in there that you might have to address.
>>> >
>>> > All the tools have a --help option; not sure about other documentation.
>>> >
>>> > --Morgan
>>>
>>> 'make install' should work, and I believe there are some man pages.
>>>
>>> - Joe
>>>
>>> --
>>> dm-devel mailing list
>>> dm-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/dm-devel
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20131115/380576ea/attachment.htm>