lessコマンド でファイル書き換えてみる lessコマンドとは？ テキストファイルを1画面ずつ表示するコマンド less /var/log/messages で、messagesのログファイルを確認することができます。 大体、確認する際にlessを使うことが多いかと思います。 lessコマンドでファイルの書き換えをしてみる サンプルファイルの準備 $ echo aaaaaaa > sample.txt $ cat sample.txt aaaaaaa サンプルファイルの書き換え less sample.txt ========== aaaaaaa ========== ↑の less を開いた状態で v を押すと↓のように変換モードになる aaaaaaa test という文字列を追加 aaaaaaa test :wq で保存 aaaaaaa test less の状態で戻るので、閉じます。 確認すると変更されている $ cat sample.txt ========== aaaaaaa test ========== 対応策 重要なファイルをタイポで書き換えてしまう可能性があります。 書き換えれないように、 以下のようにcatコマンドを使用することで防ぐことができます。 cat sample.txt | less ちなみに、↑のコマンドで v を押すと、以下のように編集できない旨表示されます。
テキストファイルを1画面ずつ表示するコマンド less /var/log/messages で、messagesのログファイルを確認することができます。 大体、確認する際にlessを使うことが多いかと思います。
less /var/log/messages
less
$ echo aaaaaaa > sample.txt $ cat sample.txt aaaaaaa
less sample.txt ========== aaaaaaa ==========
↑の less を開いた状態で v を押すと↓のように変換モードになる
v
aaaaaaa
test という文字列を追加
test
aaaaaaa test
:wq で保存
:wq
less の状態で戻るので、閉じます。
確認すると変更されている
$ cat sample.txt ========== aaaaaaa test ==========
重要なファイルをタイポで書き換えてしまう可能性があります。 書き換えれないように、 以下のようにcatコマンドを使用することで防ぐことができます。
cat sample.txt | less
ちなみに、↑のコマンドで v を押すと、以下のように編集できない旨表示されます。
Virtual Data Optimizer(VDO)とは VDOとは、記憶域上に保存するデータを、よりスペース効率よく保存するための機能を提供してくれるソフトウェアです。 エンタープライズのストレージにおいてメジャーな、次の機能が実装出来ると考えてください。 シンプロビジョニング 重複排除 圧縮 ブロックデバイス上に配置されたファイルシステムに対してVDOの機能を提供するのは勿論、 LVMによって制御されているブロックデバイスやiSCSIストレージ上のLUNに対してもこの機能を提供可能です。 なお、シンプロビジョニングだけに関して言えば、他の機能で”Stratis"と呼ばれる機能でも実装が可能です。 重複排除や圧縮を使いたい場合は、VDOなのかもしれません。 SANストレージ側で同様の機能持ってる場合は、流石に併用はしないだろうなとは思いますが。 1. VDOボリュームの作成 まず、現在の構成を確認します。 # 現在の各ブロックデバイスの様子を確認 (sdbとsdcにvdoを適用します) lsblk # vdoが構成された領域の一覧表示 (現在は未構成のため何も表示されません) vdo list # vdoを対象デバイス上に構成する際のコマンド vdo create --name "vdoボリューム名" --device "対象のデバイス" --vdoLogicalSize "vdoの最大サイズ" --vdoSlabSize "スラブサイズ" --force 実行例 vdo create --name vdo1 --device /dev/sdb --vdoLogicalSize 100G --vdoSlabSize 1G --force 実行例 vdo create --name vdo2 --device /dev/sdc --vdoLogicalSize 100G --vdoSlabSize 1G --force スラブサイズにはVDO内でに存在する分割されたデータ域のサイズの事です。詳細についてはこちらをご確認ください。 VDO のスラブサイズ - Red Hat 構成が完了した場合のlsblkとvdo listの比較をしてみましょう。(本ページ内1つ目の画像と見比べて見てください) lsblkでは、sdbやsdcはそれぞれ20GBのサイズのブロックデバイスですが、その配下に100GBのvdoがそれぞれ構成されている事が分かります。(つまりシンプロビジョニング構成) またvdo listコマンドでは2つのvdo デバイスが認識されています。 2. VDOボリュームのマウント /mnt配下にvdo1とvdo2というマウントポイントを作成済みです。(mkdirにて) マウントするためにはフォーマットが必要なので、ext4でフォーマットします。その後mountコマンドでマウントします。 # ext4でvdo1をフォーマットする mkfs.ext4 /dev/mapper/vdo1 # 作成したext4でフォーマット済みのvdoデバイスを、/mnt配下のディレクトリへマウントする mount /dev/mapper/vdo1 /mnt/vdo1 以下の図は、上記のコマンドを実行した結果です。 同様の作業をvdo2に対しても行います。(上記コマンドで、vdo1の箇所をvdo2に読み替えましょう) 2つのvdoデバイスのマウントを終えましたので、lsblkとdfでマウント状況と容量を確認してみました。 lsblk側では、vdo1とvdo2の容量が100GBずつ且つそれぞれが/mnt配下のディレクトリにマウントされていることが確認出来ました。 df -hでは、100GBのうちvdoデバイスとしての構成情報を保存するために2GB程度のオーバーヘッドが消費されていることが確認出来ました。 最後は、/etc/fstabへの永続マウント設定を忘れないようにしましょう。以下設定後再起動を実施。 おや・・・正しく設定をしたはずですがEmergency Modeで上がってきました。 そこでオンラインマニュアル内を確認すると次の記述が確認出来ました。どうやらfstab内の記述が少々他と違うようです。 結構下の方までスクロールしました。 man vdo なので、man上の記述例をコピーして、後々/etc/fstab内にペーストしました。これで間違いなく正しく入力出来るでしょう。 実際に記述をしたファイルがこちらです。 この後再起動しましたが、問題なくCentOSが起動してきました。 ちなみに以下のページでも上記のfstab記述については言及がありました。 VDO ボリュームのマウント - Red Hat 3. VDOの圧縮率を見てみる 実際手元で重複排除と圧縮の効果を確認しようかと思ったのですが、いい題材が思いつかなかったのでYoutubeより抜粋 画面の左側はVDO未使用、画面の右側はVDOを使用している環境です。 どちらも25GBのボリュームに対して、Linuxカーネルの歴代のソースコードをWriteし続けている作業です。 右下にはvdostatsの行として、25GBの領域に対して、4.2GBだけを使ってこのソースコード全てを圧縮して保存している記述が見受けられます。VDOボリュームとしては250GBとして構成し、29GBのデータを入れているのですが、VDOによる容量節約機能で僅か4GBしか消費していないわけです。つまり29GB-4.2GBで、大凡25GB程度得をしているわけですね。 RHEL 8 Beta - Using the Virtual Data Optimizer (VDO) 関連リンク A look at VDO, the new Linux compression layer - Red Hat Red Hat Enterprise Linux 8 Deduplicating and compressing storage - Red Hat RHEL 8 Beta - Using the Virtual Data Optimizer (VDO) ストレージの重複排除および圧縮 - RHEL8でVDOを使用してストレージの容量を最適化
VDOとは、記憶域上に保存するデータを、よりスペース効率よく保存するための機能を提供してくれるソフトウェアです。 エンタープライズのストレージにおいてメジャーな、次の機能が実装出来ると考えてください。
ブロックデバイス上に配置されたファイルシステムに対してVDOの機能を提供するのは勿論、 LVMによって制御されているブロックデバイスやiSCSIストレージ上のLUNに対してもこの機能を提供可能です。 なお、シンプロビジョニングだけに関して言えば、他の機能で”Stratis"と呼ばれる機能でも実装が可能です。 重複排除や圧縮を使いたい場合は、VDOなのかもしれません。
SANストレージ側で同様の機能持ってる場合は、流石に併用はしないだろうなとは思いますが。
まず、現在の構成を確認します。
# 現在の各ブロックデバイスの様子を確認 (sdbとsdcにvdoを適用します) lsblk # vdoが構成された領域の一覧表示 (現在は未構成のため何も表示されません) vdo list
# vdoを対象デバイス上に構成する際のコマンド vdo create --name "vdoボリューム名" --device "対象のデバイス" --vdoLogicalSize "vdoの最大サイズ" --vdoSlabSize "スラブサイズ" --force 実行例 vdo create --name vdo1 --device /dev/sdb --vdoLogicalSize 100G --vdoSlabSize 1G --force 実行例 vdo create --name vdo2 --device /dev/sdc --vdoLogicalSize 100G --vdoSlabSize 1G --force
スラブサイズにはVDO内でに存在する分割されたデータ域のサイズの事です。詳細についてはこちらをご確認ください。 VDO のスラブサイズ - Red Hat
構成が完了した場合のlsblkとvdo listの比較をしてみましょう。(本ページ内1つ目の画像と見比べて見てください) lsblkでは、sdbやsdcはそれぞれ20GBのサイズのブロックデバイスですが、その配下に100GBのvdoがそれぞれ構成されている事が分かります。(つまりシンプロビジョニング構成)
またvdo listコマンドでは2つのvdo デバイスが認識されています。
/mnt配下にvdo1とvdo2というマウントポイントを作成済みです。(mkdirにて) マウントするためにはフォーマットが必要なので、ext4でフォーマットします。その後mountコマンドでマウントします。
# ext4でvdo1をフォーマットする mkfs.ext4 /dev/mapper/vdo1 # 作成したext4でフォーマット済みのvdoデバイスを、/mnt配下のディレクトリへマウントする mount /dev/mapper/vdo1 /mnt/vdo1
以下の図は、上記のコマンドを実行した結果です。 同様の作業をvdo2に対しても行います。(上記コマンドで、vdo1の箇所をvdo2に読み替えましょう) 2つのvdoデバイスのマウントを終えましたので、lsblkとdfでマウント状況と容量を確認してみました。 lsblk側では、vdo1とvdo2の容量が100GBずつ且つそれぞれが/mnt配下のディレクトリにマウントされていることが確認出来ました。 df -hでは、100GBのうちvdoデバイスとしての構成情報を保存するために2GB程度のオーバーヘッドが消費されていることが確認出来ました。
最後は、/etc/fstabへの永続マウント設定を忘れないようにしましょう。以下設定後再起動を実施。
おや・・・正しく設定をしたはずですがEmergency Modeで上がってきました。 そこでオンラインマニュアル内を確認すると次の記述が確認出来ました。どうやらfstab内の記述が少々他と違うようです。 結構下の方までスクロールしました。
man vdo
なので、man上の記述例をコピーして、後々/etc/fstab内にペーストしました。これで間違いなく正しく入力出来るでしょう。 実際に記述をしたファイルがこちらです。 この後再起動しましたが、問題なくCentOSが起動してきました。 ちなみに以下のページでも上記のfstab記述については言及がありました。 VDO ボリュームのマウント - Red Hat
実際手元で重複排除と圧縮の効果を確認しようかと思ったのですが、いい題材が思いつかなかったのでYoutubeより抜粋 画面の左側はVDO未使用、画面の右側はVDOを使用している環境です。
どちらも25GBのボリュームに対して、Linuxカーネルの歴代のソースコードをWriteし続けている作業です。 右下にはvdostatsの行として、25GBの領域に対して、4.2GBだけを使ってこのソースコード全てを圧縮して保存している記述が見受けられます。VDOボリュームとしては250GBとして構成し、29GBのデータを入れているのですが、VDOによる容量節約機能で僅か4GBしか消費していないわけです。つまり29GB-4.2GBで、大凡25GB程度得をしているわけですね。
RHEL 8 Beta - Using the Virtual Data Optimizer (VDO)
A look at VDO, the new Linux compression layer - Red Hat Red Hat Enterprise Linux 8 Deduplicating and compressing storage - Red Hat RHEL 8 Beta - Using the Virtual Data Optimizer (VDO) ストレージの重複排除および圧縮 - RHEL8でVDOを使用してストレージの容量を最適化
長く使ってきた Manjaro Lxqt バージョン 更新でトラブり使用を断念しました。 Lxqtバージョンは正規のデフォルトバージョンではないようで Manjaro20へのバージョンアップが遅れているようです？ 詳しいことはわかりません。 新たにManjaro Xfce バージョンを導入しました。 軽量なまま、デフォルトバージョンですから 更新のトラブルも少ないはずです。 お約束の「.xprofile」の書き足しが必要？ 日本語入力を設定するのに 「入力メソッド」の設定を探す必要もありません。 テキストエディット（何でもいいです）で 「export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export XMODIFIERS=@im=fcitx」 と書かれたファイルを1個作り Manjaroのhomeなどに貼り付けてやるだけです。 直接は貼り付けないかもしれませんから 作ったファイルを一旦デスクトップなどに保存し そこからhomeなどに貼り付けてください。 日本語入力ができるようになります。 軽量で使いやすい ManjaroLinux おすすめです！
長く使ってきた Manjaro Lxqt バージョン 更新でトラブり使用を断念しました。 Lxqtバージョンは正規のデフォルトバージョンではないようで Manjaro20へのバージョンアップが遅れているようです？ 詳しいことはわかりません。
新たにManjaro Xfce バージョンを導入しました。 軽量なまま、デフォルトバージョンですから 更新のトラブルも少ないはずです。
お約束の「.xprofile」の書き足しが必要？ 日本語入力を設定するのに 「入力メソッド」の設定を探す必要もありません。 テキストエディット（何でもいいです）で 「export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export XMODIFIERS=@im=fcitx」 と書かれたファイルを1個作り Manjaroのhomeなどに貼り付けてやるだけです。
はじめに OpenWRT/LEDEにrtorrent環境を構築する際のTipsです。 RaspberryPiやOrangePi等のイメージファイルをダウンロードする場合等、 サーバーによっては数時間掛かる場合も有る為、 常時起動のNASでtorrentが動作すると非常に便利です。 未だ色々と課題が残っていますが、 それなりに運用出来ていますので、 足跡を残しておきます。 尚、以下の環境を前提に記載しています。 中華ファンレスNASをOpenWRT(LEDE)で使う 参考: 1. https://github.com/wolandmaster/luci-app-rtorrent 2. LEDE/OpenWRT — Setting Up Torrent Downloading 環境構築方法 参考1.の luci-app-rtorrent githubページの README.md に従いinstallします。 /root/.rtorrent.rc の内容のみ、参考2.のページの情報を参考にしました。 owner課題 上記環境構築でそれとなく動く様になりましたが、 ダウンロードしたファイルのパーミッションがrootとなってしまう為、 使い勝手が微妙ですので、修正します。 ~/.rtorrent.rc system.umask.set = 0000 残課題1 何かしらの起動順序の依存関係の問題か、 reboot直後は、luci-appのTorrent List (cgi-bin/luci/admin/rtorrent/main) が動作しません。 今は、取り敢えずreboot後はrtorrentを再起動させる事で課題は解消しますが、根本的に解決させたいとは思っています。 /etc/init.d/rtorrent stop /etc/init.d/rtorrent start ちなみに、 上記コマンドを/etc/rc.localに記載してみましたが、それでもダメでした。 何かしら、起動が遅いものが存在しているのか・・・ 残課題2 何の拍子か、時々 luci-app の Torrent List が無反応になる場合が有ります。 screenからreattachしてみると、rtorrentとしては動いている為、 luci-app からの呼び出しの何かでこけている様です。 取り敢えずの回避策として、 下記スクリプトを準備して、実行する様にしました。 #!/bin/bash -x /etc/init.d/rtorrent stop rm -rf /root/.rtorrent.session/* /etc/init.d/rtorrent start 解決に向けて 何かヒントになりそうな、似た様な現象に遭遇した事の有る為、 コメント頂けると幸いです。
OpenWRT/LEDEにrtorrent環境を構築する際のTipsです。 RaspberryPiやOrangePi等のイメージファイルをダウンロードする場合等、 サーバーによっては数時間掛かる場合も有る為、 常時起動のNASでtorrentが動作すると非常に便利です。
未だ色々と課題が残っていますが、 それなりに運用出来ていますので、 足跡を残しておきます。
尚、以下の環境を前提に記載しています。 中華ファンレスNASをOpenWRT(LEDE)で使う
参考: 1. https://github.com/wolandmaster/luci-app-rtorrent 2. LEDE/OpenWRT — Setting Up Torrent Downloading
参考1.の luci-app-rtorrent githubページの README.md に従いinstallします。 /root/.rtorrent.rc の内容のみ、参考2.のページの情報を参考にしました。
上記環境構築でそれとなく動く様になりましたが、 ダウンロードしたファイルのパーミッションがrootとなってしまう為、 使い勝手が微妙ですので、修正します。
system.umask.set = 0000
何かしらの起動順序の依存関係の問題か、 reboot直後は、luci-appのTorrent List (cgi-bin/luci/admin/rtorrent/main) が動作しません。
今は、取り敢えずreboot後はrtorrentを再起動させる事で課題は解消しますが、根本的に解決させたいとは思っています。
/etc/init.d/rtorrent stop /etc/init.d/rtorrent start
ちなみに、 上記コマンドを/etc/rc.localに記載してみましたが、それでもダメでした。 何かしら、起動が遅いものが存在しているのか・・・
何の拍子か、時々 luci-app の Torrent List が無反応になる場合が有ります。 screenからreattachしてみると、rtorrentとしては動いている為、 luci-app からの呼び出しの何かでこけている様です。
取り敢えずの回避策として、 下記スクリプトを準備して、実行する様にしました。
#!/bin/bash -x /etc/init.d/rtorrent stop rm -rf /root/.rtorrent.session/* /etc/init.d/rtorrent start
何かヒントになりそうな、似た様な現象に遭遇した事の有る為、 コメント頂けると幸いです。
