On 11/13/2012 1:20 PM, Richard Brittain wrote: > On Tue, 13 Nov 2012, Jeffrey Altman wrote: > >> On 11/13/2012 11:26 AM, Richard Brittain wrote: >> >>> More testing shows that every time I create this scenario, it is the >>> first 4kB of the file that has been replaced by nulls. The initial test >>> was confusing because some of my test files contain nulls. >> >> The hole in the file is exactly 4KB starting at offset 0? > > Yes - on the examples I was able to examine, it was exactly 4k at the > start of the file.
If it is always 4KB at the beginning of the file I do not think Andrew's patch is going to be the solution. It is certainly worth trying if you can but in this scenario to get a 4KB at the beginning the client would need to have issued an RXAFS_FetchData() for offset 0 and length 0 and have received back 0 bytes and status info indicating that the new length of the file is 4KB. I believe that Andrew's patch addresses the case where a chunksize is say 64KB and the client issues a read for 1KB and the file server says the file is really 4KB in length. The client would show 1KB of data followed by a 3KB hole. Andrew, please correct me if I'm wrong. >> How large are the files? > > 20-200MB. I never saw it on smaller files, or on very large files, but > that might be luck. > >> Is the file being written by a Windows client or by a Linux client? > > Windows and Mac clients. I was initially testing your latest Windows > client, but then got suspicious that this was either server or > read-client related, and nothing to do with the writing client, so I > reproduced it (easily) from a Mac. The reason I ask this is that the Windows client does not have write on close semantics and will write 4KB blocks. If the first 4KB block of the file is still in use it is possible for 4KB+1 to some later 4KB multiple to be written first. If you can reproduce this from a OSX then it isn't going to have anything to do with the Windows writing pattern. > I only used linux for the reading client. > > >> I would like to see a tcpdump of the Linux client with (fs setcrypt off) >> for this output. > > I'll see what I can do. I think it will be very important in isolating the relevant code path. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
