ファイルシステム総合スレ その18
■ このスレッドは過去ログ倉庫に格納されています
>>483
ストレージなんて導入後１年とか経過したら急激にパフォーマンスが悪化したみたいな話は少なくないわけで。
データ置くんだから色々なハード×運用アプリ×負荷条件×期間で運用して実績積んだ上じゃないと安心
なんてとても言えないんじゃ。 オラク●って、会社が関係すると残念なイメージ。
Solaris ヨロなんだけど。 Btrfs は RAID1 にサイズの異なるディスクを追加してどうヤリクリしてくるか眺めるFS メタな話だけどなんでこのスレ犬板にあんの？ム板とかじゃなくて。 Linuxはファイルシステムの選択肢が多いから、どのファイルシステムを使うのがベストなのかを語るスレだからじゃないの？
ファイルシステムの実装について語るスレだったらプログラム板にあってもおかしくないかもしれないが、
そんなコアな人は5chじゃなくて各OSSファイルシステムのMLとかでやりとりしてるんじゃないの。
自分でコードを書く人向けなのがプログラム板で、ソフトウェアをユーザーとして使う人向けなのがそれ以外の板だと思うけどね。
じゃなきゃハード関係の話題以外はなんでもかんでもプログラム板ってことになっちゃうでしょう。 >>496
言われてみればそうだな。
確かに多くの種類のファイルシステムを「使う」のはLinuxやBSDユーザーだな。
そしてその実装は5chで議論することじゃないな。
俺がバカでしたw btrfsが問題あるっぽいのはわかる。わかるんだけど、サブボリュームとか便利すぎて乗り換えれない。長らく使っててクラッシュしたの一回だけだし、性能もソコソコだし、バックアップ気軽に取れるし >>498
そのファイルシステム
静かに壊れているかもしれないぞ？
試しにbtrfsckをして確認してみた方がいい btrfs は静かに壊れるという経験はないなあ。
壊れるときはあっという間にエラーログ吐きまくって盛大にぶっ壊れる。
btrfsの唯一(?)凄いのところは、ぶっ壊れても頑張れば相当サルベージできるところ。
面倒くさいからバックアップから復旧するけど。 >>499
btrfs check やってみたよ！
問題なかった
zfsは遅いイメージがあるのとライセンス的に…… 個人的にはzfsは速度より古いPCを再利用しようとした時にメモリを食うのがネック過ぎる
削りに削ったFreeBSDですらdedupしてないのに2Gでもきつい そんなカスみたいな環境で使うことは想定してないしな appleがzfsを採用しなかったのは暗号化に対応していなかったからだぞ
ZoLは最近になって暗号化に対応したけどな /dev/sdc に刺さったPVから作られたLVMがあるんだけど、このディスクを /dev/sdb に
繋ぎ変えたいんだけど、繋ぎ変えるだけでそのまま使えますか？
何か作業が必要？ >>508
lvm.conf で vgscan で除外するデバイス一覧に /dev/sdb が入ってなければOK。
lvm.conf を修正したなら initramfs 再作成もお忘れなく。 昔特に考えもなく/bootを除いたOS丸ごとZFSにしてたのを
OS更新に伴って見直そうと思うんだけど
とりあえずメインで使うのは引き続きZFSにして
/boot←fat32(esp)
/tmp←ext4
くらいしか思い付かないんだけど他に良い案とかないかな？ もう何年もずっとtmpにはtmpfsを使っている…もちろん推奨などしない /boot ext4
/boot/efi fat32
にするものらしい bootはxfsにすると高速起動するよ
地味な変更だけど効果は大きいからオススメ >>513
それちょっと良いかも。検討してみるよ
>>515-516
/boot xfs
/boot/efi fat32
で試してみるよ。出来ることなら高速起動の方が良いもんね
>>514
特にオススメが無いor迷ったらZFSにするくらいの意味で捉えて頂ければ メモリが潤沢な環境で/tmpの下のいくつかのディレクトリをtmpfsにするのは有意だけど
/tmp全体をtmpfsにするのはtmpfsのドキュメントで禁忌にされてるので、やるならまあown riskで むしろ最近のディストロは/tmpまるまるtmpfsが割と普通な気が
その禁忌って書いてあるドキュメントって読んでみたいんだけどどれ？ Fedoraがやってるんだから問題ない
とりあえず迷ったらFedoraがどうしてるか見るのがいい
全ての設定はFedoraから流れていく Fedoraは先進的で実験的らしいから実装一発目の機能とかは怖いイメージ((((；゜Д゜))) /tmpは普通にtmpfsだろ
/var/tmpは違うけど Fedoraに限らずsystemdのデフォルトで/tmpはtmpfsだろ
で、/tmpをtmpfsにするのは禁忌なんて書いてるtmpfsのドキュメントってどこにあんの？
kernel付属ドキュメントでも禁止なんかしてねえけど
https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt RHEL7 は systemd だけど tmpfs ではないな。 (Fedora は人柱？)
例えばメモリ 192GB 搭載のサーバで /tmp に tmpfs 使ってる場合、OS、サービス、
仮想マシン等で190GBメモリを使ってたら、/tmp に書き込める量って2GBだけで
それ以降はスワップアウトって事だよね？
なんか心許ないなぁ。 tmpfsに書き込むデータよりも先に他のデータがスワップアウトされるけどな 前提条件がおかしいわな
空きメモリが10%以下の状態とかtmpfs関係なくメモリ不足 個人利用で仮想マシン動かしつつ動画編集もやりたいって場合でも
メモリ64GBあれば平気そうかな
今メモリ安いからちょっと奮発すればいける >>527
解析用途の場合は10%以下でも特にメモリ不足って感じはしないなぁ。 /tmpの容量が気になるほどの巨大ファイルを置くような使い方、する？ >>530
解析用途であらかじめ使うのがわかってる場合は /tmp 以外に NVMe とかで別途高速なデバイス用意する。
しかしミスって /tmp に書くバカもいる。 なんでそんな特定状況で対処もわかってる話でtmpfs使うとか言い出すん？ .oO(いまさら禁忌は /tmp じゃなくて /var/tmp だった…なんて言えそうにない雰囲気だな) >>532
RHEL7 では /tmp が tmpfs ではない話の中で、なぜ tmpfs を使わないかの理由について
候補を挙げてるだけで、tmpfs 使っちゃダメって言ってる人とは別の人です。 /var/tmpは再起動してもデータが残っていないと駄目だからtmpfsが禁止なんて当然だよな インチキなブログのtipsだと/var/logもtmpfs指定したfstab晒してたりして舌がﾚﾛﾚﾛってなる まあ昔のSSDだとlogもtmpfsに突っ込みたくなる気持ちは分からなくもない まあデメリットとかわかった上で自分がやる分には全然いいと思うけど人に進めるもんじゃないってのはあるね bcachefsがカーネルにマージされたら即座に導入するわ
ファイル名長が緩和されるのが素晴らしい
現状だとWindowsで解凍可能なファイルがLinuxではファイル名長の関係で
ひと工夫しないと解凍不可能だったりして不便すぎる >>539
例えば？
正直ファイルシステムの出来はともかく
ファイル名に関してはext4とかの方が柔軟な気がするんだけど。 例えばも何もファイル名長って書いてあるやん
そのあたりの諸元でLinux系fsの大半に問題が出るのは常識だと思ってたけど LVMで確保されたストレージのサイズ変更を
久しぶりにやってみた。lvextendでLVの
サイズを変更して、xfs_growfsでユーザから
見える空き容量を増やす簡単なお仕事だが、
何度やってもドキドキしちゃうな。 >>539
こんなの作られてたのか
btrfsはダメみたいだしZOLは導入めんどくさいから
出来が良いといいんだけどなぁ >>542
拡張ならまだよい。
縮小するお仕事は、大変だよ？ >>545
それでファイルシステム破壊したことあるw
家のサブ機だったから自己責任だったけど
あれ全く縮小の準備が整ってなくても何の警告もなしに実行するんだね。
少なくとも2016年では。 >>546
おれもルートファイルシステムを縮小しようとして、起動しなくなったことがある。
バックアップから戻した。以後試してない。 bcachefsの開発者ってpatronで資金提供者集めてるんだな 大口スポンサーの要求が参照リンクの実装だったらしく
今急ピッチで実装しているみたいだな これが実現するとbtrfsやxfsのような形式での重複排除も可能になる なんでbcacheなんか拡張することにしたのか疑問だったけど
このKent Overstreetって人がbcache本体の作者でもあったのか
ずっとfacebookがやってるやつとごっちゃになってたわ bcacheの作者がbcachefsの作成に移行した影響で
大元のbcache自体が全然更新されていないという状況になってる
オープンソースって実際には1人抜けたら立ち行かないようなプロジェクトばかりよね bcashefsのベースになってるから下手に弄れなくなったんだろ
あるある過ぎて笑えんけど ext4に続いてF2FSも大文字小文字を区別しないようにするオプションが作られているらしい どこ読んでるかわかんないけど、コメントちゃんとあるように見えるけど 寄付なんて殆どが直接募集した奴が何割吸い取るかもわからない詐欺みたいなもんだぞ Linux上のZFSはLinux 5.0以降でSIMDサポートを復元する方法を考え出しました
https://www.phoronix.com/scan.php?page=news_item&;px=ZFS-On-Linux-Restoring-SIMD
近いうちに、新しいZFS On Linuxベンチマークを出すようにします。 >>561
chromeで自動翻訳してくれるからそのまま貼った。 >>454
Ext2Fsdをインストールしてるとリムーバブルメディアを取り外せなくなるからアンインストールした
>>459
ファイルを更新した直後に青画面や停電などでクラッシュすると
次回起動時に該当ファイルが0で埋められる挙動があってデータを失ったことがある
ソフトはバックアップを作ってから更新するタイプだったがご丁寧にもバックアップまで0で埋められた >>440 >>445
bcachefsは知らんが
bcacheは安定性に難あり
条件を満たすとカーネルがメモリやスタックの汚染を報告して十数分後から数時間後にシステムが確実にクラッシュする
多数ある条件を回避していって最近になってようやく安定稼働に持ち込めた xfsも一時期酷かったけど今は高評価だし、直ってれば何でもええよ 何かを利用するって事は、その下側の使ってる部分の品質を上回れない事でもあるからなぁ
安定したばっかのを使うってのは（ｒｙ そういうのを使ってあーでもないこーでもないと情報を交換したりバグを報告するのがOSSユーザーの嗜みであり楽しみでは？ 今まで何もわからずUFA使ってたけど新NAS作ろうとして調べれば調べるほどファイルシステムが選べないわ
どれも一長一短あるしまるでリーマン予想を解いているみたいだ windowsから読み書きできない時点で、
XFSのせいではないが、候補から外したくなる 緊急時、データだけでも確保したいときのことを考えちゃうんだよ
XFSって、プラットフォームによってはLinuxからでも読めないことあるしなぁ
市販のNASで一度懲りたわ そんなこと言い出したらNTFS最強って話になってくるし windows関係ないけど、xfsの何がという話をしないから
信心深いのかな？くらいにしか思わない
自分ならext4で無難かな >>577
RHEL7 のファイルシステムサイズの上限が ext4 は 50TB、xfs が 500TB。
2U サイズのラックマウントサーバだと 3.5インチHDDが12本は載るからext4
だと１パーティションに収まらないのよね。
上限は RHEL6 の時は 16TB だったからその頃から xfs を選択せざるを
得なくなった人が多い。
RHEL7 以降デフォルトが xfs になってるから不具合も一番潰されてるだろう
から、一番安心して使える。
何を以て安心っていうかというと、どれだけ多くのディスク/RAID装置で、
どれだけ多くの故障パターンを経験して来たかだと思ってる。
なので普及率はバカにできない。
>>574
カーネルを新しくするか逆に古くする、マウントオプション色々試す、はやった？ >>565
仮想マシンのゲストのWindows(10とXP)がクラッシュしたときも再現したのでNTFS実装の挙動で間違いない
俺はそれを見たとき対策を諦めた 同じNTFSでも2000ではファイルを閉じるときに必ず物理書き込みする挙動があって
クラッシュしたときにファイルが壊れる経験は皆無だった XFSの噂はよく聞くが、どのベンチマークでもメタデータ更新系の成績がかなり悪い点は気になっている
細かいファイルをよく扱うLinuxとは相性悪いんじゃないだろうか？ 複数のファイルの遅延書き込みを溜め込みつつ、特定のファイルのフラッシュが必要になったら
確実にそのファイルへの変更結果をファイルシステムに矛盾が発生しない順序で
即座に物理層に反映・・・って、実は思ってる以上に複雑
その辺りは資本の力で開発されたファイルシステムに軍配が上がる >その辺りは資本の力で開発されたファイルシステムに軍配が上がる
んなこたーない、ntfs厨はもうこないでほしい 上にもあるが現在は正解がないというのが真実な気がする
正解がないので各派閥が宗教のように自分が使っているFSだけを信じ続けている
デジタルなのにやってることは人類が太古から続けているアナログ的な宗教に行き着くというのが感慨深い 商用のファイルシステム以外はzfsとextの中間に位置する様なシロモノがないからな
その辺りにbtrfsが位置する予定だったんだろうけど、蓋を開けてみたらアレだったしな >>578
ARMアーキテクチャのNASで使われているXFSは、
x86アーキテクチャのマシンからは、
エンディアンの違いで読めないことがあったんだよ。
（知ってたらゴメンね）
読む方法はある（シェアウェア）らしいし、
最近はバグらしきもの（FSかドライバか）が取れたらしいけど。
>>580
Linux物理マシンをext3で使ってたとき、
sync コマンドと、ALT＋SysRq＋s はなんか習慣的に押してたなw
まぁ、気休め程度にしかならんだろうけど。 ■ このスレッドは過去ログ倉庫に格納されています
