Re: RAID6: "Bad block number requested"

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

 



On Mon, 2018-06-11 at 17:56 -0400, Bryan Gurney wrote:
> 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.

We've done the work to make this function.  However, it was a while ago
and I don't believe anyone tests regularly now (particularly with the
corner cases) so errors can creep back into the stack.

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

This is a textbook case of something that can never work: The
requirement for a 4k drive is that the stack must be aligned, meaning
4k or multiple of 4k block size all the way up and down.  The isofs
you're copying only has a 2k block size.  You get the same failure with
any non 4k multiple filesystem block size.  Fortunately most modern
filesystems have had 4k, or multiple thereof, block sizes for a while
now, so you're unlikely to see this on your old ext4 devices but, in
principle, it could happen.

James


> 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