Messages in this thread | | | Date | Wed, 17 Feb 1999 18:36:31 GMT | From | "Stephen C. Tweedie" <> | Subject | Re: fsync on large files |
| |
Hi,
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/
| |