From: "Norman Diamond" <ndiamond@wta.att.ne.jp>
To: "Hans Reiser" <reiser@namesys.com>, <linux-kernel@vger.kernel.org>
Subject: ReiserFS, two oddities
Date: Sun, 26 Oct 2003 16:37:26 +0900 [thread overview]
Message-ID: <334201c39b94$286e7ae0$24ee4ca5@DIAMONDLX60> (raw)
This is tangential to my observations about bad blocks (which the disk's
firmware refused to reallocate during reads, writes, and S.M.A.R.T. long
self-tests). I have had two odd observations which seem related to ReiserFS
on perfectly good blocks.
Here is partial output from fdisk's p command, copied by hand:
/dev/hda8 18169578 29431079 5630751 83 Linux
The first two numbers are the partition's starting and ending LBA sector
numbers. fdisk's u command kindly toggles these between cylinder numbers
and LBA sector numbers. The third number is the quantity of 1K Linux blocks
in the file system, and does not get toggled by fdisk's u command.
The sector is readable if I ignore partitions:
# dd if=/dev/hda of=/dev/null bs=512 skip=29431074 count=1
1+0 records in
1+0 records out
but not if I address it from inside the partition:
# dd if=/dev/hda8 of=/dev/null bs=512 skip=11261496 count=1
dd: reading `/dev/hda8': Input/output error
0+0 records in
0+0 records out
LBA sector number 29431074 is inside the partition. 18169578 + 11261496 =
29431074, verified several times. 11261496 / 2 = 5630748, verified only
twice, but it is within the quantity of 1K Linux blocks that the partition
has. Why is the sector unreadable when read from inside the partition?
Let's try a minimal, shouldn't-be-helpful sanity test.
# dd if=/dev/hda8 of=/dev/null bs=512 skip=11261495 count=1
1+0 records in
1+0 records out
Yup, it succeeded, and doesn't help explain the problem 1 sector later.
The second strange observation is that reiserfsck with no options, applied
to a non-mounted partition, seems to write to the partition while replaying
journaled transactions. When repeated, the number of replayed transactions
is 0, so I think the first execution wrote to the partition. (If the
partition had been mounted then of course ordinary operations would get get
journaled transactions merged into the file system, but I guarantee that
this observation occured on a non-mounted partition.) reiserfsck 3.6.4
starts by saying that it will read-only check consistency, but the fact
seems to be read-mostly.
next reply other threads:[~2003-10-26 7:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-26 7:37 Norman Diamond [this message]
2003-10-26 8:47 ` ReiserFS, two oddities Oleg Drokin
2003-10-26 12:20 ` Andries Brouwer
2003-10-26 13:43 ` Norman Diamond
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='334201c39b94$286e7ae0$24ee4ca5@DIAMONDLX60' \
--to=ndiamond@wta.att.ne.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=reiser@namesys.com \
/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