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/