afs: Skip checking chunkBytes sanity for RW files
Currently, the IsDCacheSizeOK check can trigger a false positive for a
dcache, if the data in the dcache was populated by a local write to a
file that was later extended with sparse data.
For example: say a client opens a new file, and writes 4 bytes to
offset 0, and then writes 4 bytes to offset 0x400000. After the first
write, the first chunk for the file will contain just 4 bytes, and
after the second write, the first chunk is unchanged (since we're
writing to a different area of the file), but the file is now 0x400004
bytes long. The sparse area of the file will be correctly filled with
zeroes for local reads and on the fileserver, but the 4-byte chunk
causes IsDCacheSizeOK to complain and mark the dcache as invalid.
Even though nothing is wrong, this causes the following scary messages
to potentially appear in the kernel log, and the relevant dcache to be
invalidated:
afs: Detected corrupt dcache for file 1.
536870913.2.2: chunk 0 (offset 0) has 4 bytes, but it should have 131072 bytes
afs: (dcache 0xfffffdeadbeefb4d, file length 4194308, DV 1, dcache mtime
1575049956, index 996, dflags 0x2, mflags 0x0, states 0x4, vcache states 0x1)
afs: Ignoring the dcache for now, but this may indicate corruption in the AFS cache, or a bug.
It's probably difficult or impossible to detect if this specific case
is happening, so to avoid this scenario, just avoid doing the size
check at all for RW data from the cache.
Change-Id: Ia40ec838c525d9abc13a03be39028e4ca04a9457
Reviewed-on: https://gerrit.openafs.org/13969
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>