☰

物理セクタサイズが4096のハードドライブは、USBブリッジの背後に512を報告します。

tag-icon • tag-icon hard-disk usb-drive block-device
物理セクタサイズが4096のハードドライブは、USBブリッジの背後に512を報告します。

新しい（2017）4TBハードドライブを購入したため、物理セクタサイズは4096であると予想しました。もちろん、

$ hdparm -I /dev/sdh
  ...
  Logical  Sector size:                   512 bytes
  Physical Sector size:                  4096 bytes
  Logical Sector-0 offset:                  0 bytes
  device size with M = 1000*1000:     4000787 MBytes (4000 GB)

ただし、次のように分割しようとすると、parted物理ブロックサイズは512になります。

$ parted /dev/sdh print
Model:   (scsi)
Disk /dev/sdh: 4001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

152d:0561ドライブは、USBブリッジ（JMicron JMS55チップセット）の背面ドッキングステーション（iTec）のUSB 3ポートにあります。

ブロックレイヤーのサイズも間違っているようです。

$ cat /sys/block/sdh/queue/physical_block_size
512
$ cat /sys/block/sdh/queue/minimum_io_size 
512

SCSIコマンドREAD CAPACITY (16)も誤ったサイズを報告します。

$ sudo sg_readcap --16 /dev/sdh
Read Capacity results:
  Protection: prot_en=0, p_type=0, p_i_exponent=0
  Logical block provisioning: lbpme=0, lbprz=0
  Last logical block address=7814037167 (0x1d1c0beaf),
  Number of logical blocks=7814037168
  Logical block length=512 bytes
  Logical blocks per physical block exponent=0
  Lowest aligned logical block address=0

（他のドライブから）代わりに

  Logical blocks per physical block exponent=3 [so physical block length=4096 bytes]

一方、blockdev報告書によると

$ blockdev --report /dev/sdh
RO    RA   SSZ   BSZ   StartSec            Size   Device
rw   256   512  4096          0   4000787030016   /dev/sdh

インターネット検索で「MBRパーティションテーブル付きの大規模ハードドライブを許可する4k / 512セクタエミュレーション」を実行するUSB​​ブリッジに関するあいまいな情報が見つかりましたが、正しく理解している場合は、このブリッジの論理セクタサイズは4096でなければなりません。私のブリッジではありません。 。

それで、正確に何が起こりましたか？この問題をどのように解決しますか？つまり、カーネルがドライブに4096バイトサイズの物理ブロックがあると信じることができますか？とphysical_block_size属性minimum_io_sizeは書き込めません。

1つの可能な説明は、ブリッジファームウェアにバグがあることです。バグは単にREAD CAPACITY (16)応答の最初の12バイトをコピーし、バイト13の指数を消去します。しかし、この場合でも何とかエラーを解決したいと思います。

編集する

これで別の（旧）USBエンクロージャでテストしました。 eSATAを接続すると、すべてが期待どおりに機能し、READ CAPACITY (16)4096バイトの物理セクタサイズを報告します。 USB（04fc:0c25Sunplus SATALink SPIF225A）を介して接続すると、サポートされていREAD CAPACITY (16)ないという苦情が表示されますが（物理セクタサイズなし）サポートされてREAD CAPACITY (10)います。

これは、少なくともSunplusブリッジの場合、SCSIコマンドはランダムに渡されず、応答をゼロにするJMicron USBブリッジファームウェアにバグがある可能性が高いことを確認しますREAD CAPACITY (16)。

ただし、まだこのエラーを解決する方法を知っておく必要があります。

答え1

man blockdev

   --setbsz bytes
          Set blocksize. Note that the block size is specific to the  cur‐
          rent  file descriptor opening the block device, so the change of
          block size only persists for as long as blockdev has the  device
          open, and is lost once blockdev exits.

存在するブロック/ioctl.c:

case BLKBSZGET: /* get block device soft block size (cf. BLKSSZGET) */
    return put_int(arg, block_size(bdev));
case BLKSSZGET: /* get block device logical block size */
    return put_int(arg, bdev_logical_block_size(bdev));
case BLKPBSZGET: /* get block device physical block size */
    return put_uint(arg, bdev_physical_block_size(bdev));

したがって、BSZはblockdev論理ブロックサイズまたは物理ブロックサイズを報告しません。 「ソフトブロックサイズ」です。

このコードを見ると、ファイル記述子別のソフトブロックサイズの部分が理解できないようです。blockdev他のオプションはブロック（固定サイズ512バイトセクタのみ）として文書化されていないため、どちらかを使用して設定したくありません。

私のテストで実際に起こっていることは、BSZが非常に長い間所定の位置に残っているということです。どのこのプロセスはブロックデバイスを開いたままにします。最後のclose（）でリセットされたようです。

Partedも数年前にこれについて混乱していました。

それを保護してください。 BLKBSZGETは、カーネルがデバイスにアクセスするために選択したブロックサイズです（通常のディスクの場合は1k、ata_ramの場合は4k）。これはベースディスクの論理ブロックサイズではありません。 ：-（したがって、カーネルから正しい値を取得するには別のioctl（）が必要になる可能性があり、BLKSSZGETは最終的にディスクの論理ブロックサイズになる可能性がありますが、新しいioctl（）はディスクの物理セクタサイズを派生します。

もう一つの珍しい点：

2003年4月9日水曜日午後6時53分17秒+0200で、Rob van Nieuwkerkは次のように書いています。

マイシステム（RH 2.4.18-27.7.xカーネル）のマウントされていない複数のパーティションでBLKBSZGETを使用すると、4096が表示されます。一部は1024を提供しています。おそらく最初にインストールしてからテストのために削除したのでしょうか？

これが最も可能性の高い答えです。マウントを解除すると、ファイルシステムがset_blocksize（get_hardsect_size（dev））を妨げるとは思いません。

関連情報