Re: dm-cache fs corruption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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@xxxxxxxxx> wrote:
./cache_restore -V
0.2.8


On Thu, Nov 14, 2013 at 4:38 PM, Joe Thornber <thornber@xxxxxxxxxx> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux