適切な準備とFreeBSDでのZFSの使用

少し前に、運用上の増分バックアップを保存するのに十分な容量のアレイを構築するという問題が発生しました。 お金をかけたくありませんでしたが、場所が必要でした。 解決策は十分にシンプルで便利でした。 次はたくさんのテキストです。





基本はSuperChassis 825TQ-560LPBシャーシを採用しました



8個のHitachi 1TBドライブとLSI Logic SAS HBA SAS3081E-Rコントローラーが挿入されました。 ZFSの機能のみに基づいて、ハードウェアレイドなしでスキームを事前に計画しました。



FreeBSD 7.2-STABLEの最初のバージョンのサーバーは約3か月間存続しましたが、この間、使用されたメモリvm.kmem_sizeおよびvfs.zfs.arc_maxの制限という形で主なバグが発見されました。

カーネルに割り当てられたメモリの不足により、システムはパニックに陥り、arc_maxバッファの不足により、動作速度が非常に低下しました。 システムを起動するために、1GBのフラッシュドライブを使用しました。これにより、フラッシュドライブを新しいアセンブリと交換するだけで、システムバージョンを簡単に変更できました。



構築されたアレイの回路は、ディスク(デバイス)の名前によるアドレス指定に基づいていました。

さらに本文には、dmesgおよびコンソール作業コマンドからの挿入があります。

mpt0: <LSILogic SAS/SATA Adapter> port 0x2000-0x20ff mem 0xdc210000-0xdc213fff,0xdc200000-0xdc20ffff irq 16 at device 0.0 on pci3

mpt0: [ITHREAD]

mpt0: MPI Version=1.5.20.0

mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 )

mpt0: 0 Active Volumes (2 Max)

mpt0: 0 Hidden Drive Members (14 Max)



da0 at mpt0 bus 0 scbus0 target 0 lun 0

da0: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da0: 300.000MB/s transfers

da0: Command Queueing enabled

da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da1 at mpt0 bus 0 scbus0 target 1 lun 0

da1: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da1: 300.000MB/s transfers

da1: Command Queueing enabled

da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da2 at mpt0 bus 0 scbus0 target 2 lun 0

da2: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da2: 300.000MB/s transfers

da2: Command Queueing enabled

da2: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da3 at mpt0 bus 0 scbus0 target 3 lun 0

da3: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da3: 300.000MB/s transfers

da3: Command Queueing enabled

da3: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da4 at mpt0 bus 0 scbus0 target 4 lun 0

da4: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da4: 300.000MB/s transfers

da4: Command Queueing enabled

da4: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da5 at mpt0 bus 0 scbus0 target 5 lun 0

da5: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da5: 300.000MB/s transfers

da5: Command Queueing enabled

da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da6 at mpt0 bus 0 scbus0 target 7 lun 0

da6: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da6: 300.000MB/s transfers

da6: Command Queueing enabled

da6: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da7 at mpt0 bus 0 scbus0 target 8 lun 0

da7: <ATA Hitachi HDE72101 A31B> Fixed Direct Access SCSI-5 device

da7: 300.000MB/s transfers

da7: Command Queueing enabled

da7: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

ugen3.2: <JetFlash> at usbus3

umass0: <JetFlash Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2> on usbus3

umass0: SCSI over Bulk-Only; quirks = 0x0100

umass0:2:0:-1: Attached to scbus2

da8 at umass-sim0 bus 0 scbus2 target 0 lun 0

da8: <JetFlash Transcend 1GB 8.07> Removable Direct Access SCSI-2 device

da8: 40.000MB/s transfers

da8: 963MB (1972224 512 byte sectors: 64H 32S/T 963C)

Trying to mount root from ufs:/dev/ufs/FBSDUSB







