On Fri, Apr 12, 2002 at 09:30:11PM +0900, Hirokazu Takahashi wrote:
> Hi,
>
> I wondered if regular truncate() and read() might have the same
> problem, so I tested again and again.
> And I realized it will occur on any local filesystems.
> Sometime I could get partly zero filled data instead of file contents.
>
> I analysis this situation, read systemcall doesn't lock anything
> -- no page lock, no semaphore lock -- while someone truncates
> files partially.
> It will often happens in case of pagefault in copy_user() to
> copy file data to user space.
>
> I guess if needed, it should be fixed in VFS.
I don't see it as a big problem and would just leave it as it is (for NFS
and local)
Adding more locking would slow down read() a lot and there should be
a good reason to take such a performance hit. Linux did this forever
and I don't think anybody ever reported it as a bug, so we can probably
safely assume that this behaviour (non atomic truncate) is not a problem for
users in practice.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 15 2002 - 22:00:20 EST