> -----Original Message----- > From: linux-cifs-owner@xxxxxxxxxxxxxxx <linux-cifs-owner@xxxxxxxxxxxxxxx> On > Behalf Of David Disseldorp > Sent: Monday, August 19, 2019 6:04 PM > To: ronnie sahlberg <ronniesahlberg@xxxxxxxxx> > Cc: linux-cifs <linux-cifs@xxxxxxxxxxxxxxx> > Subject: Re: FSCTL_QUERY_ALLOCATED_RANGES issue with Windows2016 > > On Mon, 19 Aug 2019 18:31:51 +0200, David Disseldorp wrote: > > > Nothing stands out in the captures to me, but I'd be curious whether you > > see any differences in behaviour if you set write-through on open or > > explicitly FLUSH after the SET-SPARSE call. > > Hmm actually it looks like there's already a FLUSH shortly after the > mtime update following the SetInfo(EOF). One thing that does look a > little weird is the AllocationSize field before that FLUSH - in > seek_bad.cap.gz it's 2M, whereas it's ~6M in seek_good.cap.gz. Another oddity is that the FSCTL_SET_SPARSE comes *after* the 2MB write. It seems entirely possible that filesystem may have decided to allocate additional blocks during the write, in expectation of more writes. Since the EOF pointer is still 2MB, I believe the filesystem may be well within its rights there. In any event there may be a timing thing going on, because it's doing immediately: write 2MB fsctl SET_SPARSE setinfo EOF=4MB compound open+mtime+close (why a new handle for setting mtime btw?) getinfo flush fsctl QUERY_ALLOCATED_RANGES The NTFS developers were kind of skeptical of the approach of looking at the block allocation counts to detect holes. The first example they mentioned was a small file, like 400 bytes, for which the entire content would fall into the MFT record. Such a file would show zero blocks allocated, regardless of sparseness. Tom.
