Bug 1329234 - [RFE] Implement mda update respecting physical sector size
Summary: [RFE] Implement mda update respecting physical sector size
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: lvm2
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: LVM and device-mapper development team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-21 13:19 UTC by Zdenek Kabelac
Modified: 2019-10-28 16:21 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-28 16:21:30 UTC
Type: Bug


Attachments (Terms of Use)

Description Zdenek Kabelac 2016-04-21 13:19:40 UTC
Description of problem:

Existing lvm2 has aligned start of  metadata area on 1K boundary, however we have 4K sector disks so some metadata updates are changing single 4K sector and may possibly cause damage of even previous metadata.

Implement a mechanism to keep mda write aligned on 4K for such disks.

To stay fully compatible with existing disk format - we will give-up 'disk-wrapping' inside our ring-buffer.
Option like: 'only_wraparound_metadata_when_necessary' may be used to control
when we want to wrap in ringbuffer.

This technique will be more 'space' demanding then existing lvm2 for metadata space by might automatically fallback to wrapping mode in case we run out out space.

Mixed usage with older lvm2 commands should just cause temporary misalignment


Version-Release number of selected component (if applicable):
2.02.152


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Alasdair Kergon 2016-04-21 14:12:42 UTC
Background notes: This is a well-known flaw in the original design where an offset was hard-coded instead of being stored in the header.  The result is that some writes that we expect to be atomic involve rewriting data that should not have been part of the same write operation.  The hard-coded offset is relied upon whenever the metadata wraps around the buffer.  The argument presented here is that if the metadata area is sufficiently large, we can make sure that the metadata we write is contiguous and then we can use a larger hard-coded offset while not preventing unmodified versions of the LVM code from still always being able to read the metadata correctly.  At the same time we will probably want to add some additional annotations to avoid increasing the complexity of forensic analysis of metadata areas as metadata versions will no longer be stored sequentially and both old and new tools could be mixed.

Comment 2 David Teigland 2019-10-23 21:43:52 UTC
We should be able to close this, the io now goes through bcache (io-manager) which has io blocks aligned with 4K and sized according to the logical block size.  Metadata that is not aligned or sized properly ends up being written via one or more bcache blocks which are.


Note You need to log in before you can comment on or make changes to this bug.