一部のファイルをNAS(ShareCenter DNS-320)に移動しようとしていますが、ファイルマネージャの使用にはいくつかの問題があります。
Input/Output error
または、マウントされたcifs / smb共有でrsyncを使用している場合
rsync: close failed on "/mnt/nas1/_am-unordered/.long-file-name.mkv.PI2rPM": Input/output error (5)
rsync error: error in file IO (code 11) at receiver.c(856) [receiver=3.1.0]
# mount | grep mnt/nas1
//192.168.x.y/backup on /mnt/nas1 type cifs (rw,relatime,vers=1.0,cache=strict,username=admin,domain=BACKUP,uid=1000,forceuid,gid=0,noforcegid,addr=192.168.x.y,file_mode=0755,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)
NASの内部に不良セクタがあると仮定し、fsck
RAID-0 NASの内部に破損したディスクがあることを確認する必要があります。
fun_plug
これを使ってインストールしました。地図時間今、NASに正常にSSHを接続することができます。通常、私はこの方法を使用して、fsck -yvckfC -E fragcheck /dev/sdX
マウントされていない単一ディスクの不良セクタを特定します。
問題は、バッドブロックをどのように実行し、マウントされたRAID0パーティションのバッドブロックのリストに挿入するかです。 SSHサービスはNASにマウントされたパーティションで実行されるため:
# umount /mnt/HD/HD_a2/
umount: /mnt/HD/HD_a2: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
# lsof /mnt/HD/HD_a2/
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sh 1963 root 1w REG 9,1 5191 12 /mnt/HD/HD_a2/ffp.log
sh 1963 root 2w REG 9,1 5191 12 /mnt/HD/HD_a2/ffp.log
sh 1963 root 10r REG 9,1 1942 246939802 /mnt/HD/HD_a2/fun_plug
rc 1986 root txt REG 9,1 587316 141426950 /mnt/HD/HD_a2/ffp/bin/bash
rc 1986 root mem REG 9,1 28892 139854377 /mnt/HD/HD_a2/ffp/lib/ld-uClibc-0.9.33-git.so
rc 1986 root mem REG 9,1 260898 139853932 /mnt/HD/HD_a2/ffp/lib/libreadline.so.6.2
**snip**
sshd 5519 root mem REG 9,1 60546 139854375 /mnt/HD/HD_a2/ffp/lib/libgcc_s.so.1
sshd 5519 root mem REG 9,1 359940 139854378 /mnt/HD/HD_a2/ffp/lib/libuClibc-0.9.33-git.so
NASの現在のRAID構成は次のとおりです。
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1]
md1 : active raid0 sda2[0] sdb2[1]
7808789888 blocks 64k chunks
md0 : active raid1 sdb1[1] sda1[0]
524224 blocks [2/2] [UU]
unused devices: <none>
ベストアンサー1
badblocks
そもそも問題が解決されるため、不安定な前提で作業します。
badblocks
修正を信頼できない理由
ハードドライブを使用すると、新しいセクタを信頼できないセクタに置き換えて、問題を隠すために常に最善を尽くします。ハードドライブは、この目的のためのスペアセクタプールとともに工場で出荷されます。新しい不良セクタの数がゆっくりと増加する限り、予備セクタのプールもゆっくりと減少し、ハードドライブはそのまま残る。現れる完璧に動作します。
不良セクタを検索する唯一の方法badblocks
は、スペアセクタプールが使い果たされた場合、つまり一定期間のパフォーマンスが低下した場合です。言い換えれば、目立つ不良セクタは、ハードドライブがあまりにも多くの問題を覆い隠したため、カーペットがぼやけて見え始めたことを意味します。
私が知っている限り、ハードドライブはおそらく初期から数十年の間自動修理を行ってきました。統合開発環境。私が作業した最後のシステムは、最初から初期の不良セクタセットが公開されていました。静電気放電指数そして自己顕微鏡ハードドライブの歴史は1980年代後半にさかのぼります。
だからといって、最新のハードドライブにもはや初期の不良セクタセットが提供されていないという意味ではありません。彼らは。不良セクタは工場でマッピングされているため、badblocks
新しいハードドライブでテストすると表示されます。若い不良セクタ。 (スペアセクタプールのセクタは、不良セクタを置き換えるようにマッピングされます。)
badblocks
検査の結果、新しいドライブまたはまだ保証期間が残っているドライブで不良セクタが見つかった場合は、すぐに交換する必要がある十分な理由になります。
badblocks
ファイルシステムの不良セクタリストが機能するのに十分な長さの一貫した結果を返すことができます。これにより、ドライブのセルフリカバリ機能が機能しなくなっても、保証期間が過ぎたり交換できないハードドライブを引き続き使用できます。
ただし、間隔が近いテスト間でbadblocks
異なる結果を返すことも可能です。 (たとえば、1日または1週間の間隔で2回テストを実行します。)ハードドライブがこれらの不良状態に入ると、ファイルシステムの不良セクタのリストは意味をなさなくなります。ファイルシステムの不良セクタのリストは、リストが長期間安定している場合にのみ利点を提供します。
ポイント:まだ読みやすい状態でハードドライブを交換してください。はい、これはNAS全体を再構築することを意味するかもしれませんが、これはRAID-0です。恐ろしいRAID」。
より良いソリューション:モニタリング
時間の経過とともにスペアセクタプールのサイズを追跡できない場合、セクタスワップが発生したことを知りません。賢い。追跡したい場合でも、一部のハードドライブはこれを報告しませんが、この情報を提供するハードドライブは報告するだけです。真実の修正版文字通りの真実ではなく
つまり、このコマンドは知っておくべきことを伝えることができます。
# smartctl -x /dev/sda | grep Realloc
5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
196 Reallocated_Event_Count -O--CK 200 200 000 - 0
元の値と正規化された値ですが、smartctl
レポートは完全に正確ではないかもしれません。ここで数字を増やすこと、特に短期間で大きな増加をするのは常に悪いことです。
このコマンドを実行しているコンピューターでは、最後の列は0です。私がこのレポートを完全に信頼できないかもしれないということは、これが私が言う意味です。これは「生」値で、「200」列は「正規化された」値です。ドライブは再割り当てされたことがないと主張しますが、これは事実ではないことはほとんど確実です。 「200」は、ハードドライブメーカー自体が考えた値であり、それ自体の意味があります。ハードドライブのブランド間では比較できず、同じメーカーの他のハードドライブと比較することはできません。
しかし、もう一度申し上げますが、これらの値を監視して突然増加し始めた場合、これは実際に何が起こっているのかを知らせなくても悪い兆候です。酸化物レベル。
smartctl
RAIDデバイスではなく、個々のハードドライブに関する情報を報告します。各ドライブの情報を抽出するためにさまざまな種類のハードウェアRAIDコントローラと通信する方法を知っていますが、基本デバイスを直接使用できるため、ソフトウェアRAIDの特定のサポートは必要ありません。したがって、および代わり/dev/sda
に監視する必要があります。/dev/sdb
/dev/md1
smartd
- 同伴ツールsmartctl
- このバックグラウンド連続監視を実行します。