lkml.org 
[lkml]   [1999]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: MM deadlock [was: Re: arca-vm-8...]
Date
From
>>> 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
>
>> 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.

Indeed, O_APPEND writes extend the file, and thus need a higher
level of locking. Regular writes interior to the file should be able to
continue concurrently with the O_APPEND extend.

>> I would guess that it should be something like:
...
>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.

I agree that I may be advocating optimizing for an infrequent
case; I prefer to think of it as a clean design. :-) Regarding shared
the use of database files, I note that Oracle can dynamically extend a
shared database file, so there's a possibility that the
extend-while-interior-I/O-is-in-progress scenario might occur
(depending upon how Oracle manages their own internal queuing, of
course).

Craig Milo Rogers


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