原則として、すべてが多かれ少なかれ明確です。 コントローラがあり、月があり、ディスクがあり、コントローラに接続されたデバイスの名前があります。

 backupstorage#zpool create storage raidz da0 da1 da2 da3 da4 da5 da6 da7
 backupstorage#zpool status -v
  プール:ストレージ
 状態:オンライン
 スクラブ:要求なし
構成:

        名前状態読み取り書き込みCKSUM
        ストレージオンライン0 0 0
           raidz1オンライン0 0 0
             da0オンライン0 0 0
             da1オンライン0 0 0
             da2オンライン0 0 0
             da3オンライン0 0 0
             da4 ONLINE 0 0 0
             da5オンライン0 0 0
             da6オンライン0 0 0
             da7オンライン0 0 0

エラー:既知のデータエラーはありません




ドライブの1つが死ぬまで、すべてが機能します。 7番目のディスクは崩れ始め、コントローラーはタイムアウトでアレイからそれを捨てました。 また、ディスクは完全に新品であり、負荷がかかっていなかったため、ディスク自体が落下するという確信はありませんでした。

日立DFTはエラーを検出せず、すべてが正常であり、時折スローダウンするだけだと言いました。 MHDDは、アクセス時間が約500ミリ秒の多くのセクターを見つけました。これらのセクターのうち50セクターが保証期間中にドライブを変更したばかりです。



しかし、ドライブは実際それほど悪くはありません。 ドライブは克服されましたが、その障害の間に見つかった問題が私を考えさせました。



問題1:ディスク番号が月に付いていないアレイ

Solaris ZFSは、これらのコントローラーのコントローラー番号と衛星にマップされたドライブを使用して設計されました。 このようなアカウンティングスキームを使用する場合、デッドディスクを交換し、アレイ内のデータを同期するだけで十分です。 FreeBSDでは、Linuxと同様に、デバイスの命名は通常透過的であり、コントローラーの物理ポートに依存しません。 これは実際には最大の待ち伏せです。

たとえば、システムからディスク5を取り出し、ディスク上のハードウェア障害をエミュレートします。

 backupstorage#camcontrolすべてを再スキャン
バス0の再スキャンが成功しました
バス1の再スキャンが成功しました
バス2の再スキャンが成功しました

 mpt0:mpt_cam_event:0x16
 mpt0:mpt_cam_event:0x12
 mpt0:mpt_cam_event:0x16
 mpt0:mpt_cam_event:0x16
 mpt0:mpt_cam_event:0x16
 (da4:mpt0:0:4:0):失われたデバイス
 (da4:mpt0:0:4:0):キャッシュの同期に失敗しました、ステータス== 0x4a、scsiステータス== 0x0
 (da4:mpt0:0:4:0):デバイスエントリの削除

 backupstorage#zpool status -v
  プール:ストレージ
 状態:劣化
 スクラブ:要求なし
構成:

        名前状態読み取り書き込みCKSUM
        ストレージの劣化0 0 0
           raidz1劣化0 0 0
             da0オンライン0 0 0
             da1オンライン0 0 0
             da2オンライン0 0 0
             da3オンライン0 0 0
             da4が削除されました0 0 0
             da5オンライン0 0 0
             da6オンライン0 0 0
             da7オンライン0 0 0


すべてが素晴らしいです。 コントローラは、ドライブを紛失したことを確認し、紛失としてマークしました。

新しいディスクを挿入して、アレイを同期できます。 ただし、サーバーを再起動すると、

非常に興味深い画像があなたを待っています(画面がテキストで過負荷にならないように、dmesgクォータから不要な情報を削除します)

da0 at mpt0 bus 0 scbus0 target 0 lun 0

da0: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da1 at mpt0 bus 0 scbus0 target 1 lun 0

da1: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da2 at mpt0 bus 0 scbus0 target 2 lun 0

da2: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da2: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da3 at mpt0 bus 0 scbus0 target 3 lun 0

da3: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da3: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da4 at mpt0 bus 0 scbus0 target 5 lun 0

da4: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da4: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da5 at mpt0 bus 0 scbus0 target 7 lun 0

