From: Pat LaVarre <p.lavarre@ieee.org>
To: linux-fsdevel@vger.kernel.org
Subject: Re: zeroes read back more often than appended
Date: 09 Oct 2003 18:52:31 -0600 [thread overview]
Message-ID: <1065747151.2314.12.camel@patehci2> (raw)
In-Reply-To: <1065732882.5176.14.camel@patehci2>
Ouch I see I forgot to mention, when I do see zeroes read back more
often then appended, ...
Often I also see dmesg like those discussed in the recently dead
linux_udf thread "balloc free bit already set and byte minus one".
For example we see:
UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3791 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 3796 already set
UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte=1f
The complete tty log follows.
I see trouble in single writes without these messages, so I guess these
messages are related but not the only cause. Alternatively, these
messages may be loudly discussing normal activity, rather than
complaining of real trouble, I'm too new to know.
Pat LaVarre
$
$ uname -msr
Linux 2.6.0-test7 i686
$
$ dmesg >1
$
$ udfwh mkudffs 0xFFFF 0xC00
+ rm dd.bin
+ dd if=/dev/zero of=dd.bin bs=1M seek=1023 count=1
1+0 records in
1+0 records out
+ ls -l dd.bin
-rw-rw-r-- 1 pat pat 1073741824 Oct 9 18:42 dd.bin
+ sudo losetup /dev/loop0 dd.bin
+ sudo mkudffs
+ head -1
mkudffs 1.0.0b2 for UDF FS 1.0.0-cvs, 2002/02/09
+ sudo mkudffs /dev/loop0
start=0, blocks=16, type=RESERVED
start=16, blocks=3, type=VRS
start=19, blocks=237, type=USPACE
start=256, blocks=1, type=ANCHOR
start=257, blocks=16, type=PVDS
start=273, blocks=1, type=LVID
start=274, blocks=523757, type=PSPACE
start=524031, blocks=1, type=ANCHOR
start=524032, blocks=239, type=USPACE
start=524271, blocks=16, type=RVDS
start=524287, blocks=1, type=ANCHOR
+ sudo mount /dev/loop0 /mnt/loop0
++ id -u
++ id -g
+ sudo chown 500:500 /mnt/loop0/.
+ cd /mnt/loop0
+ wh 0xFFFF 0xC00
0
hexdump -C wh.bin | head -3
00000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa |................|
*
04372000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
real 0m10.480s
user 0m2.787s
sys 0m1.894s
+ cd -
+ sudo umount /mnt/loop0
+ sudo losetup -d /dev/loop0
$
$ dmesg >2
$
$ diff 1 2 | grep '^>'
> he hash table of 4096 buckets, 32Kbytes
> UDF-fs DEBUG fs/udf/lowlevel.c:65:udf_get_last_session: CDROMMULTISESSION not supported: rc=-22
> UDF-fs DEBUG fs/udf/super.c:1544:udf_fill_super: Multi-session=0
> UDF-fs DEBUG fs/udf/super.c:532:udf_vrs: Starting at sector 16 (2048 byte sectors)
> UDF-fs DEBUG fs/udf/super.c:875:udf_load_pvoldesc: recording time 1065746572/73570, 2003/10/09 18:42 (1e98)
> UDF-fs DEBUG fs/udf/super.c:886:udf_load_pvoldesc: volIdent[] = 'LinuxUDF'
> UDF-fs DEBUG fs/udf/super.c:893:udf_load_pvoldesc: volSetIdent[] = '3f86008cLinuxUDF'
> UDF-fs DEBUG fs/udf/super.c:1085:udf_load_logicalvol: Partition (0:0) type 1 on volume 1
> UDF-fs DEBUG fs/udf/super.c:1095:udf_load_logicalvol: FileSet found in LogicalVolDesc at block=32, partition=0
> UDF-fs DEBUG fs/udf/super.c:923:udf_load_partdesc: Searching map: (0 == 0)
> UDF-fs DEBUG fs/udf/super.c:964:udf_load_partdesc: unallocSpaceBitmap (part 0) @ 0
> UDF-fs DEBUG fs/udf/super.c:1005:udf_load_partdesc: Partition (0:0 type 1511) starts at physical 274, block length 523757
> UDF-fs DEBUG fs/udf/super.c:1338:udf_load_partition: Using anchor in block 256
> UDF-fs DEBUG fs/udf/super.c:1571:udf_fill_super: Lastblock=0
> UDF-fs DEBUG fs/udf/super.c:847:udf_find_fileset: Fileset at block=32, partition=0
> UDF-fs DEBUG fs/udf/super.c:909: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/09 18:42 (1e98)
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3791 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 3791 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 3792 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte= 1
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3791 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 3792 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte= 3
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3793 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte= 3
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3791 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 3792 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte= 7
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3793 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte= 7
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3794 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte= 7
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3791 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 3792 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte= f
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3793 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte= f
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3794 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte= f
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3795 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte= f
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3791 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 3792 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte=1f
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3793 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte=1f
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3794 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte=1f
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3795 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte=1f
> UDF-fs DEBUG fs/udf/balloc.c:192:udf_bitmap_free_blocks: bit 3796 already set
> UDF-fs DEBUG fs/udf/balloc.c:193:udf_bitmap_free_blocks: byte=1f
$
next prev parent reply other threads:[~2003-10-10 0:52 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 [this message]
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=1065747151.2314.12.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