ファイルシステム総合スレ その18

本当に根拠が宗教的信仰心しかない・・・

むしろ出来ないのあるの？

>>162
死んだ

VFSの挙動変更やIFの変更があればFSによって安定性や性能は変わるだろうよ

ブロックデバイスならスタックオーバーフローとかハングとかあった
FSの事例は知らん

起動時にパラメータを渡すだけのものもあるよ
grubのメニューを作って試してみればいい

>>148
カーネルの違いによるファイルシステムの信頼性変化のソース頂戴
今btrfsからの乗り換え先を探してるから
出来ればその資料みたいに最新化したことで信頼性が悪化する例をもっと見てみたい

1Z3RL

http://gigazine.net/news/20171212-intel-optane-zfs-zil-slog/
この記事ZFSにoptane最高だぜって言ってるけど
そもそもl2arcとzilの有効性が微妙だからな
耐久度という意味では間違いなくいいけど

● 関連リンク 2
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

LVM Cacheが多分一番楽
既にあるLogicalVolumeに対してもSSDをキャッシュに出来る
動いてる状態でにキャッシュの追加と削除が可能
3年くらい使ってるけど、特に問題は起きてない
あくまでキャッシュなのでSSD追加しても全体の容量は増えないけど

>>162
メモリいっぱい積んでサブボリュームあんまり使わないでメンテもしないならまあ安定してるような

そだねー

>>37
ファイルサイズを表現するビット幅が32ビットなんだと思う

初めて聞いたわそんなん
fs選択は地獄だな

>>166
XFS JFS F2FS

zshはmetadataの処理速度が遅すぎて、ガリガリアクセスするとこには使いたくないわ

>>59
バランスを考えるならメタとデータの書き込み比率を考慮しないとね

>>30
標準では読み込みのみ。

そんな糞設計やだ

>>72
すまね、ext系列の話
管理方法じゃなくてブロックサイズの話な。

noatimeとかそういうのでぐぐったところ、

流石に情報が遅すぎないか

hddとかssdとかusbメモリをudfフォーマットできるの？

FAT32のメタデータの中にファイルサイズを表す数字を置く場所があって
その場所の大きさが32bitしかない
そして、2^32で表せる数字が約40億
だから最大4Gまで
※ファイルサイズはバイト単位だから、4Gバイトまで

FATというのは、DOSで使うために作られたファイルシステム
FAT32というのは、FATをWindows95OSR2で使うために拡張されたファイルシステム
だからWindows関係の板で聞く方がいいというのは正しい

4KBセクタだと、急な電源断で Write 中のデータが失われる場合 、4KB のセクタ単位で壊れるわけだな。512B セクタだと思って処理してると、関係ない所が壊れるケースが出てくるという話。
あたり前の話なんだが、一般人に警告されたことはないようだな。

LinuxにはまともなFS自体無いしね
今ならext4が一番無難そう

>>42
> 4Gビット

え?

ext以外で予約領域の概念があるファイルシステムってある？

もしファイルサイズのデータがセクタ数を意味するものであったのなら
2TBまでのファイルが作れたかもしれない(512Bとして)

だけどファイルサイズはバイト数で表すものであって、セクタ数ではない
もちろんビット数でもない

勝手にビット数だと決めつけるのは自由だが
それは自分で作ったFSのフォーマットで使ってくれ

かゆ
　うま

btrfsはファイル沢山あるとこでスナップショット消したりscrub/balanceするとスワップ使わずにメモリ食い潰してOut of Memoryで落ちるの何とかならんのか
そうじゃなくても負荷がかかるとわりと簡単にエラー吐くし

zfs使えばええやん

数万のファイル更新は絶対にやらないシステムならいいんじゃね？
XFS使ったことないけどkernelのソースとか取ってきたら死にそうw

２の３２乗を計算するとすぐわかる

>>65
ハードディスクは、セクタ単位で読めなくなる。その単位でしか ECC がないんだから当然そうなる。
前のデータが一部残っているとかはない。
代替処理というのは、また別の話。リードエラーが起きたセクタに書き込めば、なにもなかったように書き込める機能。

いまどきのOS?　ファイルシステムは古いものが多いぞ。NTFS , XFS , JFS, EXT2 などは 1990 年代の設計だ。
EXT は、2,3,4 と進化しているが、ディスクレイアウトの基本は同じ。エクステンションなど取り入れてはいるが、XFS の最小から実装されていたような古いもの。
ブロックやクラスタとか もっと前の話だな。

新しい設計というと、btrfs 、ZFS なんかの COW ファイルシステムだが、現状はいまいちだな。NetApp の WAFL 特許がネック。

乙

>>59 はジャーナリングは信用出来ないとかいってext2使ってそう

nullpofs

カーネルのデータは、だいたい slab を使って管理する。ページ単位では管理しないよ。
で、メモリが圧迫されると、shrink するようなコードが動いたりする。そういったパラメータとかはあるよ。

そうだよ

2の32乗 = 4,294,967,296 で確かに4Gになるけどこれって4Gビットだよね
なんでここから4GBに繋がるの？

>>38 windows関係あるの？ >>39 FAT32の話ね

重複排除使わなきゃそんなに使わなくね？

前スレの話
そもそも通電してれば問題ないんじゃないの？

>>9
どれくらいのファイル数でどんだけのメモリ？

メタ情報はPOSIXで標準化されたとしても独自に拡張するし相互運用はする物じゃない
exfatみたいに単純なファイルのやりとり程度でとどめるべき

xfsは2010年ごろ？に大改修されて、
その道の人に言わせるとext4より良くなったとか

RHEL 7.5のVDOを試してみた人いますか？

いろんな種類のインストールイメージを複数枚分保存したら、
およそ半分のサイズで収まったらしいと聞いています。

ZFS on Linuxでそんなことをやったらメモリーがパンクし、
CPUはフル稼働に、その後いろいろ調子が悪くなりそう。

実用的に動くのかな？

>>55
誰が勘違いしてるの？
本当にわかってる？

セクタは物理的なディスクが扱う最小単位
クラスタはOSが扱う最小単位

おまえ、本当にバカでしょ

>>46だがようやく理解できた
ありがとう！

基地外