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 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
