Re: Re: [RFC][PATCH 0/4] dm-log: support multi-log devices

[Takahiro Yasui <tyasui@redhat.com>]

Phillip Susi wrote:
> Takahiro Yasui wrote:
>> log disks are updated in parallel and we do not know which disk has the
>> latest and correct data if the system crashes during write operations
>> on log devices. But there is no problem about it.
> 
> Once the IO request has been completed, the data needs to be stable on
> the disk.  This means that either you have to wait until the data has
> been written to all underlying mirror devices before completing the
> request ( slow ) or you have to have some way of knowing which disk(s)
> got written to, and which ones need updated after a crash.  Are you
> saying you take the former path?

Yes, write I/O to all underlying mirror devices need to be completed.
I understand your concern and think that there is a room to study about
performance enhancement.

>> There are two cases we need to think about.
>>
>> 1) Some log devices contain "clean", but mirror devices are not synchronized
>>
>> This case is problematic, but never happens, because data is written on
>> mirror devices after marking log devices "dirty", and make it "clean"
>> after write I/Os on mirror devices completed and mirrors get synchronized.
> 
> Does the entire log-data-log update cycle complete before dm completes
> the higher level IO request?  That would maintain data integrity, but at
> significant cost to performance.

I/O request returns to the higher level after data I/O completed, and
an update of the log device is done later.

> For performance sake, don't you want to allow write requests to be
> completed before the log is necessarily marked as clean again?  That way
> multiple writes to the same data zone do not require multiple log
> dirty/clean updates.  Also for performance reasons, don't you want to
> allow the data to be written to only one mirror before completing the
> request?  Then go back and do lazy synchronization?

I am also thinking exactly what you mentioned, and it will improve performance
of dm-mirror. I am now trying to improve performance in terms of:

> FUTURE WORKS
>   * Independent header and bitmap I/O
>   * Partial bitmap update

Thanks,
---
Takahiro Yasui
Hitachi Computer Products (America) Inc.