Messages in this thread | | | Date | Tue, 12 Jan 1999 16:05:33 GMT | From | "Stephen C. Tweedie" <> | Subject | Re: 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/
| |