ファイルシステム総合スレ その17 [転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
>>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にぶっこまれるって事はそういう事なんでしょ ext4に透過圧縮があれば十分なんだがなあ
以前は/usr以下をsquashfsしてaufs被せる荒業が使えたんだがsystemdが起動に必要なファイル置きやがるからだめになったし 圧縮機能だけでzfs-fuseを使っていたんだけど、（CentOS 6）
さっきダウンしていた。マウント先ディレクトリにアクセスできなくなっていた。
service zfs-fuse restart を時間を置いて二度行なったら、復帰した。
/var/log/message を確認したら、エラーが記録されていた。
segfault at 70 ip xxxxxxx sp yyyyyyy error 4 in libpthread-2.12.so[zzzzzz]
もう怖くて、zfs-fuse使えない。
重複機能はとっくに諦めていたけど、圧縮機能も諦めて、
もうzfs-fuse使わない。ext4のまま使うことにする。
圧縮効果は1.6倍だったのでもったいないけど、安全の方が大事。 >>953自己レス
メールのINBOXフォルダとして使っていたので、
大量に入ってくるメールの取扱でバグったのかなあ。 評判の悪いfuseなんぞわざわざ使ってる方に問題がある
ZoL使え >>955
ZFS on Linux ググってみたけど、標準の機能でないために躊躇します。
yum update みたいに、カーネルごとアップデートされるようになったら使いたいなあ。 fuseのzfsも標準の機能じゃないしｗ
てかOracleもFSFもLinux界隈もPC衰退期の現状にライセンスが合ってない
もうソースに手入れた人が把握できなくて身動き取れないだけかも知れんけど >>956
ZOLが標準に組み込まれないのはライセンスの問題
FUSEはZOLまでの繋ぎで今はメンテもされていない 事実上、まともな透過圧縮は起動に使うには面倒なZOLだけか
透過圧縮って、パフォーマンス低下させない様にって細工が面倒なのはわかるんだけど
ext4で特定の圧縮アルゴリズムで標準化みたいな動き、出ないもんかな >>960
btrfsってもう詰んだんでしょ。
>>958
永久にカーネルに組み込まれないってことでしょうか。
それともオリンピックまでになんとかなる話？
なんとかしてほしい。ド素人にも使えるようにしてほしい。
ZFS on Linuxなんてつかったら、多分、カーネルアップデートしたりしたときに、
データにアクセス不能にしてしまいそうでこわい。
凍結的に使いつづけるのならよいのかも知れないけど。 red hatが作るXFSベースのfsに透過圧縮付いたりしたら良いのにね 正直、圧縮はbtrfsだのzfsだのでなく、ストレージに提供させる機能とした方がよさそうだが >>961
特定のFSに限らんだろうが暗号化ディスクをマウントしたままカーネルアップデートするとディスク構成壊れて起動不能というのはある >>965
ブロックレイヤーでってことか？
メタやジャーナルまで圧縮することになるし
FS側で圧縮した方が良さそうじゃない？
俺は使ってないファイルとか圧縮効果の高いファイルだけ圧縮して欲しいわ 起動時のえっらい小さなローダーがパスワード入力とか求めた上で
暗号化解除やら、場合によっては圧縮の解凍しながらとか、相当難しいからね
FreeBSDでも/boot/だけは圧縮とかすらできない様に、あちこちにブロック入ってる
（抜け道があったりで完全じゃないけど（それ言い出したら何でもできるけど）） >>967
ちょいと考えてみたけど、ブロックレベルでってのは、特にSSDで無理があるな
透過圧縮の類って、実際の圧縮は確か16KB単位とかでやってる筈
頻度表を扱うアルゴリズムを使うってなった時点で、最悪値で無条件に
256×出現回数の表現に必要なビット数 の頻度の情報が必要になるから
4KB単位での圧縮なんて（テキストファイル限定とかでもなきゃ）先ず意味がない >>967
>>969
内蔵HDDとかというよりかは、FCとかiSCSIとかで接続するような外部ストレージね
OSからは4kbのブロックとして見えるけど、実態はストレージによりそう見せられている
仮想的なブロックの、更に下位のレイヤーでの圧縮や展開
ストレージ内蔵のASICや専用アクセラレータが圧縮や展開をするようなモノ レス数が950を超えています。1000を超えると書き込みができなくなります。
