ファイルシステム総合スレ その18
ファイルシステム総合スレ その17
http://mao.2ch.sc/test/read.cgi/linux/1421502118/
● 関連スレ
ジャーナリングファイルシステム
http://mevius.2ch.sc/test/read.cgi/unix/979408065/
OpenSolaris/Illumos (OpenIndiana, etc.) 6
http://mevius.2ch.sc/test/read.cgi/unix/1337411922/
FS関連スレ
http://medaka.2ch.sc/test/read.cgi/os/1137387538/
過去スレ, 関連リンクは >>2-10 あたりで.
01 http://pc.2ch.sc/test/read.cgi/linux/1006743807/
02 http://pc5.2ch.sc/test/read.cgi/linux/1063025258/
03 http://pc8.2ch.sc/test/read.cgi/linux/1101495293/
04 http://pc8.2ch.sc/test/read.cgi/linux/1136695633/
05 http://pc8.2ch.sc/test/read.cgi/linux/1152348695/
06 http://pc11.2ch.sc/test/read.cgi/linux/1164457481/
07 http://pc11.2ch.sc/test/read.cgi/linux/1173530292/
08 http://pc11.2ch.sc/test/read.cgi/linux/1190788761/
09 http://pc11.2ch.sc/test/read.cgi/linux/1225001916/
10 http://pc11.2ch.sc/test/read.cgi/linux/1238673446/
11 http://hibari.2ch.sc/test/read.cgi/linux/1256639505/
12 http://hibari.2ch.sc/test/read.cgi/linux/1281277564/
13 http://engawa.2ch.sc/test/read.cgi/linux/1311812102/
14 http://engawa.2ch.sc/test/read.cgi/linux/1326613113/
15 http://engawa.2ch.sc/test/read.cgi/linux/1341012960/
16 http://hayabusa6.2ch.sc/test/read.cgi/linux/1363315915/
17 http://mao.2ch.sc/test/read.cgi/linux/1421502118/
ext4 http://www.bullopensource.org/ext4/ (リンク切れ)
reiserfs/reiser4 http://www.namesys.com/ (リンク切れ)
xfs http://oss.sgi.com/projects/xfs/ (リンク切れ)
jfs http://jfs.sourceforge.net/
nfs http://nfs.sourceforge.net/
ntfs http://sourceforge.jp/projects/sfnet_linux-ntfs/
fuse http://fuse.sourceforge.net/
btrfs http://btrfs.wiki.kernel.org/index.php/Main_Page
NILFS2 (NTT) http://www.nilfs.org/ja/ (リンク切れ)
zfs http://zfsonlinux.org/
http://hub.opensolaris.org/bin/view/Community+Group+zfs/WebHome (リンク切れ)
en:List of file systems
http://en.wikipedia.org/wiki/List_of_file_systems
Linuxファイルシステム技術解説
http://www.atmarkit.co.jp/flinux/index/indexfiles/linuxfsindex.html
Linuxの次世代ファイルシステムは「バターFS」!?
http://www.atmarkit.co.jp/news/200807/10/btrfs.html
Linux ジャーナリング・ファイルシステムの徹底調査
http://www.ibm.com/developerworks/jp/linux/library/l-journaling-filesystems/?ca=drs-jp
Linux フラッシュ・ファイルシステムの徹底調査
http://www.ibm.com/developerworks/jp/linux/library/l-flash-filesystems/?ca=drs-jp
Linux filesystem benchmark 2008/1-2
http://www.t2-project.org/zine/1/
http://www.t2-project.org/zine/4/
Filesystem Specifications - Links & Whitepapers
http://www.forensics.nl/filesystems
Linuxファイルシステムベンチマーク ext3, ext4, JFS, ReiserFS, XFS, NILFS2
http://hesonogoma.com/linux/FileSystemBenchmarkResults-01.html
http://hesonogoma.com/linux/FileSystemBenchmarkResults-02.html
[Phoronix] Benchmarking ZFS On FreeBSD vs. EXT4 & Btrfs On Linux
http://www.phoronix.com/scan.php?page=article&item=zfs_ext4_btrfs
Oracle Solaris ZFS 管理ガイド
http://docs.oracle.com/cd/E19253-01/819-6260/
● リンク切れ
File Systems in Linux
http://www.linux.org/lessons/advanced/x1254.html
LinuxサーバーにSSDを使うための情報メモ
http://oopsops.hatenablog.com/entry/2012/05/24/164941
Linux+SSDのファイルシステムベンチマーク
http://smackerelofopinion.blogspot.jp/2012/06/intel-ssd-520-goodness.html
http://hesonogoma.com/SSD/Intel_SSD-330-Series_120GB_Benchmark.html
http://hesonogoma.com/SSD/Silicon-Power_SSD-T10-128GB_Benchmark.html
そもそも通電してれば問題ないんじゃないの？
そうじゃなくても負荷がかかるとわりと簡単にエラー吐くし
>>8
データ書く時はEEPROMとかフラッシュとかの特性上、イレースした後（全部０にした後）
ビットが１のとこだけに対して、読み込みの時とは別の方法で電流流さないといけない
通電してるかどうかは寿命とは関係ない
PCの場合不可能だけど、マイコンとかでの直接書き込みの場合、チップさえ受け付けてくれれば
オール 0xff を書き込む場合に限ってはイレースの必要は無いし、
一度の書き込みでビットが立たなる程にまで劣化したフラッシュの類に
全く同じビットを書き込んで強引にビットを立てるっていう、姑息な手段がある
ただし１への多重の書き込みは、素子に大きなダメージを与える可能性がある（つまりはそういう事）
RedHatが匙投げたじゃん btr2fs とかで再設計とかもないみたいだし、終わりじゃないかな
どれくらいのファイル数でどんだけのメモリ？
4GB RAMに1.1M個で2.6TiB
4GB RAM/1M個近い別の環境もエラー出る
メモリ少ないだろって自分でも思うけどSynologyとかのNASはどうすんだよこれ…
乙
>>3
http://www.nilfs.org/ja/
↓
https://nilfs.osdn.jp/ja/
ですな
> スワップ使わずにメモリ食い潰してOut of Memoryで落ちるの何とかならんのか
カーネルページはスワップ対象にならんからな
メモリ増やすか、btrfs側を修正するしかないかと
それをするにしても、meminfo のデータ がどういう風になってるか分析しないといけない。
カーネルのパラメータをいじるってのはどんな場合に
なんの値を変更するのですかね？
多分カーネルビルドし直すってことですよね？
grubのメニューを作って試してみればいい
ファイルシステム関係は、sysctl.conf に記述するものが多い。ググってね。
実際の設定については、"meminfo vm.dirty_background_ratio" あたりでググると良い。
なるほど、物理メモリサイズをもう少し確保できるようなチューニングのことでしたか
てっきり、カーネルページまでスワップさせる設定ができるのかと思っていました
で、メモリが圧迫されると、shrink するようなコードが動いたりする。そういったパラメータとかはあるよ。
slabはページ（メモリ）の管理効率をあげるもので、
結局メモリはページ単位で管理されるという認識なのですが、違うんですかね？
カーネル空間にページがマップされてはいるが、それだけの話。
キーワードを提示することしか出来なくて悪いが、"dentry inode" でググるとどう使われているか少しは分かるかもね。
8GB積んだらスナップショット消しても落ちないようになった
しかしbtrfs-transactionが動いてる間は同じボリュームではほとんど何もできないのな
ちなみにOSはどれも最新のものね。
好き好んで使ってるのはそんなにいなさそうだが。名前＆目的としてはこれがなんだがなあ
標準では読み込みのみ。
exfatでだめならnfsやsmb使ったほうがいい
まあ、必要ないだろ。
今はファイル鯖にクラウドストレージもあるんだから。
他とやり取りするファイルに属性値なんてそれ程重要じゃないし
exfatみたいに単純なファイルのやりとり程度でとどめるべき
そう考えるとexFATは必要最低限という点で適切な選択だと思う
単純さ故にどのOSの実装も問題ないだろう
Windowsスレで聞いて
FAT系のファイルシステムはいくつもあり最大16EiBまで扱える
ファイルサイズを表現するビット幅が32ビットなんだと思う
なんでここから4GBに繋がるの？
>>38 windows関係あるの？ >>39 FAT32の話ね
何で最小単位をビットにしたのか教えてくれ
なんとなく…
でもよく考えたら違うかも
4,294,967,296状態表すことができるってことかな
それがなんで4GBに繋がるのかはわからないけど
その場所の大きさが32bitしかない
そして、2^32で表せる数字が約40億
だから最大4Gまで
※ファイルサイズはバイト単位だから、4Gバイトまで
FATというのは、DOSで使うために作られたファイルシステム
FAT32というのは、FATをWindows95OSR2で使うために拡張されたファイルシステム
だからWindows関係の板で聞く方がいいというのは正しい
2TBまでのファイルが作れたかもしれない(512Bとして)
だけどファイルサイズはバイト数で表すものであって、セクタ数ではない
もちろんビット数でもない
勝手にビット数だと決めつけるのは自由だが
それは自分で作ったFSのフォーマットで使ってくれ
何が何を表してるのかを混同してんじゃないかな
1つの32bitで表せる数値の最大が4,294,967,296ってだけ
その数値がどんな単位で何を表してるのか(bitかbyteかメートルかグラムかとか)はまた別の話
セクタを何と勘違いしてる？
今でもセクタは絶対に外せない概念なんだけど
CHSで言うセクタとは、単に「１トラックあたりのセクタ数」のことだけど
そんなことしか知らない人が、ファイルシステムのスレッドで知ったかぶって書き込むかね
ファイルの最小単位が、セクタ8個分だから、4KB
だから、1バイトのファイルを作っても、4KB のサイズになる
https://i.ytimg.com/vi/_jjwqFhlxi4/maxresdefault.jpg
戌厨のいつものグロ貼り転載ｗ
セクタとクラスタを勘違いしてないか？
ありがとう！
> 4Gビット
え?
誰が勘違いしてるの？
本当にわかってる？
セクタは物理的なディスクが扱う最小単位
クラスタはOSが扱う最小単位
おまえ、本当にバカでしょ
Btree なんかは、キャッシュしたと思うんだが、inode なんかは基本キャッシュしない。読み込んで カーネルのデータ構造に変換してキャッシュとは違う管理をする。
4KB 読み込んで 256B か 512B 書き換えて 書き戻すようなことをするのかね。効率も悪いが、4KB内の関係ないデータが壊れる可能性が出てくる。
関係ないデータが壊れるとお手上げだな、検出できないし、当然復帰できない。
ジャーナルも対応がどうなっているのか。基本は小さなデータを追記しては 書き込み完了を待つ。512B 単位のエミュレーションなんかを使うと、書き込んだはずのものが一部壊れる可能性が出てくる。完全に4KB 単位にして、スカスカで使えば問題は起きないが。
こういうことがあるので、4KBセクタというのは、ファイルシステムの基本設計のバランスを崩してるね。既存のほぼすべてのファイルシステムが向いていないとも言える。
4KBセクタへの移行が始まったの何年前だと思ってるんだ
バランスを考えるならメタとデータの書き込み比率を考慮しないとね
あたり前の話なんだが、一般人に警告されたことはないようだな。
ブロックやクラスタと言われる単位で連続して書き込む
そのためにアラインメントを揃えたりもしてるんだし
もちろん必要な極一部、例えばMBRの書き換えを要するfdisk等はこの限りではないし
「やろうと思えば」(512Bセクタでエミュレーションしているならば)512B単位で書き込む(書き込もうとする)ことは出来るけど
普通に使っている限り、ブロック単位で扱われる
特定のエミュレーションセクタに書き込み中に電源断が起きて「書き込み未完了」のまま代替処理が行われたら
その周囲のエミュレーションセクタ共々ブロック全体が「書き込み未完了」になるので
仮にセクタ代替処理が行われて周囲のデータ共々入れ替わっても問題は起こらない
ハードディスクは、セクタ単位で読めなくなる。その単位でしか ECC がないんだから当然そうなる。
前のデータが一部残っているとかはない。
代替処理というのは、また別の話。リードエラーが起きたセクタに書き込めば、なにもなかったように書き込める機能。
いまどきのOS? ファイルシステムは古いものが多いぞ。NTFS , XFS , JFS, EXT2 などは 1990 年代の設計だ。
EXT は、2,3,4 と進化しているが、ディスクレイアウトの基本は同じ。エクステンションなど取り入れてはいるが、XFS の最小から実装されていたような古いもの。
ブロックやクラスタとか もっと前の話だな。
新しい設計というと、btrfs 、ZFS なんかの COW ファイルシステムだが、現状はいまいちだな。NetApp の WAFL 特許がネック。
4KBセクタのディスクに512Bセクタだと思って512Bで書き込むとサイレントにデータを破壊することがあるのか・・・
１つのセクタが複数のブロックに分散されるのは
アラインメントを揃えずにフォーマットされた、4Kセクタ以前のOSで何も考えずに使われていたものだけ
それも無思慮に扱われてパフォーマンスが低下しているのに文句言いながら使っている人だけ
パフォーマンス低下って4KBセクタに512Bで書き込む際に発生するRead-modify-Writeでってことかな？
メディアファイル格納用にさ
https://ja.wikipedia.org/wiki/XFS
とりあえず、XFS の エクステント、遅延アロケーションの項目読んでみ。この機能は ext4 にも導入されている。
上で書いたの間違い。
X エクステンション
O エクステント
すまね、ext系列の話
管理方法じゃなくてブロックサイズの話な。
お前のことだろ SLEEVE
http://medaka.2ch.sc/test/read.cgi/market/1516899338/
１系のcheck sumにだけunrecoverable errorみたいなのが5〜6個出たんだけど
もう一回scrubしたら消えた。
こういうもん？何か対処した方が良いのかな？
各ディスクの S.M.A.R.T 情報みて、ECC 系や Reallocate 系、その他エラー系のカウントが
カウントアップしてないか確認。
一回とって数時間後にもう一回とってみて比較。 ヤバそうだったら HDD 交換。
特に電源ブチ切りしたわけでもなく、ハードウェアエラーも発生していない場合は
memtest とかでメモリをテスト(サーバ製品でECC付きなら省略可)。
予防交換可能なモノ (サーバ製品で保守期間内の場合) ならここでマザボ交換。
その後は再発するか様子見して再発するならファイルシステムのバグを疑う
(OS 保守があるなら OS ベンダーにエスカレーションだが ZFS なんでコミュニ
ティに連絡？)、かな。
ありです。今度の休みに戻ったら順番にまずはS.M.A.R.Tから見てみます
ハードの交換で済めば良いけどZFSのバグだとほかに良さそうなFS知らないから困るなぁ
超えております。総務省の、『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆
絶滅してなかったんだな！調べたらBtrfsが非推奨とか書かれてて2度ビックリさせられたっていう
流行り廃りが変わってたのか
厄介なライセンス問題がなくて
透過的圧縮が選べて
安定動作する
ベストなファイルシステムbstfs(仮)がXFSを元に誕生してくれるはず
XFS元にとか、raid考えるならブロックレイアウト的に無理ある
btrfsフォークしてテコ入れした方がまだ楽
仕事でbtrfs開発出来たらなあと思う今日この頃
いろいろ詰め込み過ぎたな
ext5はよ
使い勝手とかどうだったんだろ
少し前にzstdが使えるようになったって話題になっていた気が…
もし将来的にbtrfsが破棄されるようなことがあってもさすがにその頃には>>88の言う通りテコ入れフォークが誕生したり
あるいはZFS on Linuxのライセンス問題も解決してるだろうから満を持してそっちにスルっと移行が正解
仮にBtrfsが派生無く廃止されてZoLライセンスも悪い方に着地したら……いよいよNILFS2の台頭の時
(ASIC)で高速にやるって流れになりそうだし、スナップショットや
シンプロビジョニングも昔からハード側(というかミドルウェア？)で
やった方が安定してる模様。
つまりソフトじゃハードに勝てず、市場のパイを急速に失いつつ
ある状況だわな。
クラウド化の流れでエントリーレベルのサーバ製品はビジネスの
メインストリームから外れちゃった(PCサーバ数台買って Linux
入れる時代は終わって、外部のクラウドか大規模な内部クラウド
上の仮想マシンに Linux 入れる時代になった)んで、ファイル
システム上でのスナップショットとか透過圧縮とか前世代の技術
なんかに時間を割きたい技術者なんていないでしょ。
エンドユーザーが使うディスクやファイルシステムに対する解になってないからなあ
まあ興味の集まる分野でもないから技術者が減りそうなのは同意
HCIみたいな箱売りたいメーカーはハード依りだろうけど、クラウド事業者はお高いハードでってのはない気がする
稼働時間に対する障害発生率はハードの方が高いって研究結果もある
確かGoogleが出してた
そのうえ技術者まで離れそうとなるとソフト面でも今後ぜんぜん進化しなくなる暗黒時代の到来か
何気にヤバイじゃん！既にその手の機能を自前で確保済みだったファイルシステムは割りと羨ましいが保守されなくなると使うのも危険に
その後の方針はどうなったんだろう
100〜のスレッドの続きを読む
