Linux ファイルシステムを理解したい - Qiita
]# cat /etc/redhat-release CentOS Linux release 7.7.1908 (Core) ]# uname -a Linux localhost.localdomain 3.10.0-1062.1.2.el7.x86_64 #1 SMP Mon Sep 30 14:19:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux ファイルシステムとは何か? データを管理/操作するための仕組み。 ファイルとディレクトリで構成されていて、/ を基点とした木構造になっている。 # ls -l / 合計 56 lrwxrwxrwx. 1 root root 7 8月 25 01:17 bin -> usr/bin dr-xr-xr-x. 6 root root 4096 9月 29 15:51 boot drwxr-xr-x. 19
inotify-toolsでファイルやディレクトリを監視する - Qiita
Linux2.6から追加されたinotifyというAPIは、ファイルやディレクトリーでオープン、クローズ、移動/名前変更、削除、作成、属性の変更などといったファイルシステムイベントを監視することができます。 inotify API群を利用して自分でファイルシステムイベント監視プログラムを実装することができますが、 今回は、inotify-toolsというinotifyを利用したファイルシステムイベント監視ツールを使用します。 inotifyイベント inotifyでは対象のファイルまたはディレクトリに対して以下のファイルシステムイベントが監視できます。 ※対象がディレクトリの場合は、ディレクトリ自身とその配下のファイルが対象となります。 イベント名 イベント発生タイミング
Yoctoの概要 - Qiita
初めに YoctoはReferenceが読みにくく、Referenceを参照して学習することが困難(だと筆者は思う)なツールです 一回勉強したことを忘れないよう、覚えたことをここにまとめます 目標 「Yoctoを触ったことがない人」、「Yoctoを触ってるけど全体像がよくわからない人」が 「大雑把なイメージをつかむこと」「細かいことは自分でググって解決できるようになること」を目標とします 参考 YoctoのQuickStart YoctoのReference bitbakeのReference https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html (「bitbake reference」でググると古い資料がトップに来るので注意!) Yoctoとは Linuxをビルドするプロ
Linux：キャッシュを開放する（/proc/sys/vm/drop_caches） - あたまんなか
同じ構成＋同じアプリケーションのサーバーなのに片方のサーバーのメモリ使用率が100%近くに張り付いてしまっていたので調査したメモです 正常なサーバー $ free -m total used free shared buffers cached Mem: 3763 3547 215 0 33 1585 -/+ buffers/cache: 1928 1835 Swap: 4095 141 3954 Alerm発生サーバー $ free -m total used free shared buffers cached Mem: 3763 3743 19 0 1178 1240 -/+ buffers/cache: 1325 2438 Swap: 2047 45 2002 meminfoを見てみる cat /proc/meminfoで正常鯖とAlerm鯖を見比べてみます slabtopも見る
普通の Linux 環境で手軽にバイナリファイルを編集する (dd, vim) - Qiita
テスト用ファイル ちょうど手元にあった PPPoE の pcap ファイルから CHAP の部分を抜粋したもの PPPoE のユーザ名 (hogehoge@one.ocn.ne.jp) をマスクする目的で書き換えてみる。 hogehoge の部分を xxxxxxxx のようにどうでもいい文字列で埋める。 編集したいファイルが大きい場合、Vim を使う方法ではメモリ消費が激しいので避ける。 dd でバイナリ編集 編集する場所を確認するため、一度 hexdump で中身を調べる $ hexdump -C pppoe.cap 00000000 0a 0d 0d 0a 34 00 00 00 4d 3c 2b 1a 01 00 00 00 |....4...M<+.....| 00000010 ff ff ff ff ff ff ff ff 04 00 0e 00 45 64 69 74 |...
RAID setup - Linux Raid Wiki
General setup This is what you need for any of the RAID levels: A kernel with the appropriate md support either as modules or built-in. Preferably a kernel from the 4.x series. Although most of this should work fine with later 3.x kernels, too. The mdadm tool Patience, Pizza, and your favorite caffeinated beverage. The first two items are included as standard in most GNU/Linux distributions today.
mdadmでソフトRAIDにホットスペアディスクを追加してみる(RAID 5編): ぴろにっき
さて。先ほど作成したり再構築したりしたRAIDアレイに、ホットスペアディスクを追加してみる。 「ホットスペアディスクってなんなのさ？」という人に簡単な解説をしておこう。先ほどまでに作成していたRAID 5のアレイ（ボリューム）は、4本のディスクを使って単独のディスク障害に耐えられるように構成していた。しかし、RAID 5にもアキレス腱となる部分があり、それはディスクが1本故障した状態で運用を継続している状況は、もはや新たなディスク障害には耐えられないということであった。 まあ、新たに2本目のディスクが故障してしまう前に、ディスクを交換して通常の運用状態に戻せば、また別のディスクが故障しても耐えることができる状態にすることはできる。 が、しかし。その2本目のディスク故障がいつ起きるのか。それは誰にも判らないものである。今週末にでも秋葉原に行って、新しいハードディスクを買ってくればいいお＾－＾
Chapter 5. Device Quirks
Completing the platform data specific to your device, you may also need to write some code in the glue layer to work around some device specific limitations. These quirks may be due to some hardware bugs, or simply be the result of an incomplete implementation of the USB On-the-Go specification. The JZ4740 UDC exhibits such quirks, some of which we will discuss here for the sake of insight even th
マジックSysRqキー - Wikipedia
マジックSysRqキーは、Linuxカーネルでシステム状態に関する低レベルコマンドを発行するキーシーケンスである。 SysRqとその他のキーとを組み合わせて使用する。これはカーネル開発におけるデバッグ用であると同時に、しばしばシステムがフリーズした際に、その状態からの回復やファイルシステムを破損させることなくコンピュータを再起動させるために使用される。 用途[編集] サン・マイクロシステムズのOpen Firmware（OpenBoot）と同様のこのキーシーケンスは、ソフトウェア開発やトラブルからの回復を行うための以下のようなツールへのアクセスを提供する。 強制的なファイルシステムのアンマウント プロセスの強制終了 キーボード状態の回復 書き込みキャッシュのフラッシュ（ディスクへの書き込み） システムの再起動 コマンドキー[編集] キーシーケンスは、Altキー、SysRqキーおよびその他の
Manual driver binding and unbinding [LWN.net]
Please consider subscribing to LWNSubscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net. One new feature in the 2.6.13-rc3 kernel release, is the ability to bind and unbind drivers from devices manually from user space.
電源連動 USB HDD の切断・再接続を CLI で - daily dayflower
さいきんの外付けハードディスクは電源連動機能とかついてたりしますね。んで，たとえば REGZA とかにつなぐと，テレビの電源を on にしたときだけハードディスクの電源が on になったりします。 同じようなことを Linux からもやってみたい。 といっても PC の電源を切ったらハードディスクの電源が切れるのは当たり前。PC の電源を入れっぱなし HDD 接続しっぱなしで，ソフトウェア的に HDD の電源を入れたり切ったりできたらいいなぁと思いやってみました。 もしうまくできれば，たとえば定時バックアップの際だけハードディスクの電源を入れて，バックアップが終わったら電源を切るとかできそう。かえって寿命が落ちるかもしんないけど。 調べてみたら，またたびりなっくす UbuntuでのUSBメディアの安全な取り外し とかその元ネタの Yan Li's Words: Safely remove
第555回 いま、あらためてudev | gihyo.jp
皆さん、ホットプラグってますか!? 猫も杓子もUSB端子なこのご時世、いろんなデバイスをPCに繋いだり取り外したりしていることと思います。そこで今回はデバイスの自動認識やデバイス名の設定など、システムの裏方として大活躍しているudevの基本を紹介します。 動的デバイス管理ツールudev udevとはsystemdの別名です。 すみません、言い過ぎました。Ubuntuで使われているudevは、systemdの一部として提供されるデバイスの認識に関わるデーモンでありツールです。もともとは独立したソフトウェアでしたが、2012年にsystemdと同じソースツリーから提供されるようになりました。ただしデーモンプロセスとしてはsystemd（PID=1）から独立しています[1]。 udevは具体的には次のような流れでデバイスを認識し、設定された作業を行います。 カーネルが追加・削除されたデバイスを
UBIFS file system
UBIFS file system Adrian Hunter (Адриан Хантер) Artem Bityutskiy (Битюцкий Артём) Adrian Hunter, Artem Bityutskiy (Битюцкий Артём) 2 Plan Plan ● Introduction (Artem) ● MTD and UBI (Artem) ● UBIFS (Adrian) Adrian Hunter, Artem Bityutskiy (Битюцкий Артём) 3 UBIFS scope UBIFS scope ● UBIFS stands for UBI file system (argh...) ● UBIFS is designed for raw flash devices ● UBIFS is not designed for SSD,
NanoPi NEOのルートファイルシステムをBuildrootで作る(1) - Qiita
始めに NanoPi NEOではオフィシャルの起動SDカードではubuntu 16.04のルートファイルシステムが入っています。手軽に実験するときには必要ものはaptコマンドでインストールできるので便利です。 しかし、いろいろなデーモンプロセスが動いていたりして多少冗長な部分があります。 コンパクトなルートファイルシステムを作るときには私はいつもBuildrootを使います。今回はNanoPi NEOでそれをやってみます。 Buildrootとは 私の記憶では元々はuclibcというlibcの軽量版のルートファイルシステムを構築するものだったのですが、今はglibcも選択できるようになっています。 メインのコマンド群にはbusyboxを使用します。 追加できるパッケージはかなり種類が多く、必要となるものはだいたい揃います。 ビルドのコンフィグの設定にはLinuxカーネルのビルドのときと同じ
Linuxカーネル4.1のvmalloc()（ドラフト） - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
はじめに スラブアロケータ以外の動的メモリ確保 vmalloc関数 vmalloc関数で使用するデータ構造 vmallocの初期化 vmallocでのメモリ確保 vfree関数でのメモリ解放 その他の非連続メモリ領域からメモリを確保する関数 vmap関数 ioremap関数 /proc/vmallocinfoによるメモリ確保状況の確認 はじめに 前回のLinuxカーネル4.1のSLUBアローケータ（ドラフト） - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモと同じくドラフト版公開です。こちらはLinuxカーネル4.1のメモリレイアウト（ドラフト） - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモで説明しなかったvmalloc()の説明です。 カーネルのバージョンは4.1系です。 文書自体も完成版ではないし、markdownから手作業ではてなblogにコピペして修正してるので章立
Linuxカーネル4.1のメモリレイアウト（ドラフト） - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
はじめに ユーザプロセス空間とカーネル空間 x86_64のメモリレイアウト ダイレクトマップ(ストレートマップ）領域 vmalloc/ioremap領域 仮想メモリマップ %esp fixup stack カーネルテキスト領域 モジュールマッピング領域 vsyscall 固定マップ領域 はじめに 前回のLinuxカーネル4.1のSLUBアローケータ（ドラフト） - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモと同じくドラフト版公開です。 カーネルのバージョンは4.1系です。 文書自体も完成版ではないし、markdownから手作業ではてなblogにコピペして修正してるので章立てとか変になってるところとかあるかもしれませんが気にしないでください。 一部は文書修正してます。 ユーザプロセス空間とカーネル空間 Linux x86_64では48bit（256TiB）のアドレス空間を使用できます
Linuxカーネル4.1の名前空間（ドラフト） - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
はじめに 名前空間 名前空間の利点 名前空間の種類 Mount名前空間 IPC名前空間 UTS名前空間 Net名前空間 PID名前空間 User名前空間 名前空間の管理 プロセスと名前空間 名前空間のエクスポート nsfs 名前空間共通データ NSProxy構造体 NSProxyと名前空間 参照カウンタ NSProxyと名前空間の関連 名前空間へのアクセス デフォルトの名前空間 名前空間の共有・分離・移動 名前空間の共有と複製 fork(2) clone(2) fork(2)・clone(2)時の処理 unshare(2) 名前空間の分離処理 名前空間の移動 setns(2) 名前空間の移動処理 Mount名前空間 Mount名前空間の実装 Mount名前空間の初期化 Mount名前空間の分離 IPC名前空間 IPC名前空間の実装 IPC名前空間の初期化 UTS名前空間 UTS名前空間の実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Quirks (Linus Torvalds)
What are PCI quirks?
sysfs bind/unbind attributes usage