All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Fennema <bfennema@falcon.csc.calpoly.edu>
To: Pat LaVarre <p.lavarre@ieee.org>
Cc: linux-fsdevel@vger.kernel.org, linux_udf@hpesjro.fc.hp.com
Subject: Re: zeroes read back more often than appended
Date: Tue, 7 Oct 2003 20:49:51 -0700	[thread overview]
Message-ID: <20031007204951.A25423@falcon.csc.calpoly.edu> (raw)
In-Reply-To: <1065553341.8172.45.camel@patehci2>; from p.lavarre@ieee.org on Tue, Oct 07, 2003 at 01:02:21PM -0600

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 <assert.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> 
> 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)

  parent reply	other threads:[~2003-10-08  4:12 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-07 19:02 zeroes read back more often than appended Pat LaVarre
2003-10-07 20:54 ` Pat LaVarre
2003-10-08  3:49 ` Ben Fennema [this message]
2003-10-08 16:41   ` Pat LaVarre
2003-10-08 16:47     ` editable udf metadata Pat LaVarre
2003-10-08 17:51       ` Pat LaVarre
2003-10-08 18:09         ` big-endian udfct_1_0r2 Pat LaVarre
2003-10-08 18:30           ` Matthew Wilcox
     [not found]             ` <3F8472FE.9040403@lougher.demon.co.uk>
2003-10-08 19:49               ` Matthew Wilcox
2003-10-08 20:43             ` Phillip Lougher
2003-10-21 21:54         ` editable udf metadata Pat LaVarre
2003-10-21 23:17           ` Pat LaVarre
2003-10-23 16:06             ` Pat LaVarre
2003-10-24 21:40               ` Pat LaVarre
2003-10-22  8:15           ` same page access Mark B
2003-10-22 11:21             ` Matthew Wilcox
2003-10-22 17:09               ` Mark B
2003-10-22 17:10                 ` Matthew Wilcox
2003-10-08 17:02     ` zeroes read back more often than appended Pat LaVarre
2003-10-08 17:06       ` toggling smp clears x86_mce_p4thermal of make xconfig Pat LaVarre
2003-10-08 17:21     ` zeroes read back more often than appended Pat LaVarre
2003-10-08 16:46   ` soft trace of read/write of drivers/block/loop.c Pat LaVarre
2003-10-08 20:32   ` zeroes read back more often than appended Pat LaVarre
2003-10-09 20:54   ` Pat LaVarre
2003-10-10  0:52     ` Pat LaVarre
2003-10-10 16:39       ` Pat LaVarre
2003-10-10 18:15         ` Pat LaVarre
2003-10-14  0:38           ` Pat LaVarre
2003-10-14  1:48             ` Pat LaVarre
2003-10-20 23:20               ` Pat LaVarre
2003-10-21 14:47                 ` Pat LaVarre
2003-10-21 16:46                   ` Pat LaVarre
2003-10-21 18:44                     ` Pat LaVarre
2003-10-23 18:52                     ` Pat LaVarre
2003-10-27 21:55                       ` Pat LaVarre
  -- strict thread matches above, loose matches on Subject: below --
2003-11-20 16:41 Pat LaVarre
2003-11-27  0:45 ` Pat LaVarre
2003-11-28 18:20   ` Pat LaVarre
2003-11-28 18:29     ` Pat LaVarre
2003-12-11 18:42 Pat LaVarre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031007204951.A25423@falcon.csc.calpoly.edu \
    --to=bfennema@falcon.csc.calpoly.edu \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux_udf@hpesjro.fc.hp.com \
    --cc=p.lavarre@ieee.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.