lkml.org 
[lkml]   [2002]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] zerocopy NFS updated
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/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.183 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site