On Wed, 17 Feb 1999 10:09:57 -0800 (PST), Linus Torvalds
<torvalds@transmeta.com> said:
> On Wed, 17 Feb 1999, Stephen C. Tweedie wrote:
>>
>> The atomic write behaviour is a by-product of fixing an
>> entirely different problem (concurrent truncate, for which making it
>> atomic does make a lot of sense).
> No. The atomic write behaviour was implemented because we couldn't come up
> with any other reasonable scheme to handle truncation sanely, but that was
> after we had extended tons of effort on making a "normal" write do the
> right thing.
The real problem with normal writes was not concurrent writes as much
as writes and truncates taking place at the same time. If we can rely
on the bmap remaining static throughout the write, then it is far
easier to get things right.
> I believe that we should just rip out the code that tried to handle
> concurrent normal writes, and know they can't happen.
> For concurrent writes, it may be entirely acceptable to completely _drop_
> the write semaphore at well-defined places and retry, but that's going to
> be a per-filesystem thing: the VFS layer is going to basically grab the
> semaphore and default to complete atomicity.
Then why insist in your previous mail that "No, I don't think I'll
ever allow concurrent writes to the same file"? I *know* that this
has to be a per-filesystem case and that the VFS has to remain
cautious, but the important case, ext2, already has the ability to get
this right.
--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/