On 5/20/2013 5:02 AM, Lars Schimmer wrote: > Moin! > > My laptop has a flaky connection to my home cable WLAN. > I use Windows 7 x64 en on my laptop with OpenAFS 1.7.24. > > Servers: OpenAFS 1.6.2-1 Debian. > > Now I copy over 15GB of pictures (~2000 files), and try to copy them > into OpenAFS filespace with total commander or explorer. > My upload speed is somewhat in the 600 kbyte/sec, so this upload doies > run unattended during the night. > > With the flaky WLAN it ends up with ~10-20 files with brocken checksums, > although copy did not broke and all files do have same filesize as original. > > IMHO files were copied successfull into local cache, and were flushed > onto servers. While that flush a connection does time out, but OpenAFS > does somehow work around it. And on basic check of filesize/date no > problems are to be seen. > > Any quick way to debug this? Or do I need to go onto package level? > > (yeah, real solution would be fixing my WLAN, but imho customers with 3G > do have flaky lines although from time to time and files should not > corrupt due to this)
Lars, Please file a bug report to [email protected] so the issue can be tracked properly. In your bug report provide as much detail as you can as to the details of the corruption and any correlation you can make between loss of connectivity to the servers (logged to the Windows Application Event log) and any logs you have of when the files were copied. To try to explain what I mean by details of the corruption. 1. Does the corruption reliably begin on a 1K, 4K, or other offset? 2. Does the corruption reliably end on a 1K, 4K, or other offset? 3. Is the corruption consistently a block of NULs? 4. Is the corruption consistently some other pattern? 5. Does the length of the files make a difference? When writing data to AFS the data is written to the Windows Cache Manager unless the application requests "no intermediate buffering". When data is written to the Windows Cache up to 8MB of data per file can be cached before any data is written to AFS. The data is written via the lazy writer thread which may not send the data to AFS until after the application has initiated the CloseHandle() request on the file handle. If the error occurs during CloseHandle() it is unlikely that the application will be able to respond. AFS is very aggressive about retrying data writes in case of network failures. Anyway, please file a bug report and the issue will be researched. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
