On Wed, Aug 21, 2019 at 3:47 AM Tom Talpey <ttalpey@xxxxxxxxxxxxx> wrote: > > > -----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?) It is because internally in the kernel API setting this timestamps is a path based call. We could search for and see if there is a writeable open handle and use that IF there is such handle but it would be more code and complexity. It was just easier to make it into a compound. It should be cheap enough and have no ill effects. > 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. Ok, fair enough. So if the filesystem has heuristics that can cause it to allocate extra blocks like that (not unreasonable) then it just means that these xfstests make assumptions about the filesystem that are just not guaranteed to be true when used with cifs. That is fair enough. It just means there is no bug. It is just that the test tool is not compatible with ntfs. I can live with that. I do run it against btrfs and there I get the result to allow me to run this part of the test in the regression testsuite. That is good enough for me. Thanks Ronnie Sahlberg > > Tom. >
