Hello. While running xfstests on an SMB share exposed by a Windows Server 2022 VM running on my laptop, I found an unpleasant surprise: a single run subtracted 1.5% of the write resource of my SSD, which is quite a lot. Could you please modify the test to avoid this booby trap? Or actually, let me do it myself... The root cause is that the test runs this command: src/looptest -i 10000 -t -r -w -s -b 102400 /mnt/test/looptest/looptest2.tst strace shows this pattern: lseek(3, 0, SEEK_SET) = 0 ftruncate(3, 0) = 0 lseek(3, 1013145600, SEEK_SET) = 1013145600 write(3, "\0\1\2\3\4\5\6\7\10\t\n\v\f\r\16\17\20\21\22\23\24\25\26\27\30\31\32\33\34\35\36\37"..., 102400) = 102400 lseek(3, 1013145600, SEEK_SET) = 1013145600 read(3, "\0\1\2\3\4\5\6\7\10\t\n\v\f\r\16\17\20\21\22\23\24\25\26\27\30\31\32\33\34\35\36\37"..., 102400) = 102400 lseek(3, 0, SEEK_SET) = 0 ftruncate(3, 0) = 0 lseek(3, 1013248000, SEEK_SET) = 1013248000 write(3, "\0\1\2\3\4\5\6\7\10\t\n\v\f\r\16\17\20\21\22\23\24\25\26\27\30\31\32\33\34\35\36\37"..., 102400) = 102400 lseek(3, 1013248000, SEEK_SET) = 1013248000 read(3, "\0\1\2\3\4\5\6\7\10\t\n\v\f\r\16\17\20\21\22\23\24\25\26\27\30\31\32\33\34\35\36\37"..., 102400) = 102400 This is completely OK for filesystems that support sparse files, however, such 1-gigabyte seeks are emulated by Windows as 1-gigabyte writes because the NTFS filesystem does not actually support sparse files. The result is the "looptest2" part of the test writes more than 4 TB of data. I think that the test should be preceded by a small check of whether files intended to be sparse are actually sparse. If not, either fail or skip the test. I might be able to create a patch in the next few hours... -- Alexander E. Patrakov
