On Thu, 13 Apr 2006, Nick Piggin wrote:
>
> Didn't Linus explicitly made the decision not to add synchronisation for
> writes with the same file?
I would be _very_ nervous to do it, yes. In particular, I do not consider
it at all unlikely to have something database-like that does concurrent
writes to the same file at different offsets, and serializing them on the
VFS layer seems pretty broken.
Also, doing it unconditionally in the VFS layer is actually pretty
seriously broken: the VFS layer doesn't even know what kind of file it is,
and locking on writes can be literally the wrong thing for some file
descriptors (think pipes or sockets: if we have one blocking write holding
the lock, that should _not_ imply that other - possibly nonblocking -
writes shouldn't be able to call in to the low-level write handler).
That said, I wouldn't be 100% against it, especially under certain
circumstances. However, the circumstances when I think it might be
acceptable are fairly specific:
- when we use f_pos (ie we'd synchronize write against write, but only
per "struct file", not on an inode basis)
- only for files that are marked seekable with FMODE_LSEEK (thus avoiding
the stream-like objects like pipes and sockets)
Under those two circumstances, I'd certainly be ok with it, and I think we
could argue that it is a "good thing". It would be a "f_pos" lock (so we
migt do it for reads too), not a "data lock".
Comments?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