da5: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

da6 at mpt0 bus 0 scbus0 target 8 lun 0

da6: <ATA Hitachi HDE72101 A31B> Fixed Direct Access SCSI-5 device

da6: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

SMP: AP CPU #1 Launched!

GEOM: da0: the primary GPT table is corrupt or invalid.

GEOM: da0: using the secondary instead -- recovery strongly advised.

GEOM: da1: the primary GPT table is corrupt or invalid.

GEOM: da1: using the secondary instead -- recovery strongly advised.

GEOM: da2: the primary GPT table is corrupt or invalid.

GEOM: da2: using the secondary instead -- recovery strongly advised.

GEOM: da3: the primary GPT table is corrupt or invalid.

GEOM: da3: using the secondary instead -- recovery strongly advised.

GEOM: da4: the primary GPT table is corrupt or invalid.

GEOM: da4: using the secondary instead -- recovery strongly advised.

GEOM: da5: the primary GPT table is corrupt or invalid.

GEOM: da5: using the secondary instead -- recovery strongly advised.

GEOM: da6: the primary GPT table is corrupt or invalid.

GEOM: da6: using the secondary instead -- recovery strongly advised.

ugen3.2: <JetFlash> at usbus3

umass0: <JetFlash Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2> on usbus3

umass0: SCSI over Bulk-Only; quirks = 0x0100

umass0:2:0:-1: Attached to scbus2

da7 at umass-sim0 bus 0 scbus2 target 0 lun 0

da7: <JetFlash Transcend 1GB 8.07> Removable Direct Access SCSI-2 device

da7: 40.000MB/s transfers

da7: 963MB (1972224 512 byte sectors: 64H 32S/T 963C)

Trying to mount root from ufs:/dev/ufs/FBSDUSB

GEOM: da4: the primary GPT table is corrupt or invalid.

GEOM: da4: using the secondary instead -- recovery strongly advised.

GEOM: da5: the primary GPT table is corrupt or invalid.

GEOM: da5: using the secondary instead -- recovery strongly advised.

GEOM: da0: the primary GPT table is corrupt or invalid.

GEOM: da0: using the secondary instead -- recovery strongly advised.

GEOM: da1: the primary GPT table is corrupt or invalid.

GEOM: da1: using the secondary instead -- recovery strongly advised.

GEOM: da2: the primary GPT table is corrupt or invalid.

GEOM: da2: using the secondary instead -- recovery strongly advised.

GEOM: da3: the primary GPT table is corrupt or invalid.

GEOM: da3: using the secondary instead -- recovery strongly advised.

GEOM: da6: the primary GPT table is corrupt or invalid.

GEOM: da6: using the secondary instead -- recovery strongly advised.

GEOM: da4: the primary GPT table is corrupt or invalid.

GEOM: da4: using the secondary instead -- recovery strongly advised.







何が見えますか?

最初のdmesgダンプと比較すると、9個ではなく8個のデバイスがあり、フラッシュドライブはda8ではなくda7になりました。 ZFSは、GPTタグの読み取りに問題があり、すべてが悪いことを誓い始めます。

ディスクの番号付けが1になり、Zpoolが愚かにも目の前でばらばらになりました。その結果、作業のためのランドマークが失われ、ディスクラベルが混乱しました。

 backupstorage#zpool status -v
  プール:ストレージ
 状態:UNAVAIL
ステータス:ラベルがないため、1つ以上のデバイスを使用できませんでした
        または無効です。 続行するにはプールのレプリカが不十分です
        機能します。
アクション:バックアップソースからプールを破棄して再作成します。
   参照:http://www.sun.com/msg/ZFS-8000-5E
 スクラブ:要求なし
