Re: RAID6: "Bad block number requested"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 11, 2018 at 1:00 PM, Anthony Youngman
<anthony@xxxxxxxxxxxxxxx> wrote:
> On 11/06/18 16:06, James Bottomley wrote:
>> Well, this is the problem: a 4k logical (presumably 4k physical) drive
>> cannot be addressed in block sectors that are not divisible by 8.  This
>> type of drive configuration is very unusual (although it was something
>> we tested years ago before the industry realised it had to ship drives
>> with 4k physical but 512 byte logical sectors because of the legacy
>> problem).
> I understood these drives were now becoming much more common, especially
> enterprise-grade drives. I know there were problems switching from
> 512/512 drives to 512/4096, but as you say I thought they were pretty
> much addressed.

As soon as I saw the model number "HGST HUH721010AL", and did a
search, I said, "Oh, it's _this_ drive."

The HGST Ultrastar He10 has both "512e Format" and "4K Native Format"
part numbers, so it's easy to potentially buy the wrong type of drive
(e.g.: accidentally buy a 4K Native drive, and discover some obscure
I/O failures).

FYI, in my experience, when an application sends a
smaller-than-4096-bytes I/O to a 4096-bytes block device, the usual
error code that's sent by the driver is EINVAL (or "Invalid
argument"), so see if there's a log message citing that error code.

> I think it must be a couple of years ago now though, that I heard (on
> LWN) enterprise drives were apparently switching over to 4096/4096. With
> NO 512 emulation fall-back.

Some drive manufacturers seem to be more eager than others, but
there's still work to be done.  For example, try this with a 4K-native
drive:

1. Write an ISO image to the drive with the command "dd if=isofile.iso
of=/dev/testdevice bs=4096 oflag=direct"

2. Create a test directory (for example, "/mnt/testdir"), then attempt
to mount the device with "mount /dev/testdevice /mnt/testdir"

When I tried it on RHEL 7.5, I saw this: "kernel: isofs_fill_super:
bread failed, dev=testdevice, iso_blknum=17, block=-2147483648"

Note that ISO filesystems have a 2048-byte block size (maximum), but
in this test, it's stored on a block device with a block size of 4096
bytes.

There may be more issues out there, but they have to be found first.
And finding the issues is difficult, due to the obscurity of the error
messages seen.


Thanks,

Bryan



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux