lkml.org 
[lkml]   [2005]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Use of getblk differs between locations
    > Anton Altaparmakov wrote:
    >> On Tue, 2005-10-11 at 00:49 +0200, Mikulas Patocka wrote:
    >>> On Mon, 10 Oct 2005, Anton Altaparmakov wrote:
    >>> What should a filesystem driver do if it can't suddenly read or write any
    >>> blocks on media?
    >>
    >> Two clear choices:
    >>
    >> 1) Switch to read-only and use the cached data to fulfil requests and
    >> fail all others.
    >>
    >> 2) Ask the user to insert the media/plug the device back in (this is by
    >> far the most likely cause of all requests suddenly failing) and then
    >> continue where they left off.
    >>
    >> It is unfortunate that Linux does not allow for 2) so you need to do 1).
    >
    > I recently looked into 2) a bit and the dm multipath code is almost
    > enough to do exactly this.
    >
    > If you configure your block device as an mpath device that queues on
    > path failure, and change the table to the new device location on device
    > re-attach, the queued up i/o will be flushed out. Almost. Right now,
    > when you change the table and resume the dm mapping, it does a suspend
    > which attempts to write out the data to a device which is no longer
    > there, causing it to just be dropped on the floor. If this were changed
    > not to do that, and perhaps set a timer so that the dirty data wouldn't
    > be left around forever if the device wasn't reattached, 2) would
    > definitely be possible.
    >
    > I realize that the userspace intervention required may involve a bit of
    > dark magic, but my point is most of the code required on the kernel side
    > is already implemented.
    >
    > - -Jeff

    Is memory management ready for this? Can't deadlock like this happen?
    - displaying dialog window needs memory, so it waits until memory will be
    available
    - system decides to write some write-back cached data in order to free
    memory
    - the write of these data waits until the dialog window is displayed,
    user inserts the device and clicks 'OK'

    Mikulas
    -
    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-10-12 22:01    [W:3.103 / U:0.392 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site