構成:

        名前状態読み取り書き込みCKSUM
        ストレージUNAVAIL 0 0 0不十分なレプリカ
           raidz1 UNAVAIL 0 0 0レプリカが不十分です
             da0オンライン0 0 0
             da1オンライン0 0 0
             da2オンライン0 0 0
             da3オンライン0 0 0
             da4 FAULTED 0 0 0破損したデータ
             da5 FAULTED 0 0 0破損したデータ
             da6 FAULTED 0 0 0破損したデータ
             da6オンライン0 0 0


2つあることに注意してください!!! ドライブda6。 これはすべて、da6として定義された物理ディスクがあり、ディスクにda6であったGPTラベルda6があるためです。



次に、引き出したディスクを貼り付けます。

backupstorage# camcontrol rescan all

Re-scan of bus 0 was successful

Re-scan of bus 1 was successful

Re-scan of bus 2 was successful



da8 at mpt0 bus 0 scbus0 target 4 lun 0

da8: <ATA Hitachi HDT72101 A31B> Fixed Direct Access SCSI-5 device

da8: 300.000MB/s transfers

da8: Command Queueing enabled

da8: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

GEOM: da8: the primary GPT table is corrupt or invalid.

GEOM: da8: using the secondary instead -- recovery strongly advised.







ディスクは決定されましたが、da8になりました。 もちろん、アレイを再構築することもできますが、何も良い結果にはなりません。 したがって、過負荷になります。

 backupstorage#zpool status -v
  プール:ストレージ
 状態:オンライン
 スクラブ:要求なし
構成:

        名前状態読み取り書き込みCKSUM
        ストレージオンライン0 0 0
           raidz1オンライン0 0 0
             da0オンライン0 0 0
             da1オンライン0 0 0
             da2オンライン0 0 0
             da3オンライン0 0 0
             da4 ONLINE 0 0 0
             da5オンライン0 0 0
             da6オンライン0 0 0
             da7オンライン0 0 0

エラー:既知のデータエラーはありません




再起動後、zfsは静かにすべてのディスクを見つけ、ログを少し誓い、動作を続けます。



GEOM: da0: the primary GPT table is corrupt or invalid.

GEOM: da0: using the secondary instead -- recovery strongly advised.

GEOM: da1: the primary GPT table is corrupt or invalid.

GEOM: da1: using the secondary instead -- recovery strongly advised.

GEOM: da2: the primary GPT table is corrupt or invalid.

GEOM: da2: using the secondary instead -- recovery strongly advised.

GEOM: da3: the primary GPT table is corrupt or invalid.

GEOM: da3: using the secondary instead -- recovery strongly advised.

GEOM: da4: the primary GPT table is corrupt or invalid.

GEOM: da4: using the secondary instead -- recovery strongly advised.

GEOM: da5: the primary GPT table is corrupt or invalid.

GEOM: da5: using the secondary instead -- recovery strongly advised.

GEOM: da6: the primary GPT table is corrupt or invalid.

GEOM: da6: using the secondary instead -- recovery strongly advised.

GEOM: da7: the primary GPT table is corrupt or invalid.

GEOM: da7: using the secondary instead -- recovery strongly advised.

GEOM: da0: the primary GPT table is corrupt or invalid.

GEOM: da0: using the secondary instead -- recovery strongly advised.

GEOM: da2: the primary GPT table is corrupt or invalid.

GEOM: da2: using the secondary instead -- recovery strongly advised.

GEOM: da7: the primary GPT table is corrupt or invalid.

GEOM: da7: using the secondary instead -- recovery strongly advised.







resilverは壊れた配列のデータを処理しなかったため、ほとんど問題なく実行されます。

 GEOM:da0:プライマリGPTテーブルが破損しているか無効です。
 GEOM:da0:代わりにセカンダリを使用-復旧を強くお勧めします。
 GEOM:da3:プライマリGPTテーブルが破損しているか無効です。
 GEOM:da3:代わりにセカンダリを使用-復旧を強くお勧めします。
 ======================

 backupstorage#zpool status -v
  プール:ストレージ
 状態:オンライン
  scrub:2009年11月25日水曜日11:06:15に0h0m後にエラーなしでresilverが完了しました
