ReiserFS, two oddities

ReiserFS, two oddities

[Norman Diamond]

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.

Re: ReiserFS, two oddities

[Oleg Drokin]

Hello!

"Norman Diamond" <ndiamond@wta.att.ne.jp> wrote:

ND> The sector is readable if I ignore partitions:
ND>   # dd if=/dev/hda of=/dev/null bs=512 skip=29431074 count=1
ND>   1+0 records in
ND>   1+0 records out
ND> but not if I address it from inside the partition:
ND>   # dd if=/dev/hda8 of=/dev/null bs=512 skip=11261496 count=1
ND>   dd: reading `/dev/hda8': Input/output error
ND>   0+0 records in
ND>   0+0 records out
ND> LBA sector number 29431074 is inside the partition.  18169578 + 11261496 =
ND> 29431074, verified several times.  11261496 / 2 = 5630748, verified only
ND> twice, but it is within the quantity of 1K Linux blocks that the partition
ND> has.  Why is the sector unreadable when read from inside the partition?

This is known problem that nobody wants to deal with.
When you mount some fs, it sets device's blocksize to fs' blocksize
(e.g.) 4k for reiserfs, if the size of the device was not multiple of
4k, everything that forms last partial block gets sort of stripped and you
cannot access it anymore. Even if you decrease blocksize of the block device
later, you still won't get that missing data back until reboot.
This is even more unfortunate on architectures with big pagesize where
block devices are often assigned blocksizes equal to PAGE_SIZE.
This behavior was observed on linux v2.4, not sure about 2.6

ND> The second strange observation is that reiserfsck with no options, applied
ND> to a non-mounted partition, seems to write to the partition while replaying
ND> journaled transactions.  When repeated, the number of replayed transactions

Yes, replaying journal obviously requires writes ;)

ND> is 0, so I think the first execution wrote to the partition.  (If the
ND> partition had been mounted then of course ordinary operations would get get
ND> journaled transactions merged into the file system, but I guarantee that
ND> this observation occured on a non-mounted partition.)  reiserfsck 3.6.4
ND> starts by saying that it will read-only check consistency, but the fact
ND> seems to be read-mostly.

Well, checking is checking and journal replaying is a different matter,
that is even done before starting checks.

Bye,
    Oleg

Re: ReiserFS, two oddities

[Andries Brouwer]

On Sun, Oct 26, 2003 at 04:37:26PM +0900, Norman Diamond wrote:

> 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 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?

If I understand you correctly, there may never have been a bad block.
That is good for Toshiba, no reason to say bad things about their disks.

Also, if there was no bad block, then no reallocation is needed.

You show that dd reads this sector without problems.
But you see an I/O error when it is just at the edge of the partition.
That I/O error may well be generated by Linux, not by the disk.

The details depend on kernel version, and I forgot what kernel
you used. Try  blockdev --getbsz /dev/hda  to see what blocksize
Linux is using. If that is 4096, that is 8 sectors, but only 6 sectors
remain in the partition. Try  blockdev --setbsz 512 /dev/hda
and read again. Maybe this would succeed.

Andries


[didnt you get error messages in dmesg?]

Re: ReiserFS, two oddities

[Norman Diamond]

Andries Brouwer replied to me:

> > 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 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?
>
> If I understand you correctly, there may never have been a bad block.
> That is good for Toshiba, no reason to say bad things about their disks.

Dream on.  LBA sector number 29431074 might or might not be near LBA sector
number 19021882, but 19021882 was indeed bad.  I already posted the filename
of the file which used to contain that block (it took about two days of
"find"ing and "cp"ing to /dev/null to find which file it was), and already
posted several of my dd's of the LBA sector number in the non-partitioned
device /dev/hda.  Dr. Brouwer, you know quite a lot about disks, how could
you possibly pick on the situation with sector 29431074 and pretend that
this explains the ton of observations about sector 19021882?

> Also, if there was no bad block, then no reallocation is needed.

Hey, I've received about 30 spams today trying to sell the kind of drugs
that you seem to have taken today.

By the way, after sector 19021882 was reallocated, the S.M.A.R.T log showed
that the number of reallocations had increased from 3 to 4.  And further
reads had no more failures and no more reallocations after that one finally
took place.  So the drive even disagrees with you, although it took ages and
an unknown amount of experiments to get it there.

Dr. Brouwer, I know that you know more about disk drives than you pretend to
in this message.  Please try to avoid spreading misinformation.

> You show that dd reads this sector without problems.
> But you see an I/O error when it is just at the edge of the partition.
> That I/O error may well be generated by Linux, not by the disk.

Yes, this one was, as explained by Oleg Drokin because of the 4K cluster
size in ReiserFS.  This is still unrelated to the genuinely bad block.

> [didnt you get error messages in dmesg?]

I get so many boot errors about other things that scroll off the screen
without getting into dmesg, sometimes I wonder why I still bother testing.
Meanwhile, dmesg has a few comments from ReiserFS about properly
initializing itself with respect to partitions, but no boot-time errors in
ReiserFS.