Bug 1329234

Summary: [RFE] Implement mda update respecting physical sector size
Product: [Fedora] Fedora Reporter: Zdenek Kabelac <zkabelac>
Component: lvm2Assignee: LVM and device-mapper development team <lvm-team>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: agk, anprice, bmarzins, bmr, dwysocha, heinzm, jbrassow, jonathan, lvm-team, msnitzer, prajnoha, teigland, zkabelac
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-10-28 16:21:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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.