lkml.org 
[lkml]   [1999]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: MM deadlock [was: Re: arca-vm-8...]
    Hi,

    On Mon, 11 Jan 1999 00:14:19 -0800, Craig Milo Rogers <rogers@ISI.EDU>
    said:

    >> Basically,
    >> most writes should take out a read lock on the filesize so that the file
    >> won't disappear from under their feet; only extending or truncating the
    >> file should take out an i_atomic_allocate write lock (assuming the same
    >> sorts of semantics for r/w semaphores as we already have for r/w
    >> spinlocks).

    > I know I'm just kibbitzing rather than being a useful worker,
    > but: why should the writes care if the file is extended?

    Because POSIX.1 specifies that O_APPEND writes are atomic with respect
    to each other.

    > I would guess
    > that it should be something like:

    > 1) files writes take a read lock on "must-not-shrink"

    > 2) extending or truncating the file takes out a write lock
    > on the file size

    > 3) truncating the file also takes a write lock on "must-not-shrink"

    Unnecessary complexity, I think. A single lock on
    allocation/deallocation is sufficient for the important case (concurrent
    writes inside a shared file by multiple threads/processes) while
    maintaining reasonable behaviour for truncate. For processes managing a
    shared database file, this is important. I don't think it's all that
    important at all for multiple processes extending or truncating a file.

    --Stephen

    -
    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:49    [W:4.107 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site