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

● 前スレ
ファイルシステム総合スレ その17
http://mao.5ch.net/test/read.cgi/linux/1421502118/

● 関連スレ
ジャーナリングファイルシステム
http://mevius.5ch.net/test/read.cgi/unix/979408065/

OpenSolaris/Illumos (OpenIndiana, etc.) 6
http://mevius.5ch.net/test/read.cgi/unix/1337411922/

FS関連スレ
http://medaka.5ch.net/test/read.cgi/os/1137387538/
過去スレ, 関連リンクは >>2-10 あたりで.

● 過去スレ
01 http://pc.2ch.net/test/read.cgi/linux/1006743807/
02 http://pc5.2ch.net/test/read.cgi/linux/1063025258/
03 http://pc8.2ch.net/test/read.cgi/linux/1101495293/
04 http://pc8.2ch.net/test/read.cgi/linux/1136695633/
05 http://pc8.2ch.net/test/read.cgi/linux/1152348695/
06 http://pc11.2ch.net/test/read.cgi/linux/1164457481/
07 http://pc11.2ch.net/test/read.cgi/linux/1173530292/
08 http://pc11.2ch.net/test/read.cgi/linux/1190788761/
09 http://pc11.2ch.net/test/read.cgi/linux/1225001916/
10 http://pc11.2ch.net/test/read.cgi/linux/1238673446/
11 http://hibari.2ch.net/test/read.cgi/linux/1256639505/
12 http://hibari.2ch.net/test/read.cgi/linux/1281277564/
13 http://engawa.2ch.net/test/read.cgi/linux/1311812102/
14 http://engawa.2ch.net/test/read.cgi/linux/1326613113/
15 http://engawa.2ch.net/test/read.cgi/linux/1341012960/
16 http://hayabusa6.2ch.net/test/read.cgi/linux/1363315915/
17 http://mao.5ch.net/test/read.cgi/linux/1421502118/

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

● 関連リンク3 (SSD関連)
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

● リンク全部は、確認していないので、リンク切れがあれば、ご容赦ください。

乙

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

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

>>1乙

>>8
データ書く時はEEPROMとかフラッシュとかの特性上、イレースした後（全部０にした後）
ビットが１のとこだけに対して、読み込みの時とは別の方法で電流流さないといけない
通電してるかどうかは寿命とは関係ない

PCの場合不可能だけど、マイコンとかでの直接書き込みの場合、チップさえ受け付けてくれれば
オール 0xff を書き込む場合に限ってはイレースの必要は無いし、
一度の書き込みでビットが立たなる程にまで劣化したフラッシュの類に
全く同じビットを書き込んで強引にビットを立てるっていう、姑息な手段がある

ただし１への多重の書き込みは、素子に大きなダメージを与える可能性がある（つまりはそういう事）

>>9
RedHatが匙投げたじゃん　btr2fs とかで再設計とかもないみたいだし、終わりじゃないかな

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

>>12
4GB RAMに1.1M個で2.6TiB
4GB RAM/1M個近い別の環境もエラー出る

メモリ少ないだろって自分でも思うけどSynologyとかのNASはどうすんだよこれ…

>>9
> スワップ使わずにメモリ食い潰してOut of Memoryで落ちるの何とかならんのか
カーネルページはスワップ対象にならんからな
メモリ増やすか、btrfs側を修正するしかないかと

カーネルパラメーターのチューニングという方法もあるがな。
それをするにしても、meminfo のデータ がどういう風になってるか分析しないといけない。

15だけど、後学のためにももう少し詳しく知りたいです
カーネルのパラメータをいじるってのはどんな場合に
なんの値を変更するのですかね？

多分カーネルビルドし直すってことですよね？

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

>>17
ファイルシステム関係は、sysctl.conf に記述するものが多い。ググってね。
実際の設定については、"meminfo vm.dirty_background_ratio" あたりでググると良い。

>>19
なるほど、物理メモリサイズをもう少し確保できるようなチューニングのことでしたか
てっきり、カーネルページまでスワップさせる設定ができるのかと思っていました

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

仮想メモリはファイルシステムと直接の関係は無いだろう

>>21
slabはページ（メモリ）の管理効率をあげるもので、
結局メモリはページ単位で管理されるという認識なのですが、違うんですかね？

>>23
カーネル空間にページがマップされてはいるが、それだけの話。
キーワードを提示することしか出来なくて悪いが、"dentry inode" でググるとどう使われているか少しは分かるかもね。

>>9
8GB積んだらスナップショット消しても落ちないようになった
しかしbtrfs-transactionが動いてる間は同じボリュームではほとんど何もできないのな

Ubuntu, Win, Mac のどれでも書込までできて、しかも2TBの制限もないファイルシステムはexFATですか？
ちなみにOSはどれも最新のものね。

https://ja.wikipedia.org/wiki/ユニバーサルディスクフォーマット
好き好んで使ってるのはそんなにいなさそうだが。名前＆目的としてはこれがなんだがなあ

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

事実上exfatしかないねえ

MacはNTFS使えないの？

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

ntfs-3gもinodeがなんたらでアクセスできないファイルあったりするし互換性確保しようとすると選択肢ホントないね

ファイルシステムってシステムの根幹にある物だしOSへ依存しているものが多いのは仕方ない
exfatでだめならnfsやsmb使ったほうがいい

>>32
まあ、必要ないだろ。
今はファイル鯖にクラウドストレージもあるんだから。
他とやり取りするファイルに属性値なんてそれ程重要じゃないし

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

>>35
そう考えるとexFATは必要最低限という点で適切な選択だと思う
単純さ故にどのOSの実装も問題ないだろう

なぜFATは最大4GBのファイルしか扱えないの？

>>37
Windowsスレで聞いて

>>37
FAT系のファイルシステムはいくつもあり最大16EiBまで扱える

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

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

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

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

どこまで本気なのか判断が難しい

全部本気だから教えて欲しい

>>42
何で最小単位をビットにしたのか教えてくれ

>>45
なんとなく…
でもよく考えたら違うかも
4,294,967,296状態表すことができるってことかな
それがなんで4GBに繋がるのかはわからないけど

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

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

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

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

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

>>46
何が何を表してるのかを混同してんじゃないかな

1つの32bitで表せる数値の最大が4,294,967,296ってだけ
その数値がどんな単位で何を表してるのか(bitかbyteかメートルかグラムかとか)はまた別の話

きょうびセクタだのトラックだのなんてもういらないモノになっちゃったよな

>>50
セクタを何と勘違いしてる？
今でもセクタは絶対に外せない概念なんだけど


CHSで言うセクタとは、単に「１トラックあたりのセクタ数」のことだけど
そんなことしか知らない人が、ファイルシステムのスレッドで知ったかぶって書き込むかね

1セクタは、512バイトで、
ファイルの最小単位が、セクタ8個分だから、4KB

だから、1バイトのファイルを作っても、4KB のサイズになる

セクタ=512Bytesの時代はもう終わったよ

もう4KBが主流になってきてるね

533 名前：login:Penguin[sage] 投稿日：2018/02/01(木) 13:34:25.48 ID:0hMkXx1N
https://i.ytimg.com/vi/_jjwqFhlxi4/maxresdefault.jpg

戌厨のいつものグロ貼り転載ｗ


セクタとクラスタを勘違いしてないか？

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

>>42
> 4Gビット

え?

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

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


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

4KB セクタか。ファイルデータはキャッシュするからページサイズに合わせた 4KB 単位での I/O が普通だったからそこは別に問題がないんだが、ファイルを管理するためのデータ ー メタデータはどうなんだろうかね。
Btree なんかは、キャッシュしたと思うんだが、inode なんかは基本キャッシュしない。読み込んで カーネルのデータ構造に変換してキャッシュとは違う管理をする。
4KB 読み込んで 256B か 512B 書き換えて　書き戻すようなことをするのかね。効率も悪いが、4KB内の関係ないデータが壊れる可能性が出てくる。
関係ないデータが壊れるとお手上げだな、検出できないし、当然復帰できない。
ジャーナルも対応がどうなっているのか。基本は小さなデータを追記しては 書き込み完了を待つ。512B 単位のエミュレーションなんかを使うと、書き込んだはずのものが一部壊れる可能性が出てくる。完全に4KB 単位にして、スカスカで使えば問題は起きないが。

