lkml.org 
[lkml]   [2001]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] 64 bit scsi read/write
    Date
    Ben LaHaise writes:
    > On Thu, 5 Jul 2001, Ragnar Kj\370rstad wrote:

    >> 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/

    \
     
     \ /
      Last update: 2005-03-22 12:57    [W:3.054 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site