色々な理由でシステム監視用ツール（CloudWatchやnetdata、Prometheusなど）が使えないので、vmstatのデータを動かしっぱなしにして収集してみたくなった。 awkにパイプラインで渡す部分はvmstatじゃなくてもいい。jstatでもいい。 init.dやsystemdで管理したければ、このスクリプトを使ったりすればだいたいOK。保存ディレクトリは工夫したほうがいいかも。 細かい分析したいのであればもっと別の手段使ったほうがよさそうな気がする。 他のもっといい方法あればコメントお願いします。 スクリプト logging-start.sh #!/bin/bash cd `dirname $0` vmstat 1 -n -S m -w | awk '{ print strftime("%Y/%m/%d %H:%M:%S"), $0 } { system(":") }' >> vmstat.log & pid=$! echo $pid touch $pid.pid logging-stop.sh #!/bin/bash cd `dirname $0` pidFile=`ls *.pid` pid=${pidFile%.*} echo $pid stop server. kill -9 $pid rm -rf $pidFile こんなログになる。 ❯ vmstat 1 -n -S m -w | awk '{ print strftime("%Y/%m/%d %H:%M:%S"), $0 } { system(":") }' 2021/10/10 19:22:20 procs -----------------------memory---------------------- ---swap-- -----io---- -system-- --------cpu-------- 2021/10/10 19:22:20 r b swpd free buff cache si so bi bo in cs us sy id wa st 2021/10/10 19:22:20 1 0 0 19913 14 94 0 0 187 2199 34 100 0 0 99 0 0 2021/10/10 19:22:21 0 0 0 19913 14 94 0 0 0 18432 40 186 0 0 100 0 0 2021/10/10 19:22:22 0 0 0 19913 15 94 0 0 0 18448 32 163 0 0 100 0 0 2021/10/10 19:22:23 0 0 0 19913 15 94 0 0 0 20504 34 173 0 0 100 0 0 2021/10/10 19:22:24 0 0 0 19913 15 94 0 0 0 18432 29 139 0 0 100 0 0 2021/10/10 19:22:25 0 0 0 19913 15 94 0 0 0 18432 28 146 0 0 100 0 0 2021/10/10 19:22:26 0 0 0 19913 15 94 0 0 0 18432 27 143 0 0 100 0 0 参考 よく知らないアプリケーションの性能と戦わないといけないときの防衛術（前編） - Qiita よく知らないアプリケーションの性能と戦わないといけないときの防衛術（後編） - Qiita awkを使ってvmstatに日時をつける - Qiita vmstatをdaemon化して継続的なログを記録する - Qiita

要約 LinuxでexFATフォーマットする時に/dev/sdbのようにパーティションでなくドライブを指定してフォーマットできるが、/dev/sdb1のようにパーティションを切ってからフォーマットするべき。 もし、ドライブ指定でフォーマット後に使用してしまったら、Windowsには決してつないではならない。つないだだけで読み出し不能になる。 環境 Ubuntu 20.04 LTS Windows 10 Pro 21H1 Ubuntu 18.04にはexfat-fuse, exfat-utils導入済み。20.04には導入なし。 動機 新しく買ったHDDをexFATフォーマットしようと調べていたら、Linux側でフォーマットするとWindows側から読めなくなるという記事をみかけたので、どうやってフォーマットするか少し迷った。 検証 Ubuntu上でドライブは/dev/sdbだったものとする。先にgparted上でパーティションテーブルをGPTにした。 ドライブごとフォーマット いきなりsudo mkfs.exfat /dev/sdbでフォーマットしてgparted上で確認したが、フラグの設定などのメニューが選択できなかった。(Ubuntu 20.04ではexfat-fuse, exfat-utilsなしでもexFATを読むことは出来るが、インストールしないとmkfs.exfatがないと言われてフォーマットはできない。) Gpartedで「表示 -> デバイス情報」で確認すると、パーティションテーブルが「なし」になっていた。 Gparted上で警告が表示され、「情報」を見ると「このファイルシステムの内容を読み込むことができません!これによりいくつかの操作が利用できません」と表示された。もっとも、後からつないだ他のドライブにも表示されたりされなかったりしたので、接続の順序などによる一時的なものだと思われる。 データ破損 検証のためこれをWindowsに接続すると、Windowsの「ディスク管理」からは、MBRのドライブとして扱われ、2048Gbと残りの領域に分けられ、両者とも未割り当て領域として認識された。 これをLinux側に戻して接続しようとしたのだが、エラーが出てマウントされなくなってしまった。 パーティションを切ってからフォーマット gpartedでドライブを丸ごと1つの新規パーティションにすると、位置合わせをMiBにしたせいか、後方に1MiBの未割り当て領域が出来た。余談だが位置合わせをシリンダした場合は出来なかった。 出来上がったパーティション/dev/sdb1をsudo mkfs.exfat /dev/sdb1でフォーマットすると、gparted上でフラグの設定が可能であった。 msftdataフラグを設定しないとWindows側からは認識されれず、「ディスク管理」でもドライブのプロパティは表示できるが、パーティションについては認識こそされるもののボリューム削除以外の操作はできず、ドライブ名の割り当ても不可であった。 msftdataフラグを立てて再度Windowsに接続すると、exFATとして認識され、ドライブ名も割り当てられた。 参考: Windows上でフォーマット Windows 10上でフォーマットした(と記憶している)SDカードをgpartedで確認すると、パーティションを切ってある上、前方に32MiBの未割り当て領域があった。 HDDをフォーマットすると、/dev/sdb1はmsftresフラグありで 15.98MiBのMicrosoft reserved partitionとして隠しパーティションが作成されていた。 /dev/sdb2はmsftdataフラグあり、後方は2MiBの空き領域ができていた。 復旧作業 GParted GPartedに「デバイス -> データの救出を試みる」というのがあるが、gpartを利用しており、gpartを調べてみると対応するフォーマット形式がかなり限定されていた。試しに少し動かしてみたが、数時間しても終わる気配がないので中断した。 ファイナルデータ 前回の記事で試用版にお世話になった。まさかこんなことで購入することになるとは。 一応、ほぼ全てのファイルが復旧できたのだが、どうも2-3個行方不明になったファイルが出てしまった模様。もしかしたらコピーし忘れていて、始めから存在しなかった可能性もあるにはあるが、割と直近に触ったファイルだし、フォルダのデータをコピーする前のフォルダデータが優先されてしまったのかもしれない。 復旧に要した時間は1TBあたり3時間くらいだったろうか。買ったHDDが復旧データで一杯になってしまった。 試さなかったこと exFATの仕様書で、ドライブ内に1つだけでもパーティションを切ってからフォーマットするのが正式なのか調べたほうがよいのかもしれないが、仕様書の場所もわからないし、わかっても膨大な仕様書のどこに書かれているか探せそうな気がしないので調べていない。 考察 技術的な推測 パーティションでなくディスク単位でフォーマットすると、ディスク先頭のパーティションテーブルの記録領域にフォーマット情報が書き込まれてパーティションテーブルが破壊されるのだと思われる。 そして、Windowsに接続すると「パーティションテーブルがない」ので「自動で」パーティションテーブルの記録領域にMBRが作成され、そこに書かれていたフォーマット情報が破壊され、フォーマットすらされていない状態になるのだろう。 他のフォーマット形式は試していないが、原理的にはexFatフォーマットに限らないので、一般的にパーティションを切らずにディスク自体をフォーマットするのは避けるべきといえる。 個人的な意見と感想 仕様上正しいのかもしれないが、/dev/sdbのようにドライブを指定したフォーマットは認めないか、開始前に十分な警告が表示されるべきだと思う。 ドライブ指定したフォーマットでもLinux側では普通に扱えてしまうことも、かえって問題発生を助長しているかも知れない。 Windowsにつなぐ予定がない自分が言うのもどうかとは思うが、exFATフォーマットの主な使い道といえばWindows, Mac, Linuxの間でデータをやりとりするメディア用なので、必然的に物理媒体1つを丸ごとexFATにする展開となり、このような状況に直面することは多いのではと思われる。 exfat-utilsのバージョンが1.0.1くらいだった頃からSDカードをLinux上でexFATにするのと、Winodws上でするのとでは、/dev/以下に表示される構造に違いがあるのが気になっていた。 フォーマット対象にパーティションでなくドライブ自体を指定できてしまう仕様や、検索で出てくるのがパーティションを切らずにドライブ自体を指定してフォーマットする記述になっていることに問題があるのか、exFATの仕様の不備なのかははっきりしない。 改訂履歴(表現の修正などは除く) 2021/8/27: 作成開始。 2021/9/2: 検証を記載。 2021/9/19: データ破損に関して全面改訂。 2021/10/10: さらに手直しして公開。

やりたいこと 次の2つのファイル(文字列)がある source hogehoge hugahuga hogahoga hugehuge target AAAAAA BBBBBB CCCCCC FLAG DDDDDD EEEEEE このときにtargetのFLAGの部分をsourceの内容で置き換えたい。 つまり、 result AAAAAA BBBBBB CCCCCC hogehoge hugahuga hogahoga hugehuge DDDDDD EEEEEE こんな感じ。 これが少し面倒で、詰まったので書き残す。 結論 これでOK str=`cat source | # 挿入する文字列を読み込み sed -r 's/$/\\\\n/' | # 各行の末端に改行文字を入れる sed -r '$s/\\\\n//' | # 最終行の改行文字に関しては必要ないので取り除く while IFS= read -r line # 1行ずつ読み込み do echo -n "$line" # echo -nで各行を改行しないで出力->1行にまとめる done` cat target | sed -r "/^FLAG$/s/.+/$str/" # sedで必要な部分に挿入(置換) 解説1/3 まずは次のやり方が思いつくと思う。 str=`cat source` cat target | sed -r "/^FLAG$/s/.+/$str/" しかしこれでは上手くいかない。 というのも、どうもsedは置換後の文字列($str)が複数行だと上手く置換してくれずにエラーを吐いてしまう sed: -e expression #1, char 28: unterminated `s' command つまり$strが複数行で無ければいい。 解説2/3 sourceの内容は複数行なのに$strは複数行ではいけない。 矛盾しているようだが、次のsedの仕様を使えばいける。 $ cat target | sed -r '/^FLAG$/s/.+/hogehoge hugahuga\nhogahoga hugehuge/' AAAAAA BBBBBB CCCCCC hogehoge hugahuga hogahoga hugehuge DDDDDD EEEEEE つまり改行文字\nは有効なのである。 従って、sourceの内容を1行に変換しつつ、元の改行位置に\nを入れた$strを用意すればOK 解説3/3 複数行を1行にまとめる方法に関しては、固定行数であればいくつかあるが任意の行数となるとなかなか難しい。今回は次の方法を採った。 $ cat source | while IFS= read -r line ; do echo -n "$line" ; done hogehoge hugahugahogahoga hugehuge つまりwhile readで行ごとに読み込み、echo -nで各行を改行なしで出力している。 IFS=と-rに関しては、デフォルトだと先頭・末端のスペースやバックスラッシュを取り除くwhile readの仕様対策。 あとは、1行にまとめる前に各行の末端に改行文字\nを入れておけばOK(エスケープする必要はあるが)