構成:

        名前状態読み取り書き込みCKSUM
        ストレージオンライン0 0 0
           raidz1オンライン0 0 0
             da0オンライン0 0 0
             da1オンライン0 0 0
             da2 ONLINE 0 0 0 512再同期
             da3 ONLINE 0 0 0 512再同期
             da4 ONLINE 0 0 0
             da5オンライン0 0 0
             da6 ONLINE 0 0 0 512再同期
             da7 ONLINE 0 0 0 512再同期

エラー:既知のデータエラーはありません


一般に、コントローラ内のディスクの自動番号付けでは、このようなスキームはあまり信頼できないと確信していました。 ただし、ディスクの数が変わらない場合は、ランダムな順序で並べ替えることができます。 アレイは適切に機能します。



2番目の問題:ディスク上のgeomlabel。

ディスクの命名に関する問題を解決するために、ラベルでディスクをマークし、アレイにラベルを追加することを決定しました。 ディスク上にラベルを作成する場合-ディスクの最後に書き込まれ、ディスクが初期化されると、システムはラベルを読み取り、仮想デバイス/ dev / label / labelを作成します。

 backupstorage#zpool create storage raidz label / disk0 label / disk1 label / disk2 label / disk3 label / disk4 label / disk5 label / disk6 label / disk7
 backupstorage#zpool status -v
  プール:ストレージ
 状態:オンライン
 スクラブ:要求なし
構成:

        名前状態読み取り書き込みCKSUM
        ストレージオンライン0 0 0
           raidz1オンライン0 0 0
            ラベル/ disk0 ONLINE 0 0 0
            ラベル/ disk1 ONLINE 0 0 0
            ラベル/ disk2 ONLINE 0 0 0
            ラベル/ disk3 ONLINE 0 0 0
            ラベル/ disk4 ONLINE 0 0 0
            ラベル/ disk5 ONLINE 0 0 0
            ラベル/ disk6 ONLINE 0 0 0
            ラベル/ disk7 ONLINE 0 0 0

エラー:既知のデータエラーはありません
 backupstorage#ls / dev / label / disk *
 / dev / label / disk0 / dev / label / disk2 / dev / label / disk4 / dev / label / disk6
 / dev / label / disk1 / dev / label / disk3 / dev / label / disk5 / dev / label / disk7


アレイは正常に動作しますが、今度はdisk1を引き出して脇に置きます。



