thin_dump cannot dump the correct data mapping of thin pools

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

 



Hi folks,

I have been working on an incremental backup tools of thin volumes
created by dm-thin for a couple of months.
This tool relies on the data mappings dumped by thin_dump from the
thin-provisioing-tools.
As I update thin_dump from version 0.1.5 to 0.2.7, it cannot work
correctly as the earlier 0.1.5 version.

The following things have been observed:
1. thin_dump-0.2.7 cannot take user-specified "metadata_snap" as
v0.1.5. It will always return "bad checksum in superblock".
2. If "metadata_snap" is not given by users, thin_dump-0.2.7 only
dumps the out-dated data mappings which can be recognized by observing
the wrong "transaction id".

Since it looked like thin_dump failed to get the most up-to-date
metadata blocks in version 0.2.7, I dig a little deeper into the
source code and find something that might cause the problem.
The open flag used on metadata device has been changed from "O_DIRECT
| O_SYNC" to "0" in commit 4deb1751a650010ce9c15910a064be1348dec8ba .
After I changed this back to "O_DIRECT | O_SYNC" in version 0.2.7, it
works as expected once again.

So here is my question.
Can I change this flag back to "O_DIRECT | O_SYNC" in any newer version?
I am worry about that I might accidentally mess something up by
changing this flag.
Also, what's the purpose to get rid of the "O_DIRECT" and "O_SYNC"
flags when we migrate to version 0.2.x?

Any help would be highly appreciated.

Best Regards,
Dennis

--
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