lkml.org 
[lkml]   [1999]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: High-availability question
    Hi Kurt !

    On Fri, Jul 23, 1999 at 01:32:37PM +0200, Kurt Garloff wrote:

    > I can not confirm the problem with SCSI resets.
    > Basically, a driver has to detect, when a SCSI reset occurs.

    Even if a driver dedects this it can break things quite heavy.
    Just assume that a /dev/sg program expects that RESERVE/RELEASE
    UNIT works. I've not seen any code that keeps track of reservation
    and there is no code that would try to restore the state.

    > I see another problem: The box which mounts the FS read-only will have
    > inconcsistent buffers and you'll probably see lots of fs warnings. The
    > reasons is buffering: The data and metadata on disk has been updated by the
    > RW box, but the RPO box has still outdated buffers. Now, when some buffers
    > are read in, you get inconsistent states. So your RO box should bypass the
    > buffer cache. (Test it and use flushb for discarding the buffers.)

    Is this really possible ?
    I don't think that syncronous operation on the RO box can
    avoid inconsistent states at all without a real syncronisation
    to the RW box. (yes, this could be theoretically solved if both
    sides would work stateless using transactions (RESERVE/RELEASE UNIT or
    linked commands can be used for that). But this is not possible under
    Linux where two years ago syncronisation did not work on a __single__
    machine (beside buffer cache stuff).

    1. umount removable
    2. insert other media
    4. Use /dev/sg prog to eat CHECK CONDITION (like a cdrecord inquiry)
    5. mount removable

    The kernel expected that the old media was in.

    Did somebody remember ? ;-}

    [Note that I do _not_ want that kind of (multi initiator) transaction
    support because it would slow down SCSI even more. Both sides read only
    or one side writing while the other doesn't look at the data at all is
    the only useful way to handle multi initiator environments.]

    --
    ciao -
    Stefan

    "you have moved your mouse, please reboot to make this change take effect"

    Stefan Traby phone: +43-3133-6107-2
    Mitterlasznitzstr. 13 fax: +43-3133-6107-9
    8302 Nestelbach mailto://stefan@sime.com
    Austria

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:53    [W:0.038 / U:30.376 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site