From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pat LaVarre Subject: Re: zeroes read back more often than appended Date: 13 Oct 2003 19:48:57 -0600 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1066096137.3314.32.camel@patehci2> References: <1065553341.8172.45.camel@patehci2> <20031007204951.A25423@falcon.csc.calpoly.edu> <1065732882.5176.14.camel@patehci2> <1065747151.2314.12.camel@patehci2> <1065803984.3037.7.camel@patehci2> <1065809754.3037.105.camel@patehci2> <1066091916.3011.2.camel@patehci2> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from email-out2.iomega.com ([147.178.1.83]:1211 "EHLO email.iomega.com") by vger.kernel.org with ESMTP id S262139AbTJNBtK (ORCPT ); Mon, 13 Oct 2003 21:49:10 -0400 Received: from royntex01.iomegacorp.com (unknown [147.178.90.120]) by email.iomega.com (Postfix) with ESMTP id A100E1B95 for ; Mon, 13 Oct 2003 19:49:09 -0600 (MDT) To: linux-fsdevel@vger.kernel.org In-Reply-To: <1066091916.3011.2.camel@patehci2> List-Id: linux-fsdevel.vger.kernel.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