こういうことがあるので、4KBセクタというのは、ファイルシステムの基本設計のバランスを崩してるね。既存のほぼすべてのファイルシステムが向いていないとも言える。

何言ってんだこいつ
4KBセクタへの移行が始まったの何年前だと思ってるんだ

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

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

普通のファイルシステムなら4KB以上でアライメントそろえてるから

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

たぶん、いまどきのOSで、セクタ単位で何かを書き込もうとするものは無いと思う
ブロックやクラスタと言われる単位で連続して書き込む
そのためにアラインメントを揃えたりもしてるんだし

もちろん必要な極一部、例えばMBRの書き換えを要するfdisk等はこの限りではないし
「やろうと思えば」(512Bセクタでエミュレーションしているならば)512B単位で書き込む(書き込もうとする)ことは出来るけど
普通に使っている限り、ブロック単位で扱われる


特定のエミュレーションセクタに書き込み中に電源断が起きて「書き込み未完了」のまま代替処理が行われたら
その周囲のエミュレーションセクタ共々ブロック全体が「書き込み未完了」になるので
仮にセクタ代替処理が行われて周囲のデータ共々入れ替わっても問題は起こらない

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

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

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

>>64
4KBセクタのディスクに512Bセクタだと思って512Bで書き込むとサイレントにデータを破壊することがあるのか・・・

そんな糞設計やだ

だから、ブロック単位でしか扱わないって

１つのセクタが複数のブロックに分散されるのは
アラインメントを揃えずにフォーマットされた、4Kセクタ以前のOSで何も考えずに使われていたものだけ
それも無思慮に扱われてパフォーマンスが低下しているのに文句言いながら使っている人だけ

>>69
パフォーマンス低下って4KBセクタに512Bで書き込む際に発生するRead-modify-Writeでってことかな？

クラスタサイズをNTFSみたいに64KiBにできてもいいのになと思う
メディアファイル格納用にさ

>>71
　https://ja.wikipedia.org/wiki/XFS

とりあえず、XFS の エクステント、遅延アロケーションの項目読んでみ。この機能は ext4 にも導入されている。

上で書いたの間違い。
　X　エクステンション
　O　エクステント

4KBセクタのディスクに512Bじゃデータ書き込めないから

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

なんだこのスレ…ここだけ10年前か？

いやひとりだけコールドスリーブされて来た奴がいるだけだ

頭おかしなるで

> いやひとりだけコールドスリーブされて来た奴がいるだけだ

お前のことだろ SLEEVE

違うだろ

http://medaka.2ch.net/test/read.cgi/market/1516899338/

Raid1のZFSにscrubかけたら
１系のcheck sumにだけunrecoverable errorみたいなのが5〜6個出たんだけど
もう一回scrubしたら消えた。
こういうもん？何か対処した方が良いのかな？

ファイルシステム的にはＯＫな状態になってるわけだから、見るべきはハードウェア側だね。

各ディスクの S.M.A.R.T 情報みて、ECC 系や Reallocate 系、その他エラー系のカウントが
カウントアップしてないか確認。
一回とって数時間後にもう一回とってみて比較。 ヤバそうだったら HDD 交換。

特に電源ブチ切りしたわけでもなく、ハードウェアエラーも発生していない場合は
memtest とかでメモリをテスト(サーバ製品でECC付きなら省略可)。
予防交換可能なモノ (サーバ製品で保守期間内の場合) ならここでマザボ交換。
その後は再発するか様子見して再発するならファイルシステムのバグを疑う
(OS 保守があるなら OS ベンダーにエスカレーションだが ZFS なんでコミュニ
ティに連絡？)、かな。

>>81
ありです。今度の休みに戻ったら順番にまずはS.M.A.R.Tから見てみます
ハードの交換で済めば良いけどZFSのバグだとほかに良さそうなFS知らないから困るなぁ

☆ 現在、衆議員と参議院の両院で、改憲議員が３分の２を
超えております。総務省の、『憲法改正国民投票法』、
でググってみてください。国会の発議はすでに可能です。
平和は勝ち取るものです。お願い致します。☆☆

基地外

動作確認のために久しぶりにCentOS使ったらデフォがXFSになってた
絶滅してなかったんだな！調べたらBtrfsが非推奨とか書かれてて2度ビックリさせられたっていう
流行り廃りが変わってたのか

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

LVMみたいなのなしでスナップショットが取れて
厄介なライセンス問題がなくて
透過的圧縮が選べて
安定動作する
ベストなファイルシステムbstfs(仮)がXFSを元に誕生してくれるはず

>>87
XFS元にとか、raid考えるならブロックレイアウト的に無理ある
btrfsフォークしてテコ入れした方がまだ楽

仕事でbtrfs開発出来たらなあと思う今日この頃

暗号化はあっさり入ったのに圧縮はまだ入らんからファイルサイズ辺りの設計が拡張性なさそう> btrfs
いろいろ詰め込み過ぎたな
ext5はよ

OpenSUSEあたりがデフォでBtrfs使ってたりがんばってたな
使い勝手とかどうだったんだろ

btrfsって圧縮なかったか？
少し前にzstdが使えるようになったって話題になっていた気が…

すまぬbtrfsは圧縮あるな、ext4と勘違いしてたわ

btrfsのdeprecatedはRH系だけだしXFSに振り回されないほうがいい

もし将来的にbtrfsが破棄されるようなことがあってもさすがにその頃には>>88の言う通りテコ入れフォークが誕生したり
あるいはZFS on Linuxのライセンス問題も解決してるだろうから満を持してそっちにスルっと移行が正解

XFSはsnapshotが今後もlvm依存で透過圧縮に至っては念頭にもなしが相変わらずならホント関わらないのが吉
仮にBtrfsが派生無く廃止されてZoLライセンスも悪い方に着地したら……いよいよNILFS2の台頭の時

そんなんbtrfsもxfsも使ってるsuse死亡やん

ハイパーコンバージド界隈だと重複排除や透過圧縮は専用ハード
(ASIC)で高速にやるって流れになりそうだし、スナップショットや
シンプロビジョニングも昔からハード側(というかミドルウェア？)で
やった方が安定してる模様。

つまりソフトじゃハードに勝てず、市場のパイを急速に失いつつ
ある状況だわな。

クラウド化の流れでエントリーレベルのサーバ製品はビジネスの
メインストリームから外れちゃった(PCサーバ数台買って Linux
入れる時代は終わって、外部のクラウドか大規模な内部クラウド
上の仮想マシンに Linux 入れる時代になった)んで、ファイル
システム上でのスナップショットとか透過圧縮とか前世代の技術
なんかに時間を割きたい技術者なんていないでしょ。

>>96
エンドユーザーが使うディスクやファイルシステムに対する解になってないからなあ
まあ興味の集まる分野でもないから技術者が減りそうなのは同意

HCIみたいな箱売りたいメーカーはハード依りだろうけど、クラウド事業者はお高いハードでってのはない気がする
稼働時間に対する障害発生率はハードの方が高いって研究結果もある
確かGoogleが出してた

エンドユーザーレベルに専用ハードも降りて来なくてミドルウェアも複雑化回避で避けられてて
そのうえ技術者まで離れそうとなるとソフト面でも今後ぜんぜん進化しなくなる暗黒時代の到来か
何気にヤバイじゃん！既にその手の機能を自前で確保済みだったファイルシステムは割りと羨ましいが保守されなくなると使うのも危険に

