All of lore.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 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.