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