サーバーを再起動し、ログを確認します。

 GEOM:da0:破損または無効なGPTが検出されました。
 GEOM:da0:GPTは拒否されました-回復できない可能性があります。
 GEOM:da1:破損または無効なGPTが検出されました。
 GEOM:da1:GPTが拒否されました-回復できない可能性があります。
 GEOM:da2:破損または無効なGPTが検出されました。
 GEOM:da2:GPTは拒否されました-回復できない可能性があります。
 GEOM:da3:破損または無効なGPTが検出されました。
 GEOM:da3:GPTは拒否されました-回復できない可能性があります。
 GEOM:da4:破損または無効なGPTが検出されました。
 GEOM:da4:GPTは拒否されました-回復できない可能性があります。
 GEOM:da5:破損または無効なGPTが検出されました。
 GEOM:da5:GPTは拒否されました-回復できない可能性があります。
 GEOM:da6:破損または無効なGPTが検出されました。
 GEOM:da6:GPTは拒否されました-回復できない可能性があります。
 GEOM:ラベル/ disk0:破損または無効なGPTが検出されました。
 GEOM:ラベル/ disk0:GPTは拒否されました-回復できない可能性があります。
 GEOM:ラベル/ disk2:破損または無効なGPTが検出されました。
 GEOM:ラベル/ disk2:GPTは拒否されました-回復できない可能性があります。
 GEOM:ラベル/ disk3:破損または無効なGPTが検出されました。
 GEOM:ラベル/ disk3:GPTは拒否されました-回復できない可能性があります。
 GEOM:ラベル/ disk4:破損または無効なGPTが検出されました。
 GEOM:ラベル/ disk4:GPTは拒否されました-回復できない可能性があります。
 GEOM:ラベル/ disk5:破損または無効なGPTが検出されました。
 GEOM:ラベル/ disk5:GPTは拒否されました-回復できない可能性があります。
 GEOM:ラベル/ disk6:破損または無効なGPTが検出されました。
 GEOM:ラベル/ disk6:GPTは拒否されました-回復できない可能性があります。
 GEOM:ラベル/ disk7:破損または無効なGPTが検出されました。
 GEOM:ラベル/ disk7:GPTは拒否されました-回復できない可能性があります。
 umass-sim0 bus 0 scbus2 target 0 lun 0のda7
 da7:<JetFlash Transcend 1GB 8.07>リムーバブルダイレクトアクセスSCSI-2デバイス
 da7:40.000MB / s転送
 da7:963MB(1972224 512バイトセクター:64H 32S / T 963C)
 ufsからルートをマウントしようとしています:/ dev / ufs / FBSDUSB
 GEOM:da0:破損または無効なGPTが検出されました。
 GEOM:da0:GPTは拒否されました-回復できない可能性があります。
 GEOM:da1:破損または無効なGPTが検出されました。
 GEOM:da1:GPTが拒否されました-回復できない可能性があります。
 GEOM:ラベル/ disk2:破損または無効なGPTが検出されました。
 GEOM:ラベル/ disk2:GPTは拒否されました-回復できない可能性があります。
 GEOM:da2:破損または無効なGPTが検出されました。
 GEOM:da2:GPTは拒否されました-回復できない可能性があります。
 GEOM:ラベル/ disk3:破損または無効なGPTが検出されました。
 GEOM:ラベル/ disk3:GPTは拒否されました-回復できない可能性があります。
 GEOM:da3:破損または無効なGPTが検出されました。
 GEOM:da3:GPTは拒否されました-回復できない可能性があります。
 GEOM:ラベル/ disk4:破損または無効なGPTが検出されました。
 GEOM:ラベル/ disk4:GPTは拒否されました-回復できない可能性があります。
 GEOM:da4:破損または無効なGPTが検出されました。
 GEOM:da4:GPTは拒否されました-回復できない可能性があります。
 GEOM:ラベル/ disk5:破損または無効なGPTが検出されました。
 GEOM:ラベル/ disk5:GPTは拒否されました-回復できない可能性があります。
 GEOM:da5:破損または無効なGPTが検出されました。
 GEOM:da5:GPTは拒否されました-回復できない可能性があります。


しかし、すべての悪用により、アレイは生きていることが判明しました。 活気に満ちた構造とステータスDEGRADEDを持ち、これは最初の場合よりもはるかに優れています。

 backupstorage#zpool status
  プール:ストレージ
 状態:劣化
 status:1つ以上のデバイスで回復不能なエラーが発生しました。 あ
        エラーを修正しようとしました。 アプリケーションは影響を受けません。
アクション:デバイスの交換が必要かどうかを判断し、エラーをクリアします
         「zpool clear」を使用するか、デバイスを「zpool replace」に置き換えます。
   参照:http://www.sun.com/msg/ZFS-8000-9P
 スクラブ:要求なし
構成:

        名前状態読み取り書き込みCKSUM
        ストレージの劣化0 0 0
           raidz1劣化0 0 0
            ラベル/ disk0 ONLINE 0 0 0
            ラベル/ disk1削除0 94 0
            ラベル/ disk2 ONLINE 0 0 0
            ラベル/ disk3 ONLINE 0 0 0
            ラベル/ disk4 ONLINE 0 0 0
            ラベル/ disk5 ONLINE 0 0 0
            ラベル/ disk6 ONLINE 0 0 0
            ラベル/ disk7 ONLINE 0 0 0

エラー:既知のデータエラーはありません
 ======================


次に、引き出したディスクをゼロにし、システムに挿入し直します。

ディスク上のラベルはディスクの最後に記録されるため、ディスクの先頭を定期的にゼロにすることは役に立ちません。 終わりをゼロにするか、ディスク全体をゼロにする必要があります。 それはすべてあなたの時間に依存します。

 mpt0:mpt_cam_event:0x16
 mpt0:mpt_cam_event:0x12
 mpt0:mpt_cam_event:0x16
 mpt0バス0のda8、scbus0ターゲット1、lun 0
 da8:<ATA Hitachi HDT72101 A31B>固定ダイレクトアクセスSCSI-5デバイス
 da8:300.000MB / s転送
 da8:有効なコマンドキューイング
 da8:953869MB(1953525168 512バイトセクター:255H 63S / T 121601C)


新しいディスクに「disk8」というラベルを付け、「死んだ」ディスクを新しいディスクと交換しようとします。

 backupstorage#ls / dev / label /
 disk0 disk2 disk3 disk4 disk5 disk6 disk7 disk8

 backupstorage#zpool replace storage label / disk1 label / disk8
 label / disk1をlabel / disk8に置き換えることはできません:label / disk8 is busy
 backupstorage#zpool replace -f storage label / disk1 label / disk8
 label / disk1をlabel / disk8に置き換えることはできません:label / disk8 is busy


システムは、その忙しさを理由に、ドライブの変更を拒否します。 「死んだ」ディスクを交換できるのは、デバイスの直接名のみです。 なぜこれが行われるのか、完全には理解していませんでした。 新しいディスクのラベルを交換するという考えを捨てて、新しいディスクにラベル「disk1」を付けようとします。

 backupstorage#glabelラベルdisk1 da8


ここで、ドライブが動作を再開したと言う必要があります。

 backupstorage#zpool online storage label / disk1
 backupstorage#zpool status
  プール:ストレージ
 状態:オンライン
 status:1つ以上のデバイスで回復不能なエラーが発生しました。 あ
        エラーを修正しようとしました。 アプリケーションは影響を受けません。
アクション:デバイスの交換が必要かどうかを判断し、エラーをクリアします
         「zpool clear」を使用するか、デバイスを「zpool replace」に置き換えます。
   参照:http://www.sun.com/msg/ZFS-8000-9P
  scrub:2009年11月25日水曜日18:29:17に0エラーで0h0m後にresilverが完了しました
構成:

        名前状態読み取り書き込みCKSUM
        ストレージオンライン0 0 0
           raidz1オンライン0 0 0
            ラベル/ disk0 ONLINE 0 0 0 6.50K resilvered
            ラベル/ disk1 ONLINE 0 94 1 10.5K再同期
            ラベル/ disk2 ONLINE 0 0 0 6K再同期
            ラベル/ disk3 ONLINE 0 0 0 3.50K再同期
            ラベル/ disk4 ONLINE 0 0 0 6.50K再同期
            ラベル/ disk5 ONLINE 0 0 0 6.50K再同期
            ラベル/ disk6 ONLINE 0 0 0 5.50K再同期
            ラベル/ disk7 ONLINE 0 0 0 3K再同期

エラー:既知のデータエラーはありません


すべてが適切に配置され、同期後、プールステータスを通常にリセットできます。

そして、ここから問題が始まります。 glabelによって作成されたディスクラベルはディスクの最後に書き込まれるため、zfsは基本的にどこに書き込まれるかについて何も知りません。 そして、ディスクがいっぱいになると、このラベルがほつれます。 アレイ内のディスクには物理名が付けられ、問題のポイント1に戻ります。



問題解決

問題の解決策は少し平凡でシンプルでした。 昔々、FreeBSDは大きなディスクでGPTパーティションを作成できるようになりました。 FreeBSD 7.2では、GPTパーティションの命名が機能せず、直接デバイス名/ dev / da0p1を使用してアクセスが行われました(最初のGPTパーティションの例)

FreeBSD 8.0では、GPTタグシステムに変更が加えられました。 また、GPTパーティションに名前を付けて、/ dev / gpt / partitionラベルを介してそれらを仮想デバイスとして参照できるようになりました。



本当に必要なのは、ディスク上のパーティションの名前を変更し、そこからアレイを組み立てるだけです。 それを行う方法はZFS Boot Howtoで書かれています。

 backupstorage#gpart create -s GPT ad0
 backupstorage#gpart add -b 34 -s 1953525101 -i 1 -t freebsd-zfs -l disk0 ad0
 backupstorage#gpart show
 => 34 1953525101 da0 GPT(932G)
           34 1953525101 1 freebsd-zfs(932G)
 backupstorage#gpart show -l
 => 34 1953525101 da0 GPT(932G)
           34 1953525101 1 disk0(932G)
 backupstorage#ls / dev / gpt
 disk0


gpart showで GPTセクションを作成した後、ディスク上のデータ領域の始まりと終わりを確認できます。 次に、このパーティションを作成し、ラベル「disk0」を付けます。

システム内のすべてのディスクに対してこの操作を実行し、結果のパーティションからアレイを収集します。

 backupstorage#zpool status -v
  プール:ストレージ
 状態:オンライン
 スクラブ:要求なし
構成:

        名前状態読み取り書き込みCKSUM
        ストレージオンライン0 0 0
           raidz1オンライン0 0 0
             gpt / disk0オンライン0 0 0
             gpt / disk1オンライン0 0 0
             gpt / disk2 ONLINE 0 0 0
             gpt / disk3 ONLINE 0 0 0
             gpt / disk4 ONLINE 0 0 0
             gpt / disk5 ONLINE 0 0 0
             gpt / disk6 ONLINE 0 0 0
             gpt / disk7 ONLINE 0 0 0

エラー:既知のデータエラーはありません


サーバーは、ディスクの再起動と再配置、および同じラベルとの交換を静かに生き延びます。 ネットワーク上のこのアレイの速度は、毎秒70〜80メガバイトに達します。 バッファの占有率に応じて、アレイへのローカル書き込み速度は200メガバイト/秒に達します。



PS:gptタグを使用しているときに、システムがディスク上の新しいラベルを認識しないという奇妙な不具合に遭遇しましたが、その後は自動的にパスしました。

PPS:(まだ修復されていない場合)USBフラッシュドライブからFreeBSD 8.0を実行しようとする愛好家にとって、この汚いハックは役に立ちます。

Index: sys/kern/vfs_mount.c

===================================================================

RCS file: /home/ncvs/src/sys/kern/vfs_mount.c,v

retrieving revision 1.308

diff -u -r1.308 vfs_mount.c

--- sys/kern/vfs_mount.c 5 Jun 2009 14:55:22 -0000 1.308

+++ sys/kern/vfs_mount.c 29 Sep 2009 17:08:25 -0000

@@ -1645,6 +1645,9 @@

options = NULL;

+ /* NASTY HACK: wait for USB sticks to appear */

+ pause("usbhack", hz * 10);

+

root_mount_prepare();

mount_zone = uma_zcreate("Mountpoints", sizeof(struct mount),







新しいUSBスタックでは、カーネルをロードするときに、USBデバイスが時間どおりに常に検出されるとは限らず、システムパーティションのマウント時にエラーが発生します。

このハックは、システムに10秒のタイムアウトを設定して、USBドライブの準備が整うまで待機します。



PPPS:質問がある場合は尋ねてください。



2ギガバイトのメモリを持つマシンのloader.confを設定します。

vm.kmem_size = "1536M"

vm.kmem_size_max = "1536M"

vfs.zfs.arc_max = "384M"





©Aborche 2009








All Articles