public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pat LaVarre <p.lavarre@ieee.org>
To: linux-fsdevel@vger.kernel.org
Subject: Re: zeroes read back more often than appended
Date: 10 Oct 2003 10:39:44 -0600	[thread overview]
Message-ID: <1065803984.3037.7.camel@patehci2> (raw)
In-Reply-To: <1065747151.2314.12.camel@patehci2>

Offline we spoke of trying again without letting loop.ko allot any of
the blocks of backing store i.e. patching the test script to write all
blocks:

- dd if=/dev/zero of=dd.bin bs=1M seek=1023 count=1
+ dd if=/dev/zero of=dd.bin bs=1M seek=0 count=1024

Definitely I very much appreciate the suggestion ...

But I regret to report that here I see that patch only slows down the
test, it does not change the results.

Still for me the quick reliably troublesome test cases are such as:

time udfwh mkudffs 0xFFFF 0xC00
time udfwh mkudffs 0xFFFFFF 0xC

Given that I'm now actually waiting to write a disk image full of
zeroes, I've shrunk the disk to 256 MiB from 1024 GiB. Conveniently I
find I see trouble.  With slightly fewer writes, whether I see trouble
and whether dmesg complains varies.

Indeed, at least twice now, I've seen my kernel crash, though possibly
only back when I was letting loop.ko allot blocks of backing store.

Pat LaVarre

-- example tty log

$
$ # more zeroes read than appended, but no dmesg
$ #
$ time udfwh mkudffs 0xFFFFFF 0xA
Linux 2.6.0-test7 i686
/mnt/hda11
dd if=/dev/zero of=dd.bin bs=1M seek=0 count=256 2>/dev/null
-rw-rw-r--    1 pat      pat      268435456 Oct 10 10:27 dd.bin
mkudffs 1.0.0b2 for UDF FS 1.0.0-cvs, 2002/02/09
0
hexdump -C wh.bin | head -3
00000000  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
*
0098b000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 
real    0m15.199s
user    0m3.307s
sys     0m2.956s
$
$ # no trouble, read back only the appended bytes, no zeroes
$ #
$ time udfwh mkudffs 0xFFFFFF 0xA
Linux 2.6.0-test7 i686
/mnt/hda11
dd if=/dev/zero of=dd.bin bs=1M seek=0 count=256 2>/dev/null
-rw-rw-r--    1 pat      pat      268435456 Oct 10 10:27 dd.bin
mkudffs 1.0.0b2 for UDF FS 1.0.0-cvs, 2002/02/09
0
hexdump -C wh.bin | head -3
00000000  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
*
09fffff0  aa aa aa aa aa aa                                 |......|
 
real    0m14.377s
user    0m3.275s
sys     0m2.684s
$
$ ...
$ # troublesome zeroes together with menacing dmesg
$ #
$ time udfwh mkudffs 0xFFFFFF 0xA
Linux 2.6.0-test7 i686
/mnt/hda11
dd if=/dev/zero of=dd.bin bs=1M seek=0 count=256 2>/dev/null
-rw-rw-r--    1 pat      pat      268435456 Oct 10 10:30 dd.bin
mkudffs 1.0.0b2 for UDF FS 1.0.0-cvs, 2002/02/09
0
hexdump -C wh.bin | head -3
00000000  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
*
0853f000  00 00 00 00 00 00 00 00  aa aa aa aa aa aa aa aa  |................|
+++ 2.dmesg     2003-10-10 10:30:43.095187696 -0600
+8 already set
+UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 2919 already set
+UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte=ffffff80
+UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 2919 already set
[...]
 
real    0m16.222s
user    0m3.330s
sys     0m2.929s
$

--- udfwh (new version)

#!/bin/bash

uname -msr
pwd
rm dd.bin
cmd='dd if=/dev/zero of=dd.bin bs=1M seek=255 count=1'
cmd='dd if=/dev/zero of=dd.bin bs=1M seek=0 count=256'
echo "$cmd 2>/dev/null"
$cmd 2>/dev/null
ls -l dd.bin

sudo losetup /dev/loop0 dd.bin
sudo $1 2>&1 | head -1
sudo $1 /dev/loop0 >/dev/null

sudo mount /dev/loop0 /mnt/loop0
sudo chown `id -u`:`id -g` /mnt/loop0/.
dmesg >1.dmesg
cd /mnt/loop0
wh $2 $3
cd -
dmesg >2.dmesg

diff -u 1.dmesg 2.dmesg | grep '^\+' | head -5
rm 1.dmesg 2.dmesg
sudo umount /mnt/loop0
sudo losetup -d /dev/loop0

--- wh.c (same version as before, no change)

#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;
}

---



  reply	other threads:[~2003-10-10 16:39 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
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 [this message]
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=1065803984.3037.7.camel@patehci2 \
    --to=p.lavarre@ieee.org \
    --cc=linux-fsdevel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox