Linux

為什麼檢測 U 盤需要這麼長時間?

  • February 25, 2016

我正在編寫一個 initramfs-script 並希望盡快檢測到 USB 棒。

當我插入一個 USB 2.0 記憶棒時,idVendor、idProduct 和 USB 類的檢測發生在 100 毫秒內。但是 scsi 子系統直到大約 1 秒後才“附加”,並且在完全辨識分區之前還需要 500 毫秒。

我假設驅動程序需要讀取分區表才能檢測分區。為什麼需要這麼長時間?我不希望 urb 發送/接收時間會那麼長,或者快閃記憶體的訪問時間不會花費這麼多時間。

我嘗試了 5 支來自不同供應商的棒,結果大致相同。

[ 5731.097540] usb 2-1.2: new high-speed USB device number 7 using ehci-pci
[ 5731.195360] usb 2-1.2: New USB device found, idVendor=0951, idProduct=1643
[ 5731.195368] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5731.195372] usb 2-1.2: Product: DataTraveler G3
[ 5731.195376] usb 2-1.2: Manufacturer: Kingston
[ 5731.195379] usb 2-1.2: SerialNumber: 001CC0EC32BCBBB04712022C
[ 5731.196942] usb-storage 2-1.2:1.0: USB Mass Storage device detected
[ 5731.197193] scsi host9: usb-storage 2-1.2:1.0
[ 5732.268389] scsi 9:0:0:0: Direct-Access     Kingston DataTraveler G3  PMAP PQ: 0 ANSI: 0 CCS
[ 5732.268995] sd 9:0:0:0: Attached scsi generic sg2 type 0
[ 5732.883939] sd 9:0:0:0: [sdb] 7595520 512-byte logical blocks: (3.88 GB/3.62 GiB)
[ 5732.884565] sd 9:0:0:0: [sdb] Write Protect is off
[ 5732.884568] sd 9:0:0:0: [sdb] Mode Sense: 23 00 00 00
[ 5732.885178] sd 9:0:0:0: [sdb] No Caching mode page found
[ 5732.885181] sd 9:0:0:0: [sdb] Assuming drive cache: write through
[ 5732.903834]  sdb: sdb1
[ 5732.906812] sd 9:0:0:0: [sdb] Attached SCSI removable disk

編輯 所以我發現預設設置為 1 秒的delay_use模組參數,這解釋了我看到的延遲。但是我想知道是否有人可以提供有關為什麼需要該參數的上下文?有評論建議,對於較舊的 USB 記憶棒,可能需要將 delay_use 設置為 5 秒。需要這麼多時間的 U 盤裡面是什麼?韌體初始化;從快閃記憶體讀取?我很難相信當訪問快閃記憶體的延遲大約為幾十微秒時,我們需要長達 1 秒或更長時間的延遲。

我意識到這對於這個頻道來說可能有點離題,如果是這樣,我會去electronics.stackexchange.com

您可以通過寫入來更改超時/sys/module/usb_storage/parameters/delay_use

對於較舊的 USB 磁碟,可能需要 5 秒甚至更長的穩定延遲(並且 5 是預設設置,直到 2010 年減少到 1 秒),大概是因為控制器在磁碟電機初始化時電力不足。或者可能是因為內部 SCSI 韌體在響應之前需要時間來啟動(你能說我只是在這裡推測嗎?)。

對於現代固態儲存,可能根本不需要,很多人都設置為0。不幸的是,它是一個適用於所有設備的全域參數,所以如果你有任何慢速設備,你必須忍受延遲適用於您使用的每個大容量 USB 設備。如果 udev 可以為每個設備設置它會很好,但事實並非如此。

原來有 1 秒超時 int drivers/usb/storage/usb.c。我通過鍵入以下兩個命令啟用了更多調試日誌記錄:

echo 8 > /proc/sys/kernel/printk
echo "module usb_storage +p" > /sys/kernel/debug/dynamic_debug/control
echo 0xFFFFFF > /proc/sys/dev/scsi/logging_level

scsi 子系統有一種奇怪的(與其他 linux 日誌記錄功能相比)指定日誌級別的方式;它們在每個級別都移動了一個步驟,請參閱drivers/scsi/scsi_logging.h

請參閱下面的行starting scan。核心在執行掃描前等待 1 秒。

[21960.837879 <   23.040778>] usb 2-1.2: USB disconnect, device number 18
[21960.838263 <    0.000384>] sd 20:0:0:0: [sg2] sg_remove_device
[21960.838888 <    0.000625>] sd 20:0:0:0: [sg2] sg_device_destroy
[21966.157918 <    5.319030>] usb 2-1.2: new high-speed USB device number 19 using ehci-pci
[21966.251625 <    0.093707>] usb 2-1.2: New USB device found, idVendor=0781, idProduct=5530
[21966.251634 <    0.000009>] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[21966.251638 <    0.000004>] usb 2-1.2: Product: Firebird USB Flash Drive
[21966.251641 <    0.000003>] usb 2-1.2: Manufacturer: SanDisk
[21966.251644 <    0.000003>] usb 2-1.2: SerialNumber: 4C532000001215110130
[21966.252184 <    0.000540>] usb-storage 2-1.2:1.0: USB Mass Storage device detected
[21966.252307 <    0.000123>] scsi host21: usb-storage 2-1.2:1.0
[21966.252439 <    0.000132>] usb-storage 2-1.2:1.0: waiting for device to settle before scanning
[21967.250018 <    0.997579>] usb-storage 2-1.2:1.0: starting scan
[21967.250242 <    0.000224>] usb-storage 2-1.2:1.0: scan complete
[21967.250295 <    0.000053>] scsi host21: scsi_scan_host_selected: <4294967295:4294967295:18446744073709551615>
[21967.250354 <    0.000059>] scsi 21:0:0:0: scsi scan: INQUIRY pass 1 length 36
[21967.251717 <    0.001363>] scsi 21:0:0:0: scsi scan: INQUIRY successful with code 0x0
[21967.251738 <    0.000021>] scsi 21:0:0:0: Direct-Access     SanDisk  Cruzer           1.26 PQ: 0 ANSI: 5
[21967.251745 <    0.000007>] scsi target21:0:0: scsi scan: Sequential scan
[21967.251776 <    0.000031>] scsi 21:0:0:1: scsi scan: INQUIRY pass 1 length 36
[21967.251907 <    0.000131>] scsi 21:0:0:1: scsi scan: INQUIRY failed with code 0x40000
[21967.252282 <    0.000375>] sd 21:0:0:0: sg_alloc: dev=2 
[21967.252366 <    0.000084>] sd 21:0:0:0: Attached scsi generic sg2 type 0
[21967.253703 <    0.001337>] sd 21:0:0:0: [sdb] 7821312 512-byte logical blocks: (4.00 GB/3.72 GiB)
[21967.255324 <    0.001621>] sd 21:0:0:0: [sdb] Write Protect is off
[21967.255334 <    0.000010>] sd 21:0:0:0: [sdb] Mode Sense: 43 00 00 00
[21967.258145 <    0.002811>] sd 21:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[21967.272208 <    0.014063>]  sdb: sdb1
[21967.276433 <    0.004225>] sd 21:0:0:0: [sdb] Attached SCSI removable disk

Linus Torvalds 將較低 USB 儲存穩定延遲中的預設延遲從 5 秒更改為 1 秒,使其更合理。他沒有提供任何關於延遲設置如此之高的技術原因的背景資訊,但暗示它可能只是掩蓋了一些核心錯誤。

引用自:https://unix.stackexchange.com/questions/265450