ファイルシステム総合スレ その17 [転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
2年ぐらい使ったCentOS7のノートPCがあり、OSは16GBのSSDに、
内部ストレージをZpoolにしてました。
訳あって先日Ubuntu16.04に入れ替えました。最悪Zpoolは
初期化を覚悟しましたが、大きな問題なく引き継ぎができました。
元のZFSはzfsonlinux.orgので、UbuntuのはOSに入っているものを
使いました。ストレージのデータに互換性があって良かったです。
てか全く同じバイナリーでしたっけ？ https://wikileaks.org/vault7/#Angelfire
Angelfireは、Solartime、Wolfcreek、Keystone（以前はMagicWand）、BadMFS、Windows一時ファイルシステムの5つのコンポーネントで構成されたインプラントです。
以前に公開されたVault7シリーズのCIAプロジェクト（GrasshopperとAfterMidnight）と同様に、
Microsoft Windowsオペレーティングシステム（XPまたはWin7）を実行しているターゲットコンピュータにカスタムインプラントを読み込んで実行できる永続的なフレームワークです。
Solartimeはパーティションブートセクタを変更し、Windowsが起動時にデバイスドライバを読み込んだときに実行されたWolfcreekインプラントを読み込んで実行し、
他のAngelfireインプラントをロードして実行することができます。これらの文書によると、追加のインプラントをロードすると、感染したマシンで検出される可能性のあるメモリリークが発生します。
キーストーンは、Wolfcreekインプラントの一部であり、悪意のあるユーザーアプリケーションを開始する責任があります。
読み込まれたインプラントはファイルシステムに決して触れないので、プロセスが実行されたという証拠はほとんどありません。
オペレーティングシステムが別のパーティションまたは別のパスにインストールされている場合、Windowsタスクマネージャーで常に検出され、「C：\Windows\system32\svchost.exe」と表示されます。
BadMFSは、アクティブなパーティションの最後（またはそれ以降のバージョンのディスク上のファイル）に作成される秘密ファイルシステムを実装するライブラリです。
Windows一時ファイルシステムは、AngelFireをインストールする新しい方法です。
独立したコンポーネントをディスク上に置くのではなく、インストール、AngelFireへのファイルの追加、AngelFireからのファイルの削除など、
特定のアクションの一時ファイルを作成することができます。一時ファイルは 'UserInstallApp'に追加されます。
Angelfire 2.0 -- User Guide
https://wikileaks.org/vault7/document/Angelfire-2_0-UserGuide/
BadMFS -- Developer Guide
https://wikileaks.org/vault7/document/BadMFS_Developer_Guide/ iSCSIで接続したボリューム上にRAID1組めばなんちゃってDRBD引用できるもんなの？ xfs微妙Oracleがzfsのライセンスを解放しなきゃ、透過圧縮兼ね備えてて（当然書き込めて）
ブートにも圧縮（解凍）効いて安定しててみたいなファイルシステムは
FreeBSDのしか無くなるんかいね？ APFSってmacのやつか
Linuxに組み込めるわけ無いやろ Machのコアにすり替えたFreeBSDっつーDarwinをベースに作ったMacOSXの
ファイルシステム回りの作りがどこまでLinuxに近いかで移植しやすいかどうかが決まる データの信頼性の根幹にかかわる部分が使いモノにならなかったら
MacOSX自体への信頼が揺らぎかねないし、それなりにテストした上で
社内でも実際に無理矢理鯖用途に使ってみたりとか負荷試験してはいるんじゃないかな？
シランケド、HFS Plus を改良したシロモノっぽいし、そう変な事にはならなそうな気はする
ただ、個人的には、鯖用途でもないのに重複云々とか無駄な気がしてならない
複数ユーザでchrootとかjailとかなら効果もあるだろうけど、個人の用途で重複ファイルとか
そんなに出はしないだろうし、FreeBSDのzfsでdedupした事ある奴ならわかるだろうけど
あれすんげーメモリ食う（自前で重複検出する事を考えれば、中で何してるかわかるよな？）
今時はCPUパワーあり余ってんだから透過圧縮だけでいいんだよ
CPUパワー足りないってんならNTFSみたいに compress off にすりゃいい Appleがどのオープンライセンスにするかよるけど、SSDに向けに作られた最新設計だけに期待はできるかと みんなは何をメインで使っているの？
保守的にext3とかext4なの？ 俺はNTFSとext4とufs（今となってはどれだよっていう）だけだなぁ
zfsは未だに色々と潜在的な問題抱えてそうだし、RAIDとかしないなら
オーバーヘッドでか過ぎるしdedupなんて使わないし
板に従うならzfs-fuseの話しろってんだろうけど、あれユーザランドで動いてんだぜ？
Ubuntuはモジュールだけど、まだライセンスの決着ついてないんじゃなかったっけ？
おまけにOracleは「zfsにfsckいらん」とか政治的な理由で信頼性とか検証手段とかを
犠牲にさせまくってきたし、今となっては権利持っていながらにして
もう手は下さないとかのたまってるし、色んな意味でzfsは先行き不安なんだよな・・・ zfsのdedupは１割程度しか効かなかったので結局やめたな
それはそうとオラクソ死ね >>863
システムはExt4
ストレージはBtrfs
選択的にはともかく内容的にExt4が保守的かはそこそこ疑問だな。 >>866
システムもbtrfsにしないのはどうして？ そのBtrfsも赤帽が「技術的な問題諦めてXFS行くでよ」っつって見捨てちゃったからなぁ 最近、btrfsが死んでデータ全て消えた...
Raid10だから安心なんてバカだったよ
バックアップしてないから諦めてxfsにしたよ zfsも数年前とかたまーに論理的に復旧不能とか話題出てたしなぁ
ファイルってかディレクトリのエントリしくったらそっから下が丸ごとふっ飛ぶ事になるからな
ファイルシステムだけは良く良く吟味せにゃならん >>867
Calamaresインストーラの手動パーティショニングが安定しないから。
自動インストールならExt4が選ばれる。
まぁ、システムをBtrfsにするメリットはスナップショットしかないし、するつもりは全くないけど。
>>869
どのように死んだのかわからないけど、RAID10で救出も不能だったの?
うちのBtrfsはさんざんぐっしゃぐしゃになりつつも2重運用でデータ失ったことはないけど。 >>871
kernelを4.13にあげて少したったあとにkernel panic起こして死亡したよ
カーネル上げるのってリスクでかいんだね うちはシステムはぶっ壊れてもインストールしなおしゃいいからbtrfsでデータはext4だなぁ
CPUパワーは有り余ってるのにHDDがボトルネックになってるような環境だとbtrfsで透過圧縮を有効にするとext4より結構速くなってイイ
まあSSDが普及した昨今じゃあんま意味ないけど(´・ω・`) ぼくはSSDの上で、システムもデータもbtrfsで透過圧縮にしてる(´・ω・｀)
今の所To LOVEるなし gitのファイル鯖とか、飛ばれたらくっそ面倒だから我慢してわざわざcifsで
リモートのNTFSをストレージにしてる
まじNTFS以外で透過圧縮使えて安定してる奴きぼん・・・
そうすりゃファイル鯖にgitやらMariaDBやらTFTP+nfsやら全部ぶっこんでATOM機一機潰せるのに NTFSの透過圧縮ってハフマンすら使ってないような古いフォーマットだったような >>876
古いっていうか、速い、だね
zfsもlz4とかgzip6以上にすると途端に遅くなるから、
レンジコーダーどころかハフマンなんて使えないって
RLEとかは論外だけど・・・「高圧縮アルゴリズムを採用しました！」とか言われたら逆に困る >>861
高負荷時の可用性とか、障害発生後の復旧可能性とか、
正直、あんまり注力してない
お金が絡むような用途には使わないほうが吉 ntfsは昔ファイルが壊れるバグがあって、それ以来ファイルシステムはシンプルに扱うことを心掛けている >>872
カーネルパニックとファイルシステム損傷はつながってないと思うけど…
それで不整合が起きたとしても修復すれば良いだけだし zfsは修復コマンドあるけどbtrfsにはないのかね >>881
スクショとかログとかはないけど（消えたからね）kernel panicがbtrfs関係のエラーで発生してたので関係あったのよ...
何回か復旧させたことがあるので、普通にやったが今回はお釈迦様でしたわ ちなみに4.12辺りからbtrfs関連の修正パッチとか含まれてて、4.9から一気に上げてbtrfsが何かしら壊れたかで失敗したんじゃないかな……って気がしてる >>885
こマ？
今、4.10だから4.13に上げるの怖いな RedHatが技術的問題点の解決が云々でbtrfsやめちまうから
ファイル単位でバックアップ取って他に行った方がいいんじゃないかな？
・・・いや、他の似た様なので行けそうなのないんだけどさ・・・ btrfsはもともと悪いバグの噂が絶えなかったからな 4.12からbtrfsのraid5/6がほぼ使い物になるって言うから上げたら結果的に失敗しちゃった >>884
いや、btrfsモジュールでカーネルパニックしたとしても、ファイルシステムは通常の不整合以上には壊れないでしょう?
というか、現状btrfsモジュールは毒データ与えてもストールするので、カーネルパニックになったならMLで言って欲しかった感…
(ディスクが壊れた場合はカーネルパニックになることが確認されてるけど)
現時点でディスク不良以外でraid1で実損したデータ以外が救出できなくなるケースも確認されているものがほとんどないので、
それもやっぱりMLに投げてほしかった…
なお、4.12のパッチは小規模というか大した変更じゃなかったよ。4.13も小さい。
変更がとても大きかったのは4.11だね。 https://twitter.com/Nonapeptide/status/919277335647371264
> BTRFS - perfectly named because your data is toast. #sysadmin #devops #linux
バロスｗｗｗ >>890
うーん…割とあることなのかと思ってたけど、レアケースだったのね
大変失礼いたしました
あと4.11でしたか >>890
btrfsは技術的問題点残ってるって赤帽も言ってる >>895
いや、balanceできない条件があるとか、
raid5/6の実装が間違ってるとか、
一部コードが汚い上に間違ってるとか、
そりゃ技術的問題はあるけど、だからといってそれ以外の箇所で障害が起こるということにはならないよ。
そんな挙動を示したなら、bugzillaに書くか、エビデンスつきでMLに投げるかしてよ。 >>897
それでもダメだったって報告だとか、噂が絶えなかったってのはガン無視？
大体ファイルシステムの障害とかすんごく報告し辛いよ
btrfsの新しいバージョンが本当に完全に上位互換になれるのか、
HDDかSSDか、セクタorブロックが代替されててデータ失って再現不能なのか、
ECC側のデータ化けをリトライでたまたま合う間違ったデータでリードできた後に代替されかどうか、
報告するにも検証どころか調査が面倒で、腰を据えるだけの気力と勇気が居る
てかその障害が起こったパーティションそのままに、他のパーティションのシステムから
観測し続けにゃならんのだよな・・・面倒どころの話じゃない btrfsかハードウェアの問題かすら切り分けできてないけどbtrfsの問題だと言い張るバカという自白 だからML投げたらその切り分けしろとか言われるだろ なんで頻繁にクラッシュニュースが流れるbtrfsなんて使ってんの？
直った直った詐欺の常習犯じゃん
CentOSのワークステーションで２年位アップデートしながらzfs使ってるけど１度も壊れたことないよ
悪い噂のないzfsを使おう！ >>902
windows上でzfs動かした勇者がいるとか
zfsは安心感はんぱないけど速度は遅いんよね 窓zfsは猛者すぎる
HDDでRAIDZ2だけど安物HDDノートよりは快適に使えてるよ
２年以上窓vmつっこんで定住できる程度には
自動スナップショットにもお世話になりっぱなしだしロールバックもバックアップもレストアも全然失敗しないしもう最高 RAID10しか使わない俺はZFSが重いと思ったことがない >>898
なるほど...XeonE5v2の2CPU環境なのにnon-ECCというクソ環境なのももしかしたら関係あったのかも...
次買い換えるときはECCにするよ 10年越しのC2Dのわいはzfs重すぎで断念したで なんだか病的だなここ
民生のポンコツNASのファームでも開発してるのかお前ら Btrfsをたたくとかっこいいとか思っているんだろうか
それともRedHatの言葉はすべて福音だとか思ってるんだろうか
そして、RHELが採用をやめただけでBtrfsの開発からRedHatが手を引いたとでも思ってるんだろうか あれだけ不具合出してたbtrfsにさも問題がないかの様な言い回ししてるキモオタが煽ってるからだろ
あそこまでもぐら叩きだと基本設計に問題があるとしか思えん
FATで例えるとCRCorECCを別のセクタにしただけで滅茶苦茶複雑になるんだぞ
しかも今時はSSDも絡んでくるからHDDと違ってブロックのイレース直後の電源断も考慮せにゃならん >>910
いや、問題があるならBuzillaに書くなり、MLに投げるなりすればいいでしょ。
Issueが直ってないからチケット確認しなよ。
困ってるなら、どういう状況で何が起きるか投げれば対応するわけだし。
使ってもいません、具体的に何が発生するとも言えませんってそれはただのFUDでしょ https://www.youtube.com/watch?v=6muZNaTq2tQ
#kernelvm @naota344 バージョン別BtrFSのころしかた
バグ見つけたらここまで検証して特定するまで誰にも言うな掲示板にも書くなってか？
検証用にパーティション切ってファイル放り込んで問題絞り込んでとかどんだけ時間掛かると思ってんだ >>912
いや、バグ見つけたならMLで言うなりBugizllaに書くなりしなよ。
で、あなたの環境でどういう状況で何が起きたの?具体的に教えて? >>906
メモリのECCとファイルシステムアクセスは、ほとんど関係ない。
あるとすれば、ダーティキャッシュがビット劣化して書き出したときにファイルがビット破損するケースだけれども、
これはファイルシステムとは*全く*関係がない事象。
btrfsやzfsの場合は、入出力のたびにチェックサム照合を行うので、RAID化されていればビット腐敗が発生していた場合、
自動的に修復される。
ただし、詳細は省くけれど、別にこれはscrubしなくていいということを意味しない。
ディスク故障時のような「安定した応答が得られない」ケースを除き、
基本的にデータビット破損によってRAID化されたbtrfsあるいはzfs、またはミラー化されたLVMからデータが損なわれるという事態は原理的に起き得ない。 >>913
btrfs-progsアプデされた後にUUID云々とかエラー吐かれた時点でシステム入れ直したわ
そのパーティションを検証の為に残して他のHDD用意してそっちのシステムから検証とか
義務でも何でもないのにやるかよ
（zfsも初期はアプデでトラブル云々あちこちであったみたいだからbtrfsに限った事じゃないだろうけど）
てかバグ見つけたら必ずMLとかにあげなきゃならんのかよ？
MLに上げない奴は不安定なファイルシステムについても何も言うなってか？ >>915
btrfs-progs「だけ」上げたの?だとしたら、ファイルシステム自体は何も変更されてないからファイルシステムはおかしくなるはずがないね。
ほかもあげたなら、btrfsのせいだという根拠が必要だね。
別にこの状況でこんなエラーが出たよ、というだけだから別のHDD云々は何も関係ないね。
具体的にどのようなエラーが出たのか、そしてどのような挙動を示したのかについても述べられてないけど。
別に不具合があっても黙って使い続けるのは自由だし、困るから直してって報告するのも自由だよ。
ただし、根拠も示さず証明もせずにFUDをばらまくのは下品だと思うよ。もちろん、下品に生きるのも自由だけども。
でも、わざわざ人に向かってFUDを吐いてつっかかるのは自由の範疇じゃないからね。 >>916
「だけ」な訳ないだろ
しかも
https://www.youtube.com/watch?v=6muZNaTq2tQ
#kernelvm @naota344 バージョン別BtrFSのころしかた
>>902も言ってるし
これでFUD云々だとかバカ呼ばわりだとか、印象操作してるbtrfs信者の方が頭おかしい btrfs信者はファイルシステムはわかっても自分がセルフネガキャンしてることはわからないの？
まさしくキモオタだな こういう様子を見たら、使いたいとは思わないよな
未完成なのはRHらも認めているのに、不具合があるという報告から
原因を探ろうとかそういうのではなく、不具合ではなく使う側が悪いと強硬に言い張るんだから
普通の人は、「安全で良いファイルシステムを使いたい」のであって「btrfsを良いものにしたい」なんて思ってないんだから
原因究明してMLで報告しろとか大笑いだよ まともな人間は使って幸せになれるから使うのであって
トラブルに巻き込まれた挙句キモオタがよってきて奇声を上げる製品なんて使うわけがない
どんな罰ゲームだよ CentOS7でBtrfsでインストールしなくて本当に良かったわ ext4で特に問題なくね
ext4でだめな人はxfs使ってるでしょ >>924
求めるものによってマチマチかと
ただデータをファイルとして読み書きしたいというだけなら
FATやext2なんかを参考にすれば作れるだろうし、
セキュリティや可用性を求め始めると難しくなるし Fuseはいろんなfs作ってる人がいて面白いよね
まともに使い物になって、さらにメンテまでされてるものはごく僅かだけど
設計と長期的な開発の大事さが伝わってくる FAT → エントリを２つ持って、データを書いた後２か所を更新するだけ
書き込み中の最悪のタイミングでの電源断 ： お察しください
ジャーナリング＋CRCかECCの類の更新
エントリ＋データからCRCの類までジャーナリング？二重の書き込みに加えて
他のセクタ（クラスタ）のCRCの類を読んで、該当するCRCの類だけ更新して、
それを更にジャーナルに書き込む？
新規データは空きクラスタに書き込むだけでいいけど、既存ファイルの一部の更新だった場合は
クラスタのチェーンも読み込んで、更新する箇所だけ空きクラスタに書き込んでおいてから
チェーンの部分を読んで該当箇所だけ書き換えてそれもジャーナルに書き込む？
そこまですればDB並に保護は完璧だけどめっちゃパフォーマンス落ちるし
空き容量０の時の既存ファイルの更新は？とかとか考え出したら常人にはとてもじゃないけど
zfsみたいなファイルシステムなんて設計し切れるもんじゃないし、
代替案も出さないのに文句言う奴が必ず出てくる事請け合い無し
SSDの場合はブロックイレースの直後に電源断だと軒並みデータ０になるし
どうせアプリ類の書き込み中の電源断は何かしらファイル壊れる筈だから
どっかで妥協するしかないんだよな 現在HDD(4TB)2台にそれぞれ「pool1」「pool2」の2つのzpoolを作製しています。
今度8TBのHDDを購入するため、「pool1」「pool2」の2つのzpoolを、
1つのHDDにまとめたいのですが可能でしょうか。
やはりパーティションで4TB領域2つに分けるか、
「zpool3」のようなzpoolを1つ作って
「zpool3/zpool1」「zpool3/zpool2」のようにzfsで分けるしかないでしょうか。 スナップショットを統合するのは無理だろうからファイルコピーかネームスペースを切るしかないやろな 1つのプールのルートに複数のプールをマージはできんやろ https://twitter.com/satoru_takeuchi/status/929134436364333056
sat @satoru_takeuchi
fsckは映らないテレビをどつくとかファミコンのカセットに「フーッ！」ってやるくらいのもんだと受け止めていただければいいかと思います
例えが古いですか、そうですか
8:51 - 2017年11月11日
https://twitter.com/satoru_takeuchi/status/929138273791832066
sat @satoru_takeuchi
fsckはブッ壊れたメタデータを容赦なく捨てることによってなんとかマウントできたら嬉しいですね、くらいのツールなので、
成功したからといって全てのファイルが残っているわけでもなければ整合性が保証されているわけでも無いです。ジャーナルログのリプレイなんかとは全然違うものです
9:06 - 2017年11月11日
https://twitter.com/satoru_takeuchi/status/929139286196207616
sat @satoru_takeuchi
なのでバックアップとってない人が一縷の望みをかけて使うものであって、バックアップをちゃんととってる業務サーバのファイルシステムがマウントできなくなったときに
「fsckしたらマウントできた！やったね、業務継続！」とかやるのはまずい。ちゃんとバックアップからリストアしましょう
9:10 - 2017年11月11日
https://twitter.com/_hito_/status/929156966584262656
hito @_hito_
fsckが-y与えてない状態でなんか確認出してきたら、「これ、ておいけど目をつぶる？」って確認されてるんだと思ってください。
10:20 - 2017年11月11日
https://twitter.com/_hito_/status/929157667817263104
hito @_hito_
-y与えたfsckなんて、Twitterのタイムラインぐらいのておさは平気だぜって覚悟完了した状態を示すものなんやで。
10:23 - 2017年11月11日 ジャーナリングを嫌ってるGoogleとかノードが立ち上がるたびにmkfsしてそうだよな btrfsでzstd使えるようになってたんだな
IO速度がクソな環境では有用そう Btrfs Zstd Compression Benchmarks On Linux 4.14
https://www.phoronix.com/scan.php?page=article&;item=btrfs-zstd-compress&num=1
わりとマッハっぽいな
安定してるのが確認できたら試したい zstandardを開発したのlz4の人なんだな
天才か suseとかでデフォルトzstd圧縮有効になったりしないかな exfatを古いandroidに指したらぶっ壊れたんだけど復旧方法ある？
teatdiskのクイックスキャンはダメだった
これからディープスキャン予定 >>943
復旧方法というかそれ以前の事前確認なんですが、カードリーダーの方が
壊れてないか確認(別のmicroSD挿してみる)して、その後は microSD のハード
不良なのかFSのメタデータ破損なのかを確認(dd で読み出せるかあたりか？)かな。 943っす
ディープスキャンダメだった
カードリーダーは複数使ってチェックしてるからハードのエラーではないっす
xxd -a /dev/sdcして何か出てくるので何か入ってるぽいんだけどexfatの構造はよくわからない
sudo fsck.exfat /dev/sdc1
exfatfsck 1.2.3
ERROR: exFAT file system is not found.
いわれるんだよねー。最近のFSだからメタデータのコピーくらいはあるとは思うんだけど
おそらく原因はこれ
ドコモからのお知らせmicroSDXCカードご利用時のご注意について
https://www.nttdocomo.co.jp/info/notice/page/120606_00.html
いやまさか指しただけでフォーマット実行なしで壊れるとは予想外だったわ。どんな処理してるんだか https://github.com/tex/fusecompress
LZOLayerFSもfuseCOMPdもメンテされてなさすぎてアレだし、
これもProbremとか妙にきな臭いし・・・
NTFS程度の圧縮でいいから、zfs動かすにはメモリが足りないって環境で
透過圧縮でいい方法ってないもんかね？ ここまでバグまみれで一向に改善の傾向が見られないのは設計に何か問題でもあるのかねぇ Deprecatedにぶっこまれるって事はそういう事なんでしょ レス数が950を超えています。1000を超えると書き込みができなくなります。
