On Thu, 23 May 2024 at 14:54, David Disseldorp <ddiss@xxxxxxxxx> wrote: > > On Wed, 22 May 2024 11:36:25 +0100, David Howells wrote: > > > David Disseldorp <ddiss@xxxxxxxxx> wrote: > > > ... > > > I think the best way to proceed here would be to capture traffic for the > > > same workload against a Windows SMB server. This could be don't by using > > > your cifs.ko workload or extending test_ioctl_sparse_qar_malformed(). > > > > I don't have a windows server I can try. Steve may be able to try that. > > I'll put it on my todo list for the next time I have a Windows VM > sitting around. I do recall testing Samba alongside Windows when doing > the initial implementation, but QAR is very FS block / allocation size > specific, so 1:1 behaviour isn't straightforward (nor is it required by > the FSCTL_QUERY_ALLOCATED_RANGES / FSCTL_SET_ZERO_DATA specs). I recall talks with microsoft folks on the list about these as well and I think they were problematic because ntfs and other windows filesystems do not really have the same semantics at tha tlinux has. I think one issue is that "set-zero" nothing more than a hint and depending on phase-of-moon and how the server feels might sometimes punch a hole, might sometimes fill in a hole or do a combination. The behaviour was hinted could even differ from one run to the next on the same server, because reasons. There were other issues as well making the behavior unpredictable becase one could not assume the alignment of blocks, or if it would even be constant throughout the file. It might be best to just ignore tests that fail in this area. And just accept that some things, at best, is a best-effort approximation. (as long as dataloss does not happen, of course. That is never acceptable) At the end of the day it is a lot of guesswork and trying to fit a square peg (unpredictable ntfs behavior) into a round hole (linux vfs api). > > Cheers, David >
