Re: zeroes read back more often than appended

[Pat LaVarre <p.lavarre@ieee.org>]

> Try again with both CONFIG_SMP and CONFIG_PREEMPT turned off.
> 
> I'm delight to report: works for me!!
> 
> Specifically, three times in a row, I passed the test:
> 
> ddudfwh mkudffs 65535 3072
> 
> Next I will again try to start machines running for days looking for
> trouble.  Many thanks.

In my first trial, the time to failure running less controlled tests
here seemingly increased to 2 minutes, from the 0.5 minutes I had
learned to expect.  My second trial ran for 3 minutes.  My third trial
ran for 3 minutes.

Again I read back zeroes where I thought I appended data, and again I
see bursts of dmesg complaints of
fs/udf/balloc.c:192/193:udf_bitmap_free_blocks.

Sorry I was wrong to hope my tests would run much longer.

I'll start the hunt for a new, well-controlled, repeatable test that
quickly causes trouble with SMP and PREEMPT off.  By the rules of this
game of course I remain committed to suspecting my kluge-your-own test
software ... but since for this particular test neither 2 KiB/block nor
zeroes is special, I feel like I want to guess my test code is not at
issue.

My basic setup remains:

time dd of=dd.bin bs=1M count=1024 if=/dev/zero
sudo losetup /dev/loop0 dd.bin
sudo mkudffs /dev/loop0
sudo mount /dev/loop0 /mnt/loop0
sudo chown `id -g`:`id -u` /mnt/loop0/.
cd /mnt/loop0
...

Pat LaVarre

P.S. With SMP and PREEMPT off, well-controlled test cases that
disappoint me by correctly reading the appended data rather than zeroes
now include:

ddudfwh mkudffs 1046016 200
udfwh mkudffs 0xFF600 0xC8
udfwh mkudffs 0xFFFF 0xC00