From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pat LaVarre Subject: Re: zeroes read back more often than appended Date: 07 Oct 2003 13:02:21 -0600 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1065553341.8172.45.camel@patehci2> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux_udf@hpesjro.fc.hp.com Return-path: Received: from email-out1.iomega.com ([147.178.1.82]:14812 "EHLO email.iomega.com") by vger.kernel.org with ESMTP id S262680AbTJGTCc (ORCPT ); Tue, 7 Oct 2003 15:02:32 -0400 To: linux-fsdevel@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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) ///