それならこのスレの英知を結集して新しいファイルシステム作れば良いじゃないか！

ext系はずいぶん前に開発者リソース分散を避けるためext5を作らずext4強化で実質5相当にするとか言ってたが
その後の方針はどうなったんだろう

ntfs-3gは互換性にちょい問題あるから仮想マシンのwinにマウントさせれば大丈夫だろうと思ってたけど、物理マシンのwin10にファイルシステムぶっ壊されて尻込みしてきた…

windowsがNTFS壊すことなんて普通ないだろ
壊れる場合は大体ハードか要因

btrfsはまさかのWinBtrfs登場でいま一番すき

狂気

>>102
Win10は次の起動の高速化のためにシャットダウン時に色々やってるから、油断ならない

ntfs-3gのLFS＝Windows7以前のLFSだからWindows8移行のLFSと互換性はない

btrfsからext4に逃げたけど透過圧縮ないとNAS用途だと10%くらい容量食って辛い

恐縮ですが、SSDとHDD混在のVLMでアクセス頻度の高いデータをHDDからSSD側に動的に移動してくれる機能はないでしょうか
例えば　Windows Server 2016 の　記憶域プールのような SSD と HDD を階層化する機能はないでしょうか。
CentOS7を使っています
ご存知の方がいらっしゃいましたら教えてください。

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

>>108
LVM？
階層化は聞いたことないなあ
本質的にはSSDキャッシュだし
git探してもマトモなのないね

>>108
もう開発止まってるっぽいけど、btierとか。

いろいろ情報ありがとうございます。
LVM Cacheキャッシュでいこうと思います。
できないことがわかっただけでもありがたい。

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

XFSのパーティションに別のパーティションから
100万個ファイルをコピーしたら、途中でコピーが止まり
XFSのファイルにいっさいアクセスができなくなったよ。

よくある話らしいが、EXT4で構築すればよかった。

連続書き込み3万個くらいで不具合起きるかもしれないんだっけ

RedHatの一件からだと思うがXFSに手を出して痛い目みる事例が増えてるみたいだな
そのうち安定化するといいが…

XFSでファイル鯖立ててしもうた。
鬱だ。(´・ω・`)

XFSそんななんだ・・・使わんとこ

zfs使えばええやん

>>118
メモリが足りねえ

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

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

ZFSはdedupeをonにすると地獄を見るけどoffだと最強になりすぎて
もうコイツだけで良いんじゃないかなってなって面白みがない

誰かが映画版ジャイアンfsと言ってたが一理あるっていう

ライセンスの問題がなけりゃすべてのディストリが採用してるレベル
オラクルほんとクソ

xfsだめなのぉ？

xfsは中身変わりまくりで歴史が長く信頼性が高いとか言われると？ってなる

>>122
dedup使わなくても空き容量なくなったら死ぬという欠点がある

zfsは機能と安定性は最強だけど、速度は弱くない？

あー、空き容量残り２割切ると遅くなるんだったな
確かに残り１割になったときは遅かった

atimeが更新される条件ってなんですか？
ファイル見ても更新される時とされない時があるんですが

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

ZFSをoptaneで性能底上げしたらどうやろ？

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

btrfsに続いてzfsでもzstd圧縮が使えるようになるらしいな

外国の開発者（ストレージ系）の人とXFSとEXT4について意見交換
したのだが、信頼性を求めるならEXT4じゃね？とメールしたところ、
XFSのほうが多くの面で優れていて、確かに多くのファイルを一度に
更新する（メタデータ更新）とエライコッチャになることが稀にある。
その弱点を差し引いても私はXFSを選ぶよ。　と返事をもらった。
自分はEXT4派だったんだが、XFSに宗旨替えしよう。

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

よく「エライコッチャになる」可能性があるもんを使えるどころか他人に勧められるもんだな・・・

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

xfsは明確な不具合が出ると指摘されたうえでも選ぶんだから厚い信仰心が垣間見れるな

ストレージまわりにそんな危ないの使うのはあるいみ狂信の域だけど
重要データ扱う状況でも無さそうだし文字通り人柱として貢献できるね

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

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

centos7　ext4がデフォらしいけど、かっこつけてxfsにするクセがついてます。
まぁ個人で使う分に違いはわからんでしょ。

centos7はxfsだろ
6まではext4だったが

JFSオヌヌメ

LinuxをZFSにインストールしてみたけどロールバック便利ね
ライセンス問題解決されたらインストーラーで簡単にインストールできるようになって欲しい

zfsはdebianなら公式のリポジトリからインストールできるようになってたろ
それ以上に簡単になってほしいのかね

/boot以外のディレクトリがZFSのファイルシステムに
簡単に出来るとイイね　かな？

古い資料だけど、カーネル違うとXFSの信頼性が変わるとか本当にあるんだね
https://www.toshiba.co.jp/tech/review/2010/11/65_11pdf/rd02.pdf

そんなのxfsに限らず当たり前のことでは？
ext4やbtrfsもカーネルバージョンが違えば様々な変更があるわけだし

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

そりゃ上流にバグが入ったら信頼性下がるに決まってるだろ

たら
　れば

たらの肝臓？

かゆ
　うま

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

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

お前らは仮定と雰囲気と信仰心でファイルシステムを選んでたのか

そうだよ

LinuxのVFS自体がクソなんだから、xfsだろうがzfsだろうがLinux選んでる時点で妥協の産物
可能な限りVFSの影響を排除したfsって何かあったっけ、商用のGPFSとか？

VFSの影響を排除ってどういうこと？
VFSを通さないってこと？

>>155
個人で使う分にはそんなものじゃない?
お仕事で使うならそれなりの試験して比較した上で選ぶんだろうけど

そだねー

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

Btrfsはどうよ？

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

>>162
死んだ

ファイルシステムの拡大縮小ができるのってextとBtrfsとNILFSくらい？

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

>>166
XFS は縮小できない。ってそういうことじゃない？

>>166
XFS JFS F2FS

なんだかんだFATが便利

unkofs

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

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

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

実用的に動くのかな？

nullpofs

僕の知り合いの知り合いができた副業情報ドットコム
関心がある人だけ見てください。
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

1Z3RL

1Z3RL

1Z3RL

Google File System
https://storagemojo.com/google-file-system-eval-part-i/

https://stackoverflow.com/q/6025755/8336727
socketの生成

基本はext4で8TB超えならXFSってことでおけ？

ストレージサーバー分けようぜ

1台か2台なら、なんとなく、とか個人的な好き嫌いで選んでもいいと思う。
LVM使えばSSDをキャッシュとして使えるから、速度差は現れにくくなるし。

HDDの台数が多いと、残念ながらカーネルのメインラインに取り込まれることはないZFS on Linuxが便利で困ってる。
割当ドライブの台数の増減が出来ないのが欠点なくらい。
一度btrfsも使ってみたけど、ドライブ見失う頻度が高すぎで使い物にならなかった。
md-raidはさんざん痛い目あったから違うのを試しました。

という訳で、Redhatが作ると言っていた新しいFSに期待してます。

あ、いわゆるふつうのパソコン用途です

ちなみにここでのNTFSの評価ってどうなんやろ
ファイルシステムとして

評価も何もWindowsでしか使えないから対象外

まあそうだろうけど、ファイルシステムのプロから見たらどうなのかなと
いちおう読み書きできるし

lazytimeオプションってext4専用なのかな？
それとも主要fsならどれでも使えるようになってたり

>>184
スナップショット、暗号化、透過圧縮なんかがあって比較的枯れているからその点ではいいんじゃないの
＞いちおう読み書きできるし
windows以外で使えるかって話なら常用レベルではないので問題外

>>186
Linuxで実用は無理だろうねNTFS
ファイルシステムとしてはext4とどっちが優秀かな
windowsでNTFSのときとLinuxでext4使ったとき比べて

ひとり言なのでスルーでもいいんで

NTFSのスナップショットってVSSでしょ？
あれは実用的と言えるのか

https://inmatelocator.cdcr.ca.gov/Details.aspx?ID=G31008
https://i.imgur.com/n87FKMd.png

2020年7月Hans Reiser仮釈放でReiser4開発再開か？

ブロックチェーン処理に特化した中国製ファイルシステム「TCFS」　劉尭 2018年7月10日 19:25
https://pc.watch.impress.co.jp/docs/news/1132183.html

　中国・深セン市網心科技有限公司は6日(現地時間)、ブロックチェーンの処理に特化したという
ファイルシステム「Thunder Chain File System(TCFS)」を発表した。

　これは同社が展開しているクラウドサービス「迅雷」の数百万のP2Pネットワークノードの基礎の
上で、ブロックチェーン処理と分散に特化したファイルシステム。

　merkle DAGファイル管理技術に基づいており、ファイルのすべての変更履歴を保存し、過去を
遡って検索できる。ハッシュインデックスも暗号化し、ファイルに変更があったさいに新たなハッシュを
発行することで、ファイルの改竄を防ぐ。

　データは前方誤り訂正(FEC)を使って保存され、冗長データをほかのノードに保存することで、
ファイルの破損を自動的に修復することで、データの信頼性を99.9999999999999%までに高めた。

　さらに公開鍵と秘密鍵を利用したユーザーとファイルの関係性の維持、トークンを用いたユーザーの
アクセス権限の管理といった機構も備える。

　応用としては、音楽ストリーミングサービスにおけるライセンス管理、透明性の高いオンライン
トレード、機密性の高いデータの保存などを挙げている。

https://i.imgur.com/peN6peL.png

NTFSは2MBまでクラスタサイズいけるんやな

NTFSで32MBクラスタ使えないのかな
実は勝手に諸元を書き換えて32MBクラスタ使えるとかにならないのかな

クラスタを32MBに出来れば、SMRの使用感が少しは改善されそうだと思うのに

バックアップ用のHDDって最悪Windowsでも読めるようにNTFSにしといたほうが無難？

復旧しやすいようにソースと極力同じになるように設定する事もある
条件次第じゃないか

USBブート出来るOSで読めたほうが良いって考え方もあるしね
一概には言えない

というか、お好みで、としか

今どきVirtualBoxとかでWindows上でLinuxを動かせるんだから、
Windowsが対応してないファイルシステムでもファイル取り出しは問題ないと思うんだけど

VMとLiveCDで何の問題もないな

まずは東京大学理学部数学科に入らなくては。
院はできればハーバードかプリンストンかオックスフォードかケンブリッジに入りたい。
そのためには東大の頃にダントツの成績でないと駄目だな。

ZFSで突然、あるディレクトリが書き込み不能になる
別のディレクトリを作成してファイルをmv
それらファイルが消滅してどこにも見当たらない
元のディレクトリをrmdirしようとすると、Directory not empty
ファイルは残ってそうなのに見えない
復活の呪文ありますか？

データ領域もジャーナリング機能のついたファイルシステムにしたほうが良いんですか？

>>199
本当にお前はダメな奴だな
ここの住人は皆んなハーバードかケンブリッジを首席で卒業した奴らだぞ
分かったならマルチしてないで勉強しなさい

そして超一流自宅警備員へ

>>202
バークレーじゃないの?

>>201
起動時に毎回fsckと戯れたいなら好きにすれば良いと思うよ

文系大学持ち出す時点で何もわかってない奴

自分らが触れる機会があるのはMIT or ケンブリッジ のコードだもんな

一番多そうなのはバークレーだろ

https://github.com/TanninOne/usvfs

パーティションごとにファイルシステムが違ったらどうなるんだろ。
/homeを初期化したくなかったので/homeはext4のまま、
その他はbtrfsにしてみた。そうしたら一見して問題は起こらなかった。
でもまだ長期間使用していないから分からない。

>>210
別になんともならんよ
/boot だけext2 で残りは xfs とかよくあったし、さらには /home は nfs にして Solaris のマシンと共用とか普通に使ってた

古には/ですらnfsにして使ってたしな

exfatってtrimに対応してますか？
USBブート用のLinuxのファイルシステムで悩んでいるのですが
winに差し込むとうっかりフォーマットするリスクを抑えるためにexfatにしようか考え顔なのですが
流石に今どきTRIM未対応のファイルシステムは論外なので。

exfatはそういう用途向けではないだろ

>>213
何度か試したが、exfat では（機器によるかもしれんが）そもそも EFI ブートしない。

https://en.wikipedia.org/wiki/EFI_system_partition

> UEFI firmware supports booting from removable storage devices such as
> USB flash drives. For that purpose, a removable device needs to be
> formatted with a FAT12, FAT16 or FAT32 file system,

FAT12かFAT16かFAT32でないとブートできないみたいよ

/bootと/分けりゃいいだけだろ？

だね

最近の Windows10 では修正されたけど、以前の Windows10 や 8.1 以前はパーティション
切ってある USB メモリは最初のパーティションしか認識しないんだよね。
USB HDD だと2つ目以降のパーティションが見えるのが不思議だった。

/を先に持ってくればなんの問題もないだろ

昔のWindowsの仕様の方が良かったな
先頭だけをvfatにしておけば誤フォーマットすることもなかったし

IOスケジューラの話ってどこのスレでやればいいのかね
LinuxのデフォルトをBFQにする話が出てるけど

>>222
ずっとArchでzenカーネル使ってるけど不具合もないしいいんじゃないの。

>>222
昔はカーネル朗読スレがあった気がした

ext4はさっさとファイル名最大1024バイト対応しろよ
https://mao.5ch.net/test/read.cgi/linux/1541235943/

こんな短いんだ知らんかった

>>2
いつものメリケン基準で、ファイル名なんか256バイトもあれば十分よyeah
とか言っちゃって決めたんだろ。マルチバイト文字とか考えちゃいねぇ

その点Windowsは最初から国際化対応。256文字は必要だから
1024バイトだなって1993年、Windows NT 3.1の頃から対応されてる

リンク先では63文字と書いてあるけど、IVSとかIVDとか考慮すると最低32文字だからな

漢字1文字が最大8バイト、Unicodeの「IVS」とは？
https://tech.nikkeibp.co.jp/it/article/COLUMN/20100126/343783/?ST=spleaf&;P=2

MAX_PATHって256じゃなかったか

Windows10はパス長最大260文字の制限が撤廃されたな
デフォルトだと互換性維持のために制限された状態だから設定変える必要があるけど

ずっと前から260文字なんて超えられてる
MAX_PATHなんてC言語などでWin32を直接使っていた場合で、
たいていの言語では関係ないからな

ext5まだー？

（この世界はもう俺が救って富と権力を手に入れたし、女騎士や女魔王と城で楽しく暮らしてるから、俺以外の勇者は）もう異世界に来ないでください。.zip

が保存できません！

>>232
嘘つくなや

リナクスのは母型となる仮想ファイルシステムで制限あるんだっけ
extの改良だけでは済まないかと

暇つぶしに fuse で超長い名前通してみたけど、通るね

raiserfsが4,032 bytes/255 characters、Reiser4が3976 bytesだから
どこかに制限あるとしても簡単に変更できるようなってると思う

>>233

>>232は211バイトだからね
73文字（うち4文字は1バイト）で63文字を超えてるけど
多くの日本語文字は1文字で3バイトなので、69*3 + 4 = 211 バイト

63文字っていうのはUTF8で全部4バイト文字を使った場合
JIS X 0213の第3・4水準漢字の一部や、絵文字なんかが4バイト
だから一般的には85文字が限界

AKBの
「鈴懸の木の道で『君の微笑みを夢に見る』と言ってしまったら僕たちの関係はどう変わってしまうのか、僕なりに何日か考えた上でのやや気恥ずかしい結論のようなもの」
が76文字（228バイト）だから、もう少し余裕があるな。

アダルトビデオのタイトルは252文字とかすでにext4の限界を突破している。
（252文字と書いてあるサイトを見つけたが実際には249文字だった。
拡張子込みでNTFSの255文字ギリギリ追加い切ってるのかもしれんなｗ）

WinとLinuxの文字数制限は分かったけど
Macの文字数制限はどうなってるの？
あれもLinuxと同じ255バイト制限？

>>238
こっちにまとまってたよ
https://en.wikipedia.org/wiki/Comparison_of_file_systems

主要なのを抜き出すと

HFS Plus ・・・ 255 UTF-16 characters
APFS ・・・ 255 UTF-8 characters

ext4 ・・・ 255 bytes
ReiserFS ・・・ 4,032 bytes/255 characters
Reiser4 ・・・ 3,976 bytes
ZFS ・・・ 255 bytes
Btrfs ・・・ 255 bytes

exFAT ・・・ 255 UTF-16 characters
FAT32/FAT32X ・・・ 8.3 (255 UCS-2 characters with LFN)
NTFS ・・・ 255 characters（ UTF-16 code unit ）
ReFS ・・・ 255 UTF-16 characters

思ったんだけど、UTF-16はサロゲートペアとか使われたら最小127文字かもしれない
LinuxはReiser4を使えばext4の限界突破できるのか
ReiserFSの 4,032 bytesなのに255 charactersってのがよくわからんが（1文字最長16バイトを想定？）



どうでもいいけど、こういうデータは各言語ごとに作成するのって無意味だよなぁ

ほんま文字数制限ゴミやな。
中国人が新しいFSを作ってくれるのをまつしかないか。

ファイル名に長文使えるとどんなことに便利なの？
煽りではなく純粋に使いみちが思い浮かばない…

>>240
255文字のFSはあるしそっち使っては？
伝統的なext、xfsは多分変わらんと思う
新しいFSが出てくるならNVDIMMとか
普及してDAXが流行るころかな

fuse 製なら1ヶ月あれば俺でも作れるけど
馬の骨製はいらんやろうな

>>241
JANコードをファイル名にするよりも
「JANコード + タイトル」の方がわかりやすいやろ？

>>243
うーん俺は>>241じゃないけど
例えばタイトルにスラッシュが含まれてたらもう絶対ファイルの名前にできないじゃん。
だったらファイル名は純粋な整理番号にして，それにメタデータという形でタイトルや作者の情報を添付する。
そしてファイルマネージャで閲覧したときは，その設定したメタデータが見えるようにできたらよくね？

>>243
なるほど
ただlsで表示するときに長文名すぎると邪魔じゃないの？

保存時にタイトルが長いと
エラー出るからな
例えばWinのファイルをLinuxに移してバックアップしようとしたら
ファイル名が長すぎて一部のファイルがエラーになったりする。
短くするにもどう切るとファイル名の意味が損なわれないか個別に考えるのはかなり面倒。

lsじゃなくて、samba等でwindows上のファイラーで見るから
長いファイル名は、一覧では前半しか表示されないけど
個々の名前も見ることが出来るから問題ない

>>244
> 例えばタイトルにスラッシュが含まれてたらもう絶対ファイルの名前にできないじゃん。
スラッシュ省くか全角にすればいいだけでは？
たった一文字のために、コードで管理する必要ない

> そしてファイルマネージャで閲覧したときは，その設定したメタデータが見えるようにできたらよくね？
lsもファイルマネージャｗ

>>248
言い争う気はさらさらないのだが
「ファイルの名前に使用できない」という非常に機械的な理由から，
タイトルの原題文字列を変更してしまうというのは 俺にはどうしても抵抗があるな。

あとlsじゃなくて例えばxlsみたいなコマンド作ってファイルの属性表示させればよくね？

DB使えよもうって遥か昔から言われる案件だろー

お互い折れる気のない人が議論してもなんのためにもならんでしょ
そういう考えの人も居るのか、でスルーすりゃいいのに

例えば

ChMate、旧2chMateは、ファイル名にスレッドのタイトルを利用する
(この仕様と末尾にTABをつける謎仕様のせいで、
外部SDにそのままアーカイブ出来ないという事態が発生したが、それはまた別の話)

スレタイはもちろん文字数制限があるので、全角100文字前後までに普通は収まるが
外部板なども今後も絶対大丈夫などということはなく
仮に全角100文字までとなると、SJISやNTFSのUnicodeならば問題ないが
UTF-8等だと問題が出てくるケースがあるかもしれない
全角150字までとなると、SJISでも255バイトを超えかねない

(5chのサーバー本体はそんなファイルは作らないので、タイトルの最大文字数を増やすこと自体は簡単)
※「全角」は、datが内部的にSJISで記録されていることからも、用語として妥当


NTFSでファイル名の長さが問題になることがあまりないのは
制限があるのが「バイト数」ではなく「文字数」であるため
一方、一部のファイルシステムでの制限は「バイト数」であるため、文字コードによっては
Windows上の制限を大きく下回り、ファイル鯖として使いにくくなってしまう

「自分で使う」ファイルなら、それに合わせたファイル名をつければいいが
Excelで作った文書を保存するねーちゃんが、あとでどれほど見やすさ探しやすさを求めて
どんなファイル名をつけるかなんて、普通は干渉できない


なお、Windows上の制限は、ファイル名についてはそれほど厳しくないが
最大パス長の制限は厳しいので
実際にはそこまで無茶なファイル名が使われることはあまりない

ファイルシステムじゃなくてクソアプリが原因の事例出して何いってんだ

エリートユーザー様しか使わせないファイルシステム様のスレッドだったか

じゃあ俺は場違いだな
さようなら

更にいうとパーティションの暗号化をすると
ファイル名の制限がキツくなるという謎仕様もある

reiserfs じゃだめなんか？

文字数制限は緩いほうが良いけど文字数の為に使うファイルシステム自体を変えようとは思わないな

え？パッケージのためにディストリを変えるくせに？

ディストリの変更とかファイルシステムの変更と比べたら簡単だからな

ファイルシステムの変更のほうが簡単では？
データコピーするだけでしょ？

ファイル名の長短でファイルのサイズは変わらないから
保存容量を減らさずに文章を書き続けられるってことじゃね？？

CP932なWindowsからutf-8なLinuxにファイルを持ってきたらさらに文字制限がきつくなる

>>262
Windowsは完全なUTF16です

Windowsは全角チルダと波ダッシュの文字化け問題を引き起こす不完全OS

Oracleが起動したままxfsをアンマウントしたら、データファイルが全部綺麗に消えました
lost+foundにもありません…
ufsの頃にはこんなことは何度かありましたが、いまどきのジャーナリングファイルシステムで同じことが起きるとは思ってなかったので驚いてます
よくあることなのでしょうか？

前提で？？？？ってなるけど他のファイルシステムで試してみたんか？

データファイルが全部消えて、

オラ狂う

旧時代のファイルシステム「EXOFS」メインラインでのサポート終了へ
Linux Daily Topics　2018年11月14日　階戸アキラ
https://gihyo.jp/admin/clip/01/linux_dt/201811/14

>>265
どうやってアンマウントしたのか

よくよく聞いてみると、どうやらテストの過程で何を間違えたかrmでデータファイルを消したようです
ディレクトリは消えてなかったのでおかしいなぁ、と思ったのですが、まさかそんなオペミスするなんて…
xfsにあらぬ疑いかけてすまんかった

(ﾟдﾟ)

25年前に「魅入られた様に」にrootアカウントで「rm -r /」を実行したっけ…

ある客が /root の中身が消えたというので話を聞いてみると、残ってるデータとかからして、
rm -fr /foo/work/*
って実行しようとして、
rm -fr /foo/work/ *
を(多分)実行したってのがあったなぁ。

4.19でext4が壊れるバグ
https://www.phoronix.com/scan.php?page=news_item&;px=EXT4-Linux-4.19-Corruption

なんでバグッた？

>>275
人がつくるものなどそんなもの

いや詳細をきいてるのかとw
俺も知らんけど

遠因系トラブルで原因はまだ不明らしい。 リンク先みる限り、SSDやNVMe、HDDでも出てて再現できる人は再現
できてるが、できない人はどうやっても再現できない。 VMで再現できた人はいなさそう。
4.18 では問題でないが 4.19 では出るけど、基本的に ext4 周りの修正は 4.18 にバックポートされているので
ext4 モジュール以外のところがトリガーだけど、それがどこかわからないという状態みたいね。

4.19.5で不具合出なかったけど4.18.20に戻した

ext4についてね

なんで?

kernel.orgのchagelog見た感じでは4.18.20と4.19.3でext4のfixだったから
慌てて4.19.2 → 4.18.20コンパイルじゃなく4.19.2 → 4.19.3にすれば良かったというオチだた

4.19.5でも起きてるってコメントもあるんだけどなあ

https://kledgeb.blogspot.com/2018/12/linux-34-linux-kernel-4198.html
Linux その34 - ファイルシステムが破損する問題、Linux kernel 4.19.8で修正
これは？

BLK-MQは有効にしてたけど現象でなかったんだよなあ
デバドラレベルのBUSYステータス発生なんて珍しい状態じゃないだろうし

FreeBSD ZFS File-System Code To Be Re-Based Over ZFS On Linux
https://www.phoronix.com/scan.php?page=news_item&;px=FreeBSD-ZFS-On-Linux

まるでLinuxのZFSが本家みたいになるな
Solarisとかほぼ死んでるし

まじか
最近追いかけてなかったけどそんなことになってたのか

マジかー
ZOL使っててよかった

殺人犯が作った「ReiserFS」使ってる人いる？

ライザーエフエスだよHG

>>920
今は使ってないが
壊れかけのHDDでEXT3よりも頑張ってくれた思い出

>>290
ね

https://inmatelocator.cdcr.ca.gov/Details.aspx?ID=G31008

Hans Reiserは2020年5月に仮釈放の申請ができるようになるらしい（仮釈放が認められるとは限らない）

ラップトップでスナップショット使おうとするとやっぱりbtrfsしかないんだろうか
LVMも使ってみたけどスナップショット取ると遅すぎて使い物にならなかった
ZoLのほうが良かったりするのかな

ZFSってファイルサーバーに使うもんだって勝手に認識してるわ
一般的なデスクトップに使うのってどうなのかね

zfsは遅いから向かない

軽さと安全性はトレードオフ
速さが必要ならext2でも使ってなさいってこった

>>299
今はext4の方が速いよ

もうxfsでいいじゃん

>>297
ワークステーションならまだしもラップトップじゃ力不足だろうね

zfs遅い速いって不毛な議論されてるけど、zfsはボリュームの構成で激しくちがうからなんとも言えないだろう
zfsでシングルボリューム、シングルプールだと力なんか必要ないだろう

いや巣の速度が遅いから

データ壊れるより遅くても耐障害性があるほうがいい、、
ext/xfs/reiser/jsf色々使ったけど懲りた

ZFSは使って楽しいけどね。覚えるコマンドも
少ないし。

>>305
何使ってるの？
btrfsに関しては普段はいいけどいざ問題が起きてメンテナンスしたりするとすげーバギーで常用は辛いって感想
とりあえずlvm+ext4に逃げてる
zfsは使ったことない

>>307
メインはfreebsd+zfs
linuxならext4,xfs
macはapfs
winはNTFS

使いたいOSが押してるやつだな

NTFSは堅牢だよな
カトラーが設計したからな

cephを組む猛者はさすがに居ないか

使ってるけど自動でデプロイされたから中身よく知らない

SSDでも気にするほどの差出るの?

とりあえずbtrfsが遅い
まあxfsやext4はlvm使うことが多いからそうなるとbtrfsとそんなに違わなくなるのかもしれないが
https://www.phoronix.com/scan.php?page=article&;item=linux-50-filesystems&num=1

zfsは構成がどうのとか関係なくメタデータ操作系が全般的に遅いから
homeやspool的なものとかデスクトップマシンとかでは使いたくない

鯖には用途に合わせてxfsとZoL
デスクトップにはbtrfs使ってる
btrfsはもう少し速くなってくれたら言うことないんだけどなあ

zfs勢はbtrfsをpoor man's zfsとか揶揄するけどエンタープライズしか考えていないようなのをノートパソコンで使えたもんじゃないよな

>>173
zfsは、高価なハードウェアを使わない
より安価なソフトで解決する
プアマンズRAIDだしね。

>>317
今どきはCPUが性能余してるからソフトウェアRAIDの方が速いと思う

停電とかの事を考えるとそう単純な話じゃなくなる
バッテリとか大容量キャパシタ積んだコントローラなら突然の停電でも
書き込んだなら書き込んだ、書き込まれてないなら書き込まれてないの
保証がある程度できるけど、
ソフト側で逐次各記憶装置に書き込み命令とか送り込んでると一貫性がなくなる

win10以降の記憶域プールはその辺の対策はしてるみたいだけどめっちゃ遅い
IsPowerProtectedをTrueにすれば早くなるけどその辺の対策がされなくなるしな
所詮ソフトウェアRAIDだからっつーて、
単純にパリティ分散とかミラーリングとかすればいいっちゅーもんでもない

RAIDZで雷の日でも精神ダメージが入らなくなったのは嬉しかったな
バッテリ付きRAID

ごめん途中送信した
バッテリ付きRAID高いから手が出せなかったって言いたかった

小規模・個人レベルならどっちでも良いよ
データ保証はアプリとファイルシステムが担うべき
DCクラスでハードRAIDはナンセンス

ファイルシステムが物理層の構造に依存するとか非現実的だろう

物理というかブロック層はbarrier/fua/flushに従うだけやろ？データとしての一貫性は上位のソフトウェアにしか分からんから>>322は当たり前の事を言ってるぞ

そういえばWindowsはファイルシステムの下位にフィルターが入るとかでWSLがやたらIO遅いとかネタになってたな

WSLが遅いのはNTFSの上でfuseみたいなの動かしてるからじゃないか

>>324
データの保証ってチェックサムレベルだったら勘違いしてるぞ
停電とかで一部のHDDにだけ書き込みが実行されて他に書き込まれなかった時、
単純に分散するだけじゃハードの恒久的な障害かそうじゃないかがわからなくなる
そのフラグなりジャーナリングなりまでをもファイルシステムがやれって事でしょ？

zfsみたいなチェックサムとは訳が違う

>>327
raid5/6のwrite hole問題の話か
あれはストレージノードの冗長構成とっていて頻繁なディスク同期のできない企業向けシステムが気にする問題やろ？停電や強制電源オフを頻繁にする人なら気にしたほうがいいが

それに限らずハード起因の不整合は起こり得る

win10の記憶域プールはファイルシステムより下で
ハード起因なのか停電とかなのかを判別してる

その機能の有効無効のフラグがIsPowerProtected

ZoLの未来は明るくないな
https://www.phoronix.com/scan.php?page=news_item&;px=ZFS-On-Linux-5.0-Problem

互換APIないの？

bcachefsが今年中に使えるようになるんじゃないかね
結構期待してる

今年使えるようになったばかりのfsなんて怖くて使えない

>>334
人柱様に水を差すんじゃねえだ。

Linuxのメインラインに取り込まれるのが今年になるだろうってだけで何年も前から使えるけどな

Linux上のZFSがLinux 5.0でひっかかる
https://www.phoronix.com/scan.php?page=news_item&;px=ZFS-On-Linux-5.0-Problem

少し上のレスくらい見ようぜ

何言ってんだこのバカ

>>337
>>331

Ubuntuどうするだろ

https://cdn-ak.f.st-hatena.com/images/fotolife/k/kazuki09/20160703/20160703191828.jpg

一杯あるねー君達

jfsって使ってる人どれくらい残ってるんだろう

これに新しいReiserfsにRedhatが新しく作ると言われてる奴が加わると思うと、胸が熱くなる

UX4800で主流だったvxfsってどうなったんだろ

olacleのzfsアプライアンスのボリュームをwindows10からsmbアクセスしたとき、大文字小文字の違いしかないファイルペアがあると、それらが8文字の長さの別のファイル名に見えるのはどういう機能なのでしょうか。
NFSでCentOSでマウントして、"hello.txt"と"Hello.txt"を作成すると、Windowsでは
HE~B3GZT.TXT
HE~C3GZT.TXT
という2つのファイルに見えます。

>>345
Windowsはケースセンシティブじゃないから…

ext4で大文字小文字の区別をしないモードが開発されているらしい

それはそれでまた阿鼻叫喚の予感が…

ケースセンシティブでなきゃ死ぬ環境にも問題がありそうな気がする

昔、別の板でだけど
FAT32の外付けディスクにWin2000で大文字小文字だけの違うファイルを作って
それをWin98で読んだらどうなるかってのの話題があったな

FATの特性(エントリべた書き)もあるだろうけど
dirで表示されるファイルとエディタで開くファイルが違うとか、
移動させようとすると別な方が移動されるけど残った方が読めるようになるとか
いろいろ挙動不審だったらしい

>>345
FS側じゃなくてsambaのname manglingじゃねえの
Windowsで使えない文字とかもSamba経由だとそうなる

釈放されたんだから早くreiser4復活しろよ

ようやく時代がreiser4に追いつくか？

今はbcachefsのほうが期待されてるだろう

md-raid 6上の6TBのbtrfsボリュームが怪しくなった
> BTRFS error (device sdb): parent transid verify failed on 222893 34353920 wanted 631557 found 632032
そして消せないサブボリュームがある
# ls -l /mnt/BtrfsTank
ls: /mnt/BtrfsTank/encoding にアクセスできません: 入力/出力エラーです
合計 0
drwxrwsr-x. 1 root video 636 3月 10 13:13 datastorage
d?????????? ? ? ? ? ? encoding

この?の並びが激しく気持ち悪くて不気味だ、このencoding内のデータはどうでもいいってか何も入ってなかった気がする
今の所読めないデータはないし読み書き含め他の部分は問題なく動いて見えるが、btrfs-select-superやbtrfs check --repairやってもダメなので
データ退避してから作り直すしかない
スナップショット撮っては消ししまくりにしてはよく頑張ってくれたと思う

データ退避処理の進捗をみながらRedHatがbtrfs投げ捨ててからの動きとか見てるけど
btrfs on md-raidでいいのかZFS on Linuxに移行すべきかなかなか良いスタンダードが確立してないよねぇ

btrfsはトラブるたんびにモグラ叩き、の繰り返しだったろうに何故に実運用しようとするのか

video encodingかw
エンコ厨のアニヲタは氏ねばいいよw

btrfsは失敗だもう捨てろ

btrfsのスナップショットは作る分にはいいけど…

もうNILFS2は誰も見てくれないのかなあ。
結構好きで/homeに使っているのだけれど。。。

どんなメリットがあって使っているの

>361
Logファイルシステムなんでファイル操作ごとにチェックポイントができるから保存されている限り任意の時点のファイルシステムの状態が復元できるんで、
あ、消しちゃったとか、間違えて書き換えちゃった時にすぐ取り返せる。
ルートで対象のチェックポイントをスナップショットに変更してマウントする作業する必要があるけど。。。
ファイルシステム止めずにスナップショットが得られるので他の作業しながらコンシステンシー気にせずにバックアップが取れる。
書き込み量とストレージのサイズによるけどデフォで1時間で設定で24時間位は遡れるようにしているので割と気軽にファイル操作している。
とは言っても実際にファイル取り返さないといけないケースは1年に数回程度だけど。

このディスクのファイルシステム何かわかる人いませんか・・・・・・FreeBSDのUFSではマウントできず・・・・・・。

GPT fdisk (gdisk) version 0.8.10

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdf: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 5D5F6FE4-4185-11E4-AE7C-20C6EB48C57A
Partition table holds up to 128 entries
First usable sector is 88, last usable sector is 3907029134
Partitions will be aligned on 8-sector boundaries
Total free space is 5071 sectors (2.5 MiB)

Number Start (sector) End (sector) Size Code Name
1 88 4194391 2.0 GiB FFFF
2 4194392 3907011775 1.8 TiB FFFF
3 3907011776 3907024063 6.0 MiB FFFF

パーテション１をddで吸い出してfileしてみたら↓

# file backup-disk-image-sdf1.img
backup-disk-image-sdf1.img: Unix Fast File system [v2] (big-endian) last mounted on /tmp/mnt/ustorage3,
last written at Mon Mar 11 10:13:02 2019, clean flag 0, readonly flag 0, number of blocks 524288, number of data blocks 520071, number of cylinder groups 4,
block size 32768, fragment size 4096, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0,
system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization

あ、ディスク自体はパナのVIERAに外付けHDDとして接続してたTV録画HDDです。
HDD自体はsmartやら、ddやらの読出し結果からは異常はないっぽくて、
どうも中のファイルシステムがおかしくなってるっぽいなんとか復旧したく。

各パーテション、CodeがFFFFでファイルシステムが何かわかりません。
fileの結果からは、/tmp/mntとなってるので、UNIX系の何かだとは思うんですが・・・・

レコーダで初期化したHDDは独自のファイルシステムになってるもんじゃないの？
そうでないと録画データの引っこ抜きとかが容易になるわけで。

> Unix Fast File system [v2] (big-endian)

これが「UFS2」にしか見えなくて、
まずこれをやって
https://www.google.com/search?q=ufs2+%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%80%E3%83%BC
次にこれをやってみて
https://www.google.com/search?q=ufs2+%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%80%E3%83%BC+viera
なんとなく


>>365
そんなことしてたら、コストに見合わない
安定性やバグ取りにサポートまで必要なことに手を出すほど、メーカーはヒマじゃない
せいぜい多少の細工をして外部から読みにくくすることがあるかも程度

てきとうにやってたら━(ﾟ∀ﾟ)━DB構造見えてきたー
https://imgur.com/pg50Nq7

このDBはプリセットっぽいけど一応データを見ておこう・・・・・・
？？？？TVよりはるか昔のなにやら不穏な文字列がががが・・・・・・
パナに怒られても嫌なのであれなところは黒塗りで・・・・・・・・
https://imgur.com/ZtSb9BI

ということで全力でDBデータ吸い出し中。

TV録画HDDまるごとddイメージ用の2TB、
TV録画HDDのパーテションごとddイメージ2用のTB、
パーテションごとddイメージの一応swabイメージ用の2TB、
DB吸い出し用の2TB。空き容量ガー。
今日はもうddでHDDコピーしながらDB吸い出し仕掛けて寝ることにしま・・・・

もし同じような境遇でデータ救えた人がいればアドバイスいただきたく・・・

デコードできるのそれ？

録画データ壊れてて読み込んだ時点で死んでるとかじゃなければDB修復したら元のTVで見れるでしょ

あ、そゆことね

はい。結局マウントかけずにフアイルを読み出すツールだと、情報が断片的にしか読めずDB復旧にはいたりませんでした！あと、ddの完コピディスクも予定通りダメなとこまでコピーされてだめ！南無！

結局、gpartのFFFFコードの小細工を突破して、正攻法でマウントして読み込んでffckなりするしかなさそうですが、これはうちのスキルではむりんご。

【速報】削除後、起動しているだけでデータが復元できなくなるという性質がLinuxのファイルシステムに存在することが判明
https://cloud.watch.impress.co.jp/topics/dds1904/

>Windowsでは、1回削除してもファイルシステム上にはフォルダ構成が残っているのですが、
>Linuxに関しては、削除後はしばらくそのままにしているだけでどんどん消えていきます。
>起動しているだけでデータが消えるという性質がLinuxのファイルシステムにはあります。

ファイルシステム名すら書かずに

セキュリティ的にはそのほうがいいんじゃない？

>>375
Linuxでは削除したデータの復活が難しいって話でしょ?
データが勝手に消えるという意味ではないぞ

ファイルシステムの仕様の話でバグでもなんでもないよな
それにファイルシステム上から完全に削除したファイルの復元なんてWindowsにしろLinuxにしろ保証なんてしてないし

ext4との比較かな
そんな性質あるのか？ssdの場合か？

ext4は結構戻せるからxfsのことでないかな

>>377
一般的には、そうだよね。
記事の内容は、視点がフツーじゃない。

>> 363

LGのTVの録画に使っていたディスクが壊れて調べたらLGのモデルでは次のようなことがあるらしい。

https://www.avforums.com/threads/recording-on-lg-smart-tv-lm760t.1697353/

ひとことでいうと、録画ファイルのメインデータは　JFSの第一パーティション。
メタデータ（リストとかかな？）　はext3の第二パーティションに書き込む。
パーティションタイプはa2という独自のものを利用している（！）

新しいディスクはLG TVにフォーマットさせてたが、
TVが初期化した以前の２TBのWDディスクは
fdisk -l でみるとパーティションのバウンダリがセクターの始まりにないという。
そこでlinux の上で gparted で jfsのパーティションと最後に５０MBほどのext3のパーティションを
つくり、そのあとfdiskの t コマンドで パーティションタイプをa2 に書き換えて、
上のAVForumの投稿にあるように無事つなげた。
（最初まちがってa1を書き込んだらUSB機器に問題があるといって認識せず。
正しくa2にしたら接続したが、「初期化」しますかと聞いてきた。
パーティションから作りかえることはしないだろうとOKして使えるようになった。）

古いディスクは　ddrescueで読みだそうとしているが、3日かかるとか出ていてあきらめ状況。
小さいext3部分は強制的にext3としてマウントできた。jfsの方はだめだった。

消費者としては録画ハードディスクをつなげることができるTVでは
- S.M.A.R.T.の情報を表示して欲しい（ディスクが壊れる場合の８０％くらいはS.M.A.R.T.で予測できるのではないかな。
あとの２０％はいきなりこわれるから、気休めだが。）、
- Windowsマシンなどでバックアップコピーを簡単にできる方法を提供してほしい
とつくづく思った。
（TVの内部キーで暗号化している部分があると思うので、他では再生できないバックアップなんだけども。）

メーカーが独自ファイルシステムなんて作る余裕はないという考えには同意。
LGはパーティションタイプを変えることで　obfuscateしているんだけども上記のAVFORUMの投稿者はどうやって知ったんだろう？

ファイルのヘッダ見るだけでファイルタイプがわかるように、
その人もパーティションのヘッダを見てファイルシステムがわかるんしゃないかな。
ファイルシステムにシグネチャとかあるのか知らんけど。

無かったら mount -t auto なんて出来ないぞ

NixOS Takes Action After 1.2GB/s ZFS Encryption Speed Drops To 200MB/s With Linux 5.0+
https://www.phoronix.com/scan.php?page=news_item&;px=NixOS-Linux-5.0-ZFS-FPU-Drop

ZoLもうダメそうだな

AES-NIが使えなくなってそこまで遅くなってるんだろう
暗号化をAESからchacha20に切り替えたらかなり改善されると思う

>>386
あらら(´・ω・｀)

>>387
ChaChaもChaChaでSSE/AVX使えないのはつらいぞ

ARXはあまりアーキテクチャ依存しないから速いよ

改心したはずのトーバルズ氏がまたもや感情的な暴言
Liam Tung （Special to ZDNet.com） 翻訳校正： 編集部 2019年06月25日 12時28分
https://japan.zdnet.com/article/35138967/

(前略)　Torvalds氏に早速かんしゃくの矛先を向けられたのは、オーストラリア人プロ
グラマーのDave Chinner氏である。Chinner氏は、多くのLinuxディストリビューションが
サポートしているSilicon Graphics製のXFSファイルシステムを管理している。(中略)

　しかしTorvalds氏は、Chinner氏の言い分を否定し、そのような考えを広めようと
している開発者は「無能だ」と痛烈に批判した。

　「Dave、キャッシュはちゃんと機能する。そう思わない者は無能なだけだ。ファイル
システムによるアクセスの99％はキャッシュに保存され、IOを行うことは決してない。
ページキャッシュはファイルシステムを美しく処理している」（Torvalds氏）

　それに対してChinner氏は、Linuxの行動規範に従い「礼儀正しく議論する」ことをリマイ
ンドし、カーネル開発者がプロらしく論議できる雰囲気を作ろうと、次のように回答した。

　「その通りだ。ページキャッシュは多くのストレージより高速なため、問題なく機能する
ケースはたくさんある。しかし、私が指摘したのは、そのことではない」「わたしが、IOの
並行処理、ページキャッシュ、既存コードのアーキテクチャー上の不具合などについて書い
た長文のメールの中から、たった1つの記述を前後関係を無視して引用し、まったく新しい
文脈をでっちあげた上で、私がキャッシュやページキャッシュのことを全く理解していない
と非難し始めた。」「プロらしからぬ振る舞いだ。しかし残念ながら、まったく予測できた
反応だとしか言いようがない」とChinner氏は応じている。

>>391
>ページキャッシュはいまも、ダイレクトIOよりかなりスピードが遅い。そしてNVMeのSSDが高速になればなるほど、
>そのギャップは広くなりつつある。PCIe 4のSSDで、この問題はますます明白になるだろう。もはやページキャッシュを
>使用する理由は、旧態依然としたディスクストレージを使う手頃な価格のシステムやmmap() をサポートするためだけになりつつある

じゃあnvme用に新しいファイルシステム考えれば良いんじゃね？って気はするけどね。
磁気ディスクを前提としたファイルシステムIOいじって喧嘩するなよｗｗ

何言ってんだ
ページキャッシュはファイルシステムの機能ではないだろ

SSD向けのファイルシステムならもうあるからな

>>393
> ページキャッシュはファイルシステムの機能ではないだろ

ではないにしても最終的にこの人が弄ったのはfs/配下なんでしょ？
何れにしてもそんなコアな部分を、nvmeの為に変更しますとか言ったら
揉めるのはしょうがない。

どちらかというと仮想メモリ周辺の話じゃないか

何にしても特定機能の為に汎用部分弄ったら怒られるのはしょうがない。

非常に根本的が疑問があるんだが
ダイレクトI/Oより遅いページキャッシュってなんか話がおかしくね
ページキャッシュってオンメモリならストレージインターフェースより速いはずでは…？

ページキャッシュが無い環境を使ったことがないから分からんな
どうなんだろうな

>>398
オンメモリでもページキャッシュの管理コストが絶対に発生するので
昔はストレージアクセスが文字通り桁違いに遅かったので管理コストは
無視しても差し支え無かったけど今はそうも言ってられなくなったってことかと

ダイレクトIOが遅いって言ってるのは
rawデバイスでDB扱うレベルの話でOK?
でないとRAMがSSDに。ページキャッシュのコストがあるとはいえ遅いという話にはならんと思うんだが

NVMeも通り越して、3DXpointだかあの辺のDRAMの数分の1くらいまで速いメモリを使うようになったら
ページキャッシュ経由するより直で読み書きした方が良くね？って話ならまだわかるけど
いくらNVMeでもフラッシュメモリ使っててページキャッシュはオーバーヘッドだからもう要らないみたいな話なら、何言ってんだお前…ってなる