From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Fennema Subject: Re: zeroes read back more often than appended Date: Tue, 7 Oct 2003 20:49:51 -0700 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20031007204951.A25423@falcon.csc.calpoly.edu> References: <1065553341.8172.45.camel@patehci2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux_udf@hpesjro.fc.hp.com Return-path: Received: from falcon.csc.calpoly.edu ([129.65.242.5]:15088 "EHLO falcon.csc.calpoly.edu") by vger.kernel.org with ESMTP id S261660AbTJHEM0 (ORCPT ); Wed, 8 Oct 2003 00:12:26 -0400 To: Pat LaVarre Content-Disposition: inline In-Reply-To: <1065553341.8172.45.camel@patehci2>; from p.lavarre@ieee.org on Tue, Oct 07, 2003 at 01:02:21PM -0600 List-Id: linux-fsdevel.vger.kernel.org I can't repeat this on 2.4 or 2.6.0-test6 non-smp. I'll see if I can figure out whats going on in 2.6.0-test6-smp. Somehow unrecorded block(s) are getting inserted in the data. Ben On Tue, Oct 07, 2003 at 01:02:21PM -0600, Pat LaVarre wrote: > Maybe I should have cc'ed linux-fsdevel@vger.kernel.org when I launched > this thread in linux_udf@hpesjro.fc.hp.com ... > > -----Forwarded Message----- > > Subject: zeroes read back more often than appended > Date: 06 Oct 2003 21:54:15 -0600 > To: linux_udf@hpesjro.fc.hp.com > > Is it legit to combine mkudffs 1.0.0b2 with linux-2.6.0-test6? > > And to run mkudffs on top of a loop device? > > I ask because: > > I wrote the following short programs (a bash script and a C routine) to > fopen, iterate "height" times to fwrite a "width" of bytes once or > repeatedly, and fclose. > > With mkfs and ext3, I see this trivial code reliably produces expected > results i.e. a file full of '\xAA' e.g. > > 00000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |................| > * > 00fffff0 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |...............| > > With linux-2.6.0-test6 mkudffs and udf.ko of 1 GiB loop device, I see > this trivial code reliably produces wrong results for certain small > width and height combinations, such as: > > udfwh mkudffs 0xFFFF 0xC00 > udfwh mkudffs 0xFFFFFF 0xB > udfwh mkudffs 0xFFFFFFF 0x1 > udfwh mkudffs 0x7800000 0x1 > > With mkudffs, my results grow indeterminate below somewhere near the > 0x7800000 boundary (120 MiB). 0x7400000 often fails. My logs tell me > 0x7298000 once failed for me, but I can't easily repeat that result. > > My wrong results have lots of zeroes in place of the data written e.g. > > hexdump -C wh.bin | head -3 > 00000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |................| > * > 0375e000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > > Every time I've looked, the zeroes appear aligned to at least 2 KiB > boundaries. > > Explanations, anyone? > > Pat LaVarre > > /// udfwh > > #!/bin/bash -x > > rm dd.bin > dd if=/dev/zero of=dd.bin bs=1M seek=1023 count=1 > ls -l dd.bin > sudo losetup /dev/loop0 dd.bin > sudo $1 2>&1 | head -1 > sudo $1 /dev/loop0 > sudo mount /dev/loop0 /mnt/loop0 > sudo chown `id -u`:`id -g` /mnt/loop0/. > cd /mnt/loop0 > time wh $2 $3 > cd - > sudo umount /mnt/loop0 > sudo losetup -d /dev/loop0 > > /// wh.c > > #include > #include > #include > #include > > int main(int argc, char * argv[]) // 0xFF600 0xC8 > { > int width; > int height; > char * chars; > char nonzero; > FILE * fi; > int i; > int rc; > char const * st; > > --argc; ++argv; > assert(argc == 2); > rc = sscanf(argv[0], "0x%X", &width); > assert(rc == 1); > rc = sscanf(argv[1], "0x%X", &height); > assert(rc == 1); > > nonzero = '\xAA'; > chars = malloc(width); > assert(chars != NULL); > memset(&chars[0], nonzero, width); > > fi = fopen("wh.bin", "wb"); > assert(fi != NULL); > for (i = 0; i < height; ++i) { > fprintf(stderr, "\r%d ", height - i - 1); > rc = fwrite(chars, 1, width, fi); > assert(rc == width); > } > rc = fclose(fi); > assert(rc == 0); > fprintf(stderr, "\n"); > > st = "hexdump -C wh.bin | head -3"; > fprintf(stderr, "%s\n", st); > (void) system(st); > > return 0; > } > > /// dmesg (boring, I think?) > > > UDF-fs DEBUG fs/udf/lowlevel.c:65:udf_get_last_session: CDROMMULTISESSION not supported: rc=-22 > > UDF-fs DEBUG fs/udf/super.c:1471:udf_fill_super: Multi-session=0 > > UDF-fs DEBUG fs/udf/super.c:459:udf_vrs: Starting at sector 16 (2048 byte sectors) > > UDF-fs DEBUG fs/udf/super.c:802:udf_load_pvoldesc: recording time 1065498482/249678, 2003/10/06 21:48 (1e98) > > UDF-fs DEBUG fs/udf/super.c:813:udf_load_pvoldesc: volIdent[] = 'LinuxUDF' > > UDF-fs DEBUG fs/udf/super.c:820:udf_load_pvoldesc: volSetIdent[] = '3f823772LinuxUDF' > > UDF-fs DEBUG fs/udf/super.c:1012:udf_load_logicalvol: Partition (0:0) type 1 on volume 1 > > UDF-fs DEBUG fs/udf/super.c:1022:udf_load_logicalvol: FileSet found in LogicalVolDesc at block=32, partition=0 > > UDF-fs DEBUG fs/udf/super.c:850:udf_load_partdesc: Searching map: (0 == 0) > > UDF-fs DEBUG fs/udf/super.c:891:udf_load_partdesc: unallocSpaceBitmap (part 0) @ 0 > > UDF-fs DEBUG fs/udf/super.c:932:udf_load_partdesc: Partition (0:0 type 1511) starts at physical 274, block length 523757 > > UDF-fs DEBUG fs/udf/super.c:1265:udf_load_partition: Using anchor in block 256 > > UDF-fs DEBUG fs/udf/super.c:1498:udf_fill_super: Lastblock=0 > > UDF-fs DEBUG fs/udf/super.c:774:udf_find_fileset: Fileset at block=32, partition=0 > > UDF-fs DEBUG fs/udf/super.c:836:udf_load_fileset: Rootdir at block=34, partition=0 > > UDF-fs INFO UDF 0.9.7 (2002/11/15) Mounting volume 'LinuxUDF', timestamp 2003/10/06 21:48 (1e98)