Somewhere between kernels 3.2.0 and 3.3.0 (vanilla kernel), a regression in direct IO occurred. Specifically the commit that introduced it is[1]. I did a git bisect (git url http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git) and rebuilt the kernel for each bisect, ultimately resulting in git reporting that this is the first bad commit. I did my testing on a Cobalt Qube2 with a 64-bit kernel and an n32 userspace (profiles/default/linux/mips/10.0/mipsel/multilib/n32). [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=b1c10bea620f79109b5cc9935267bea4f6f29ac6 Reproducible: Always Steps to Reproduce: 1. Create a random file to be used between the two kernels (before the commit and after the commit). $ dd if=/dev/urandom of=random-file bs=512 count=30720 30720+0 records in 30720+0 records out 15728640 bytes (16 MB) copied, 60.7035 s, 259 kB/s $ chmod -w random-file 2. Reboot to the kernel before the bad commit and run dd with direct io. Repeat. $ uname -a Linux horadric 3.2.0-dirty #2 Fri Jul 13 06:20:22 PDT 2012 mips64 Nevada V10.0 FPU V10.0 Cobalt Qube2 GNU/Linux $ dd if=random-file of=portion-of-random-3.2.0 bs=512 count=20480 iflag=direct 20480+0 records in 20480+0 records out 10485760 bytes (10 MB) copied, 42.3636 s, 248 kB/s $ reboot $ dd if=random-file of=portion-of-random-3.2.0-2 bs=512 count=20480 iflag=direct 20480+0 records in 20480+0 records out 10485760 bytes (10 MB) copied, 42.5252 s, 247 kB/s 3. Reboot to the kernel with the bad commit and run dd with direct io. Repeat. $ uname -a Linux horadric 3.2.0-rc4-00003-gb1c10be-dirty #15 Fri Jul 20 15:05:13 PDT 2012 mips64 Nevada V10.0 FPU V10.0 Cobalt Qube2 GNU/Linux $ dd if=random-file of=portion-of-random-3.2.0-rc4 bs=512 count=20480 iflag=direct 20480+0 records in 20480+0 records out 10485760 bytes (10 MB) copied, 40.6226 s, 258 kB/s $ reboot $ dd if=random-file of=portion-of-random-3.2.0-rc4-2 bs=512 count=20480 iflag=direct 20480+0 records in 20480+0 records out 10485760 bytes (10 MB) copied, 40.8856 s, 256 kB/s 4. Compare checksums of the resulting files. Actual Results: $ sha256sum portion-of-random-3.2.0* c98a6e949b36448842a21f68e7c6a5daff1f161e1eb3e3529176cf56bf5af89e portion-of-random-3.2.0 c98a6e949b36448842a21f68e7c6a5daff1f161e1eb3e3529176cf56bf5af89e portion-of-random-3.2.0-2 dca27da87a78580b8a34bbff2790ae80d3aa880d5d00fc2126f109d6fff9e056 portion-of-random-3.2.0-rc4 703cf02d4fa90679d4a75900e7e5a3b8c3000a65bfc475610b10f17bb88bedbc portion-of-random-3.2.0-rc4-2 Differing checksums on the kernel with the bad commit. Expected Results: $ sha256sum portion-of-random-3.2.0* c98a6e949b36448842a21f68e7c6a5daff1f161e1eb3e3529176cf56bf5af89e portion-of-random-3.2.0 c98a6e949b36448842a21f68e7c6a5daff1f161e1eb3e3529176cf56bf5af89e portion-of-random-3.2.0-2 c98a6e949b36448842a21f68e7c6a5daff1f161e1eb3e3529176cf56bf5af89e portion-of-random-3.2.0-rc4 c98a6e949b36448842a21f68e7c6a5daff1f161e1eb3e3529176cf56bf5af89e portion-of-random-3.2.0-rc4-2 The same checksum on all files.
Is this still true?
Likely fixed by now? If not, please re-open.
