FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 03-24-2012, 05:51 PM
Will Drewry
 
Default dm-bufio

On Fri, Mar 23, 2012 at 8:07 PM, Mikulas Patocka <mpatocka@redhat.com> 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

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-27-2012, 09:56 AM
"Kasatkin, Dmitry"
 
Default dm-bufio

On Sat, Mar 24, 2012 at 3:07 AM, Mikulas Patocka <mpatocka@redhat.com> 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.
>

Right.. It requires double space and more IO.
The it will certainly be more stable to failures.
But what if data block will be corrupted during write due to power or
other failures?
In such case both checksums will not obviously match...

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

That looks definitely more reliable.


> * 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).
>

easy and nice

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

Yes.. I noticed.

>
> BTW. regarding that reboot notifier with
> "dm_bufio_write_dirty_buffers(d->bufio)" ... there could be another
> problem ... what if other reboot notifier (maybe for a completely
> different driver) writes to the device after
> "dm_bufio_write_dirty_buffers(d->bufio)" was performed?
>

"Target" owns/writes to device...
What other driver will do it?
Also rootfs is re-mounted read-only before rebooting.
It is actually not about data device sync, but "hash device" sync.

> - would it be possible to install your notifier again?
>
> - or turn into a synchronous updates? --- i.e. set a flag in your reboot
> notifier and if the flag is on, call
> "dm_bufio_write_dirty_buffers(d->bufio)" after every write.
>

I see the idea.

> Mikulas
>

Thanks,

Dmitry

> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-27-2012, 10:20 AM
"Kasatkin, Dmitry"
 
Default dm-bufio

On Sat, Mar 24, 2012 at 8:51 PM, Will Drewry <redpig@dataspill.org> wrote:
> On Fri, Mar 23, 2012 at 8:07 PM, Mikulas Patocka <mpatocka@redhat.com> 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@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 11:41 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org