Messages in this thread | | | Date | Fri, 12 Apr 2002 14:35:59 +0200 | From | Andi Kleen <> | Subject | Re: [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/
| |