Use dm snapshot device instead of our custom ram block device about crashmonkey HOT 9 CLOSED

Agree that using libdevmapper is preferrable. And I support the move towards more standardized modules like the device mapper.

What was the original problem with cow_brd?

from crashmonkey.

It seems that dm-snapshot targets are much slower than what we currently have. They are taking more time than fsck on small file systems (18183ms vs 5526 on a ~67MB ramdisk). 9a21e80 has the latest on this work so far.

I have also found that you can't always remove a snapshot immediately after unmounting it. It gives "device busy" errors. I will try to find a better way around that.

from crashmonkey.

@vijay03 it looks like I goofed up in the code that copies data over from the base image of the snapshot. After fixing that, I reproduce the same set of errors with both the cow_brd module and dm's transient snapshot target. 13dbd35 shows the fix for the cow_brd module. Should I PR it or try to touch up the dm snapshot more?

from crashmonkey.

If there are no other advantages to going the DM route apart from this bug, I'd say stay with the current architecture. But if we are doing the DM route anyway, I'd say focus on that.

from crashmonkey.

How fast do we want the test harness to be? the DM route is noticeably slower than the cow_brd code, taking ~30s for snapshot maintenance alone for 1000 tests on ext4.

from crashmonkey.

How slow is it? How many do states do we test in 30 s?

from crashmonkey.

For 1000 tests:
operation      |       snapshot type
time (ms)      |    MD      | cow_brd
---------------+------------+----------
snapshot       |   30576    |  0
fsck           |   12822    |  9696
total          |   49306    |  11469

* I skipped some of the other operations that did not take significant amounts of time to run

from crashmonkey.

Wow, lets continue with cow-brd then. Any idea why snapshots take so much time in DM?

from crashmonkey.

part of it is probably an issue with removing them immediately after unmounting a ram block device. It seems somewhere in the subsystem it still has work for the snapshot device that prevents it from immediate removal by dmsetup. It sometimes throws "device busy" errors when trying to remove DM snapshots. dmsetup has a retry with delay loop that it will go through for removals.

I haven't tried to tune DM at all, but I'm wondering if disabling the table that is going to be removed would speed it up at all.

from crashmonkey.