Clarity and Compromise First steps of DM/MD unification Neil Brown Kernel Engineer

Clarity, Compromise and Convergence. First steps of DM/MD unification Neil Brown Kernel Engineer

Clarity: Understand the differences

© Novell Inc. All rights reserved 4 Clarity 1: Different abstractions DM has 'targets', MD has 'block devices'. 'targets' are a DM-specific abstraction. – light weight - No 'baggage' like struct request_queue – Easy to disconnect/reconnect > 'struct inode' points directly to backing_dev_info in request_queue. – light weight – no plugging or congestion notification – no 'name' – for error messages or sysfs integration. A DM device is a 'table' of 'targets'.

© Novell Inc. All rights reserved 5 Clarity 2: Different configuration. DM uses extensible ioctl, MD uses sysfs (for extensions). – Both are textual, DM ioctls are positional. – DM has separate 'messages' for reconfiguration while active. – DM has two fixed-format status message (TABLE or INFO) – Change notification: > DM has blocking ioctl > MD uses select/poll. – Low level access: > DM: dmsetup > MD: cat / echo

© Novell Inc. All rights reserved 6 Clarity 3: Online reconfiguration. DM uses suspend / rebuild / resume – clean and general – requires target / block-device separation – non-atomic, so user-space must be careful not to allocate memory. MD uses hot-add, hot-remove, hot-grow. – needs kernel to know about every possible reconfiguration. – reconfiguration is easily atomic – probably more efficient for active reshape.

© Novell Inc. All rights reserved 7 Clarity 4: Mind Share MD is “RAID” even though it has non-RAID personalities like “multipath” and “faulty”. DM is “generic virtual block device” even though it imposes a “concatenation” mapping on top of everything.

Compromise: Work with the differences

© Novell Inc. All rights reserved 9 Compromise 1: MD RAID5 for DM Create a DM target by wrapping internals of md/raid5 – great learning exercise Ugly hacks for MD – Needed to make lots of sysfs code conditional Exposed weaknesses in DM (easily fixed) – No target access to plugging – No target access to congestion notification – Dirty-log had to align with target size, but need component size alignment.

© Novell Inc. All rights reserved 1010 Compromise 2: other possibilities. RAID0 is too simple to bother with RAID1 might be worth unifying multipath – DM is much more mature than MD. – also very different from any other DM or MD module. md/bitmap and dm-region-hash/dm-dirty-log have a lot in common....would need clarity on 'important' differences.

Convergence: Remove the differences

© Novell Inc. All rights reserved 1212 Convergence 1: The best of both worlds Create something new! – Neither DM nor MD is really suitable to completely incorporate the other. Compromise leads to kludges. Use a separate abstraction, like a 'dm-target'. – want something more light-weight than 'block_device' Use sysfs for all configuration/management. Provide legacy interface for both DM and MD.

© Novell Inc. All rights reserved 1313 Convergence 2: I have a dream.... New name for new abstraction: volumes Also have 'volume group' as a useful abstraction. A 'block device' volume simply wraps a block_device. A 'file' volume wraps a file (like loop) Other volumes are built from volumes in same group – built from one or more “volume + offset” – can do RAID or encrypt or concatenation or bcache or whatever – Possibly have 'dirty log' volumes and 'metadata' volumes. A volume group can present several block devices which can switch between volumes in the group.

© Novell Inc. All rights reserved 1414 Conclusions Convergence is hard work. – Need to understand the important differences. – Need to create a win-win situation. – Need a credible long term vision – Even then, no guarantees.

Questions?

Unpublished Work of Novell, Inc. All Rights Reserved. This work is an unpublished work and contains confidential, proprietary, and trade secret information of Novell, Inc. Access to this work is restricted to Novell employees who have a need to know to perform tasks within the scope of their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability. General Disclaimer This document is not to be construed as a promise by any participating company to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. Novell, Inc. makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for Novell products remains at the sole discretion of Novell. Further, Novell, Inc. reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.