OS

A collection of 11 posts
OS

SSD換装はOSの入れ直し不要――無料ツール「Clonezilla」でシステムごと丸ごと引っ越す手順と、失敗しない事前チェックリスト

はじめに――なぜOSの入れ直しは不要なのか ノートPCを長く使っていると、多くの人がぶつかるのがストレージ容量の壁です。写真や動画、ゲーム、開発環境……。外付けSSD/HDDやmicroSDカード、クラウドへのデータ退避でしのいでいても、忙しい時に「空き容量不足」で作業が中断されるストレスはなかなか拭えません。PC Watchの特集では、メイン機のThinkPad X1 Nano（256GB SSD）を使うライターが「もう少し余裕がほしい」と感じる場面が増え、1TBへの換装を決意した経緯が紹介されています。 ここで多くの人が悩むのが「SSDを交換したら、OSやアプリを全部入れ直すのか?」という問題です。ディスククローンという手法を使えば、OS・アプリ・設定・データを新しいSSDへ丸ごと引っ越せます。クローンが正常に完了し、ファームウェア設定や暗号化の状態といった条件が揃えば、OSの再インストールは基本的に不要です。 本記事では、無料・オープンソースの定番ツール「Clonezilla」を使ったSSD換装の全体像を、事前チェックリスト→ステップバイステップの手順→よくある質問まで、一
8 min read
OS

eBPF入門――Linuxカーネルを安全に拡張する技術がクラウドの監視・セキュリティ・オブザーバビリティをどう変えるのか

はじめに Kubernetes上でマイクロサービスを運用していると、PodのIPアドレスが頻繁に入れ替わる環境では、iptablesベースのネットワーク制御のルール数が増大して更新コストが問題になったり、プロセス単位で動くエージェント型の監視の網羅性に限界が生じたりするケースがあります。「どのコンテナがどのファイルを開いたのか」「どのサービス間でレイテンシが発生しているのか」を、なるべく低いオーバーヘッドで知りたい——そんな課題に対して、いまクラウドインフラの根幹で使われているのが eBPF（extended Berkeley Packet Filter） です。 eBPFとは一言でいえば、Linuxカーネル内で安全にサンドボックス化されたプログラムを実行できる技術です。カーネルのソースコードを変更したりカーネルモジュールをロードしたりすることなく、カーネルそのものを「プログラマブル」にできます（ebpf.io公式）。よく使われる比喩は、「eBPFはLinuxカーネルに対して、JavaScriptがブラウザにもたらしたのと同じ変化をもたらす」 というもの。静的な存在だったカーネルが
8 min read
OS

ZFS入門——Copy-on-Write・スナップショット・RAID-Zがホームサーバーのストレージをどう変えるのか

はじめに——RAID5 + ext4 からの問い 自宅にNASや仮想化基盤を構築してきた技術者の多くは、「mdadmやハードウェアRAIDでRAID5を組み、その上にext4やXFSを置く」という構成に馴染みがあるでしょう。磁気ディスクが1台壊れてもパリティで復旧できる——この安心感が、長年ホームサーバーの定番構成でした。 しかし、この構成には死角があります。RAID5が守れるのは「ディスクの物理的な故障」だけだという点です。もっと静かな敵、サイレントコラプション（ビットロット）はどうでしょうか。磁気ディスクは経年で、エラーや警告なしにビットが書き換わることがあります。従来のRAIDコントローラやext4は「書き込みが成功した＝データが正しい」と仮定してしまうため、破損したデータを正しいデータとして読み返し、最悪の場合、その破損をパリティ経由で他のディスクにまで複製してしまうのです。バックアップから戻そうにも、壊れた時点のファイルが「正常」として保存されていた、という事態も起こり得ます。 この問いに対する1つの答えがZFSです。Sun Microsystemsで2001年に開発が
12 min read
OS

eBPF入門——カーネルを書き換えずにLinuxの仕組みを変える技術はどう動くのか

はじめに——カーネルを変えるにはなぜ難しいのか？ 「Linuxの仕組みそのものを変えたい」と思ったら、どうすればいいでしょうか。たとえば、特定のシステムコールを監視したい、カーネルのネットワーク処理に独自の処理を組み込みたい——そんなとき、カーネル内部に新しい処理を追加する代表的な方法は事実上2つでした（ebpf.io）。 1つ目はカーネルソースの変更です。カーネルはシステム全体を制御する特権的な存在であるがゆえに安定性・セキュリティ要件が厳しく、変更はコミュニティの合意を経てメインラインにマージされ、各ディストリビューションへ普及するまで長い時間がかかります。 2つ目はカーネルモジュールの自作です。こちらは即座に反映できますが、セキュリティ境界のない状態でカーネル空間にコードをロードするため、バグひとつでカーネルごとクラッシュする危険を伴い、カーネル更新のたびに破損リスクと隣り合わせになります（ebpf.io）。 「待つか、危険を冒すか」。カーネル内部に新しい処理を加える方法としては、この2択に_flock_してきました。そして、第3の選択肢として登場したのが eBPF（ex
13 min read
OS

eBPF入門——カーネルを再起動なしで拡張する仕組みと、今日から始めるオブザーバビリティ実践ガイド

はじめに 結論から言うと、eBPFとはLinuxカーネルを再起動せずに、しかも安全に拡張できる技術です。カーネルのソースコードを改変することも、壊れやすいカーネルモジュールをロードすることもなく、独自のプログラムをカーネル空間で動かせます。かつてパケットフィルタとして生まれたBPF（Berkeley Packet Filter）が進化した「extended BPF」は、今やオブザーバビリティ、セキュリティ、ネットワーキングを支えるLinuxの基盤技術へと成長しています。 なぜ今、eBPFなのか eBPFはすでに「研究段階の新技術」ではありません。広く採用が進んでいます。 * クラウドベンダーでの採用: AWSのEKS標準CNIやGuardDutyのランタイム監視、Azureの「Azure CNI Powered by Cilium」、GKEなど、3大クラウドのオブザーバビリティ・ネットワーキング基盤に組み込まれています。 * 商用オブザーバビリティ製品での標準利用: New Relicをはじめ、DatadogやGrafanaといった主要プラットフォームがeBPFベースの機
26 min read
OS

Windows 11のメモリ整合性、10月から既定オンに——カーネル保護と性能の代償

Microsoftは2026年10月から、対象となるWindows 11デバイスでメモリ整合性（HVCI）を既定で有効にします。カーネルを狙うBYOVD攻撃を封じる一方、ゲーム性能の低下や古いドライバーとの非互換という副作用も抱える変更です。対象条件、確認方法、トラブル時の切り分けまで整理します。
7 min read
Linux Featured

NASを再起動したらLXCが起動しなくなった——NFSv3のstale file handleと「見かけ上の正常性」という罠

NASを再起動しただけでコンテナが起動不能になった。エラーコードは116。findmntにはマウントが表示され、pvesm statusもactiveを返す。それでもlsは「Stale file handle」を返す。NFSv3のステートレス性が生む見かけ上の正常性と、その復旧手順、さらに復旧作業が引き起こした二次障害までを記録する。
7 min read
OS

中国、政府版Windowsを前倒し撤去——国産Linux移行が問う「デジタル主権」

Bloombergの報道によれば、中国国家安全部が一部の政府関連組織に「Windows 10 China Government Edition」の撤去を指示し、廃止時期を2027年2月から2026年後半へ前倒しした。移行先は麒麟や統信UOSといった国産Linux。フランスも250万台の政府PCをLinuxへ移すと宣言しており、OS選択は「性能」ではなく「主権」の問題へ変わりつつある。
10 min read
OS

eBPFが変えるLinuxカーネルの常識——雲の上のコンテナ基盤を支える「プログラマブルカーネル」入門

はじめに——「カーネルを変えずにカーネルを変える」とは？ eBPFという発想 Linuxカーネルに手を入れたい——。システムを深く観測したい、パケット処理を高速化したい、不審なプロセスを即座に止めたい。そんな要求は、クラウドネイティブ基盤を運用するSREやプラットフォームエンジニアなら日常的に直面します。ところが伝統的な解決策はどれも痛みを伴うものでした。カーネルにパッチを当てて再コンパイルする？ メンテナの承認を待つのに数年かかることもあります。カーネルモジュールをロードする？ 完全なカーネル権限で動くため、バグひとつでカーネルパニック＝ホスト全体のダウンにつながります。 このジレンマに答えたのがeBPF（extended Berkeley Packet Filter）です。カーネルを再コンパイルせず、危険なカーネルモジュールも使わずに、Verifierで検証された小さなプログラムをカーネル内で実行する——「カーネルを変えずにカーネルを変える」という発想です（Zenn、ebpf.io）。起源は1992年の古典的BPF（cBPF）ですが、2014年にAlexei Starovoit
7 min read
OS

eBPFが変えるクラウドネイティブインフラ——Cilium・Tetragon・Hubbleで開くゼロトラスト・オブザーバビリティの新世代

はじめに 「Kubernetesクラスターの規模が大きくなるにつれて、iptablesルールの更新に数秒かかるようになった」——これは、クラウドネイティブインフラを運用する多くのエンジニアが直面する現実です。 マイクロサービスアーキテクチャが普及し、Kubernetesクラスター上で動くサービス数が200、500、ときには1,000を超える規模になると、従来のネットワーキング基盤が限界を迎えます。kube-proxyが依存するiptablesは、サービス数の増加に対して線形（O(n)）にパフォーマンスが劣化します。200サービスを超えたあたりで、ルールの更新に数秒かかるようになり、新しいPodの起動からトラフィックが流れるまでのレイテンシが無視できなくなります。 さらに、サービスメッシュの導入による負担も深刻です。Istioなどのサイドカーモデルを採用した場合、各PodにEnvoyプロキシが注入され、Podあたり50〜150MBのメモリを消費します。1,000 Pod規模のクラスターでは、プロキシだけで数百GB〜1TB以上のメモリリソースが圧迫されます。CPUオーバーヘッドも無視
30 min read