On Sat, Mar 24, 2012 at 8:51 PM, Will Drewry <redpig@xxxxxxxxxxxxx> wrote: > On Fri, Mar 23, 2012 at 8:07 PM, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: >> >> >> On Sat, 24 Mar 2012, Kasatkin, Dmitry wrote: >> >>> Hi, >>> >>> Thanks for clarification. >>> Indeed everything works just with dm_bufio_write_dirty_buffers(). >>> Reboot notifier is to issue the flush only.. >>> As I understand, dm-bufio will do the flush but currently once per 10 seconds. >>> >>> if data on the block device and metadata on other block device get out >>> of sync, what you can do then? >>> how journal helps then? >>> >>> - Dmitry >> >> It depends what you're trying to do. >> >> If you're trying to do something like "dm-verity", but with a possibility >> to write to the device, there are several possibilities: >> >> * keep two checksums per 512-byte sector, the old checksum and the new >> checksum. If you update the block, you update the new checksum, sync the >> metadata device and then write to the data device (obviously you need to >> batch this update-sync-write for many blocks write concurrently to get >> decent performance). When you verify block, you allow either checksum to >> match. When you sync caches on the data device, you must forget all the >> old checksums. >> >> * use journaling, write data block and its checksum to a journal. If the >> computer crashes, you just replay the journal (so you don't care what data >> was present at that place, you overwrite it with data from the journal). >> The downside is that this doubles required i/o throughput, you should have >> journal and data on different devices. >> >> * do nothing and rebuild the checksums in case of crash. It is simplest, >> but it doesn't protect from data damages that happen due to the crash (for >> example, some SSDs corrupt its metadata on power failure and you can't >> detect this if you rebuild checksums after a power failure). >> >>> Yes.. I am aware of dm-verity target. >>> It suites well for read-only cases. >>> It is questionable how tree-based approach will work with read-write. >>> Each single update will cause whole tree recalculation. >> >> A write would recalculate hashes only in the branch from tree bottom to >> tree top. The obvious downside is that there is no protection from crash. > > It also depends on how you plan to assure the integrity of the data: > Device-based symmetric key, asymmetric key, etc and the costs > associated. Local updates make integrity tricky -- will the device > update itself or will signed updates be supplied, do they need to be > online, does only a subsection need to be online, etc. > > It's likely that the tree updates won't be too expensive compared to > the crypto and you could attempt to optimize tree updates along a hot > path if needed (by breaking out hot subdirs to a separate targets) and > explore other tricks for getting transaction oriented behavior (two > swapping metadata devices for atomic tree updates, etc). dm-verity > was never locked into being a read-only target, but the lack of need > to support online updates means the code and required changes don't > exist. > > I'm sure any of us involved in dm-verity would be happy to discuss how > it might be used for your purposes (or if it is really a bad fit), > etc. > > cheers! > will Hello, dm-verity looks extremely nice for read-only targets. Just one root hash protects whole block device. But I am interested in writable use case. Would be nice to understand how it can be addresses as well... Thanks, Dmitry -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
