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

Re: [dm-devel] [RFC, PATCH] dm-log.c: Work with devices with hard-sector-size > 512 bytes



On Tue March 28 2006 9:01 am, Alasdair G Kergon wrote:
> A couple of options:
>
>   Retain the existing on-disk format exactly, but adjust the offsets and
>   sizes used in the reads and writes to avoid the problems (pre-reading
>   other data if necessary to extend a write).

This method seems like it should be easy to implement. We could just extend 
the buffer for the disk-header and always read and write both the header and 
the log at the same time, and just point lc->clean_bits at the appropriate 
offset within that buffer. The log could then remain at offset 1k, and the 
version wouldn't have to change.

>   Add an option to create version 3 metadata storing the offset in the
>   on-disk header but continue to use version 2 by default.

I think this is a better overall solution - less kludgy and more flexible.

>   Update userspace code to request version 3 (via new log parameter) for
>   new mirror logs by default, but still permit version 2 for new logs.

Is there a situation where someone would still need to create a new version 2 
log? I would think it would be far simpler to switch all new logs to use 
version 3, and revert back to version 2 only when the log offset recorded in 
the on-disk header is blank.

Or were you thinking of using this new log parameter to allow user-space to 
specify the offset of the log?

On a related note, shouldn't log_header.nr_regions be a uint64_t instead of a 
sector_t? The header_to_disk() and header_from_disk() routines already treat 
it as 64-bit.

-- 
Kevin Corry
kevcorry us ibm com
http://www.ibm.com/linux/
http://evms.sourceforge.net/


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