ReiserFS, two oddities

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.

Hello!

"Norman Diamond" <[email protected]> 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

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

Andries Brouwer replied to me:

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?

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.

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.

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.