On Wed, Jul 3, 2013 at 3:48 PM, David Lehman <dlehman@xxxxxxxxxx> wrote:
Bryan J Smith - Professional, Technical AnnoyanceI suppose this warrants some explanation. The reason for this is thatall raid-like devices currently use the same code within blivet for
determining minimum members, &c for a given raid level. As a result, the
definitions have to be as standard as possible. At some point I may be
able to find time to make something more flexible that would allow
different definitions of a given raid level for different raid backends
(eg: btrfs). Once such a framework is in place I could potentially start
allowing things like mdadm raid10 with two or three members. Until then,
it isn't really feasible.
This is 100% user (not maintainer) opinion here, but my "objective" viewpoint is not to define things in what is possible, but to put them in terms of "risk."
When it comes to any storage, my #1 concern when it comes to risk is "recovery." Not whether it will work, or whether the implementation (e.g., kernel DM/MD, mdadm, etc...) can make use of it, but can the storage be recovered off-system, possibly by another solution.
So we have ...
- SNIA DDF RAID-1E definitions
- IBM-LSI (even infrequent Promise option) implementations
- Linux mdadm implementations
So I would limit any "considerations" (i.e., just for consideration) where they are common. E.g., at a minimum I would require not just the fact that mdadm offers a DDF metadata format option, but whether it implements a SNIA compliant RAID-1E solution with it. RAID-1E has the potential to confuse a lot of sysadmins, whereas RAID-1 (or even 4-disc RAID-10) is fairly straight-forward and understood.
But that's my 100% user opinion, not a maintainer viewpoint. I'm more concerned with people trying to "recover" things, and not always as they should. E.g., the operating system file system is lost, and maybe someone is not aware it was Linux and try to discover what it is. Rare, but I've seen it happen.
--
b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
