>> What do you mean?
>> Is it not feasible to fix this in LVM as well, or do you just not know
>> what needs to be done to LVM?
>
> Fixing LVM is not on the radar of my priorities. The code is sorely in
> need of a rewrite and violates several of the basic planning tenents that
> any good code in the block layer should follow. Namely, it should have 1)
> planned on supporting 64 bit offsets, 2) never used multiplication,
> division or modulus on block numbers, and 3) don't allocate memory
> structures that are indexed by block numbers. LVM failed on all three of
> these -- and this si just what I noticed in a quick 5 minute glance
> through the code. Sorry, but LVM is obsolete by design. It will continue
> to work on 32 bit block devices, but if you try to use it beyond that, it
> will fail. That said, we'll have to make sure these failures are graceful
> and occur prior to the user having a chance at loosing any data.
>
> Now, thankfully there are alternatives like ELVM, which are working on
> getting the details right from the lessons learned. Given that, I think
> we'll be in good shape during the 2.5 cycle.
How does can any of this even work?
Say I have N disks, mirrored, or maybe with parity. I'm trying
to have a reliable system. I change a file. The write goes out
to my disks, and power is lost. Some number M, such that 0<M<N,
of the disks are written before the power loss. The rest of the
disks don't complete the write. Maybe worse, this is more than
one sector, and some disks have partial writes.
Doesn't RAID need a journal or the phase-tree algorithm?
How does one tell what data is old and what data is new?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/