[過去ログ] ファイルシステム総合スレ その18 (1002レス)
上下前次1-新
このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
353: 2019/03/07(木)02:54 ID:6s6dEvVm(1) AAS
ようやく時代がreiser4に追いつくか?
354: 2019/03/07(木)09:33 ID:MuV+t1Gm(1) AAS
今はbcachefsのほうが期待されてるだろう
355: 2019/03/11(月)00:35 ID:UOCKT9C0(1) AAS
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やってもダメなので
省4
356: 2019/03/11(月)00:40 ID:IigLLh3C(1) AAS
btrfsはトラブるたんびにモグラ叩き、の繰り返しだったろうに何故に実運用しようとするのか
357: 2019/03/11(月)00:52 ID:5TJmB3dg(1) AAS
video encodingかw
エンコ厨のアニヲタは氏ねばいいよw
358: 2019/03/11(月)03:25 ID:Iugc1R92(1) AAS
btrfsは失敗だもう捨てろ
359: 2019/03/11(月)03:39 ID:obZ/zwS+(1) AAS
btrfsのスナップショットは作る分にはいいけど…
360: 2019/03/11(月)10:13 ID:nc+22c0z(1) AAS
もうNILFS2は誰も見てくれないのかなあ。
結構好きで/homeに使っているのだけれど。。。
361(1): 2019/03/11(月)23:14 ID:SU9pN+Q4(1) AAS
どんなメリットがあって使っているの
362: 2019/03/12(火)20:49 ID:yL9gOqQR(1) AAS
>361
Logファイルシステムなんでファイル操作ごとにチェックポイントができるから保存されている限り任意の時点のファイルシステムの状態が復元できるんで、
あ、消しちゃったとか、間違えて書き換えちゃった時にすぐ取り返せる。
ルートで対象のチェックポイントをスナップショットに変更してマウントする作業する必要があるけど。。。
ファイルシステム止めずにスナップショットが得られるので他の作業しながらコンシステンシー気にせずにバックアップが取れる。
書き込み量とストレージのサイズによるけどデフォで1時間で設定で24時間位は遡れるようにしているので割と気軽にファイル操作している。
とは言っても実際にファイル取り返さないといけないケースは1年に数回程度だけど。
363(5): 2019/03/16(土)17:38 ID:RacPXVIy(1/5) AAS
このディスクのファイルシステム何かわかる人いませんか・・・・・・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
省15
364: 363 2019/03/16(土)17:50 ID:RacPXVIy(2/5) AAS
あ、ディスク自体はパナのVIERAに外付けHDDとして接続してたTV録画HDDです。
HDD自体はsmartやら、ddやらの読出し結果からは異常はないっぽくて、
どうも中のファイルシステムがおかしくなってるっぽいなんとか復旧したく。
各パーテション、CodeがFFFFでファイルシステムが何かわかりません。
fileの結果からは、/tmp/mntとなってるので、UNIX系の何かだとは思うんですが・・・・
365(1): 2019/03/16(土)18:42 ID:QAw47Obs(1) AAS
レコーダで初期化したHDDは独自のファイルシステムになってるもんじゃないの?
そうでないと録画データの引っこ抜きとかが容易になるわけで。
366: 2019/03/16(土)19:11 ID:FKDx4ojb(1) AAS
> Unix Fast File system [v2] (big-endian)
これが「UFS2」にしか見えなくて、
まずこれをやって
外部リンク:www.google.com
次にこれをやってみて
外部リンク:www.google.com
なんとなく
>>365
そんなことしてたら、コストに見合わない
安定性やバグ取りにサポートまで必要なことに手を出すほど、メーカーはヒマじゃない
省1
367: 363 2019/03/16(土)21:15 ID:RacPXVIy(3/5) AAS
AA省
368: 363 2019/03/16(土)22:17 ID:RacPXVIy(4/5) AAS
てきとうにやってたら━(゚∀゚)━DB構造見えてきたー
外部リンク:imgur.com
このDBはプリセットっぽいけど一応データを見ておこう・・・・・・
????TVよりはるか昔のなにやら不穏な文字列がががが・・・・・・
パナに怒られても嫌なのであれなところは黒塗りで・・・・・・・・
外部リンク:imgur.com
ということで全力でDBデータ吸い出し中。
369: 2019/03/16(土)22:54 ID:RacPXVIy(5/5) AAS
TV録画HDDまるごとddイメージ用の2TB、
TV録画HDDのパーテションごとddイメージ2用のTB、
パーテションごとddイメージの一応swabイメージ用の2TB、
DB吸い出し用の2TB。空き容量ガー。
今日はもうddでHDDコピーしながらDB吸い出し仕掛けて寝ることにしま・・・・
もし同じような境遇でデータ救えた人がいればアドバイスいただきたく・・・
370: 2019/03/18(月)19:49 ID:Vfq3Yari(1/2) AAS
デコードできるのそれ?
371: 2019/03/18(月)20:09 ID:23E+fOK/(1) AAS
録画データ壊れてて読み込んだ時点で死んでるとかじゃなければDB修復したら元のTVで見れるでしょ
372: 2019/03/18(月)21:24 ID:Vfq3Yari(2/2) AAS
あ、そゆことね
373: 363 2019/03/21(木)01:42 ID:/l10lWhU(1/2) AAS
はい。結局マウントかけずにフアイルを読み出すツールだと、情報が断片的にしか読めずDB復旧にはいたりませんでした!あと、ddの完コピディスクも予定通りダメなとこまでコピーされてだめ!南無!
374: 363 2019/03/21(木)01:45 ID:/l10lWhU(2/2) AAS
結局、gpartのFFFFコードの小細工を突破して、正攻法でマウントして読み込んでffckなりするしかなさそうですが、これはうちのスキルではむりんご。
375(1): 2019/04/09(火)13:17 ID:1OOoyLh/(1) AAS
【速報】削除後、起動しているだけでデータが復元できなくなるという性質がLinuxのファイルシステムに存在することが判明
外部リンク:cloud.watch.impress.co.jp
>Windowsでは、1回削除してもファイルシステム上にはフォルダ構成が残っているのですが、
>Linuxに関しては、削除後はしばらくそのままにしているだけでどんどん消えていきます。
>起動しているだけでデータが消えるという性質がLinuxのファイルシステムにはあります。
376: 2019/04/09(火)13:22 ID:lhCkt0bg(1) AAS
ファイルシステム名すら書かずに
377(1): 2019/04/09(火)13:39 ID:izrDON32(1) AAS
セキュリティ的にはそのほうがいいんじゃない?
378: 2019/04/09(火)13:41 ID:xKrw21om(1) AAS
>>375
Linuxでは削除したデータの復活が難しいって話でしょ?
データが勝手に消えるという意味ではないぞ
379: 2019/04/09(火)14:45 ID:MWJmYr9/(1) AAS
ファイルシステムの仕様の話でバグでもなんでもないよな
それにファイルシステム上から完全に削除したファイルの復元なんてWindowsにしろLinuxにしろ保証なんてしてないし
380: 2019/04/10(水)11:00 ID:4T4hCHHJ(1) AAS
ext4との比較かな
そんな性質あるのか?ssdの場合か?
381: 2019/04/10(水)11:51 ID:sqoFbBjM(1) AAS
ext4は結構戻せるからxfsのことでないかな
382: 2019/04/11(木)07:56 ID:4Cyx3VjH(1) AAS
>>377
一般的には、そうだよね。
記事の内容は、視点がフツーじゃない。
383: sage 2019/05/02(木)07:41 ID:uuWYZZoh(1) AAS
>> 363
LGのTVの録画に使っていたディスクが壊れて調べたらLGのモデルでは次のようなことがあるらしい。
外部リンク:www.avforums.com
ひとことでいうと、録画ファイルのメインデータは JFSの第一パーティション。
メタデータ(リストとかかな?) はext3の第二パーティションに書き込む。
パーティションタイプはa2という独自のものを利用している(!)
新しいディスクはLG TVにフォーマットさせてたが、
TVが初期化した以前の2TBのWDディスクは
fdisk -l でみるとパーティションのバウンダリがセクターの始まりにないという。
そこでlinux の上で gparted で jfsのパーティションと最後に50MBほどのext3のパーティションを
省15
384: 2019/05/03(金)02:19 ID:MTUS+yEB(1) AAS
ファイルのヘッダ見るだけでファイルタイプがわかるように、
その人もパーティションのヘッダを見てファイルシステムがわかるんしゃないかな。
ファイルシステムにシグネチャとかあるのか知らんけど。
385: 2019/05/03(金)12:16 ID:Wzb7upON(1) AAS
無かったら mount -t auto なんて出来ないぞ
386(1): 2019/06/05(水)11:45 ID:7o3gJPQx(1) AAS
NixOS Takes Action After 1.2GB/s ZFS Encryption Speed Drops To 200MB/s With Linux 5.0+
外部リンク[php]:www.phoronix.com
ZoLもうダメそうだな
387(1): 2019/06/05(水)14:08 ID:rn1dV4UN(1) AAS
AES-NIが使えなくなってそこまで遅くなってるんだろう
暗号化をAESからchacha20に切り替えたらかなり改善されると思う
388: 2019/06/05(水)16:08 ID:ODK3wUcN(1) AAS
>>386
あらら(´・ω・`)
389: 2019/06/13(木)01:37 ID:vP00iu9C(1) AAS
>>387
ChaChaもChaChaでSSE/AVX使えないのはつらいぞ
390: 2019/06/16(日)06:51 ID:fORVbt/P(1) AAS
ARXはあまりアーキテクチャ依存しないから速いよ
391(1): 2019/06/26(水)02:22 ID:wL+APPob(1) AAS
改心したはずのトーバルズ氏がまたもや感情的な暴言
Liam Tung (Special to ZDNet.com) 翻訳校正: 編集部 2019年06月25日 12時28分
外部リンク:japan.zdnet.com
(前略) Torvalds氏に早速かんしゃくの矛先を向けられたのは、オーストラリア人プロ
グラマーのDave Chinner氏である。Chinner氏は、多くのLinuxディストリビューションが
サポートしているSilicon Graphics製のXFSファイルシステムを管理している。(中略)
しかしTorvalds氏は、Chinner氏の言い分を否定し、そのような考えを広めようと
している開発者は「無能だ」と痛烈に批判した。
「Dave、キャッシュはちゃんと機能する。そう思わない者は無能なだけだ。ファイル
システムによるアクセスの99%はキャッシュに保存され、IOを行うことは決してない。
省10
392: 2019/06/26(水)15:14 ID:6o+Ir3lv(1/3) AAS
>>391
>ページキャッシュはいまも、ダイレクトIOよりかなりスピードが遅い。そしてNVMeのSSDが高速になればなるほど、
>そのギャップは広くなりつつある。PCIe 4のSSDで、この問題はますます明白になるだろう。もはやページキャッシュを
>使用する理由は、旧態依然としたディスクストレージを使う手頃な価格のシステムやmmap() をサポートするためだけになりつつある
じゃあnvme用に新しいファイルシステム考えれば良いんじゃね?って気はするけどね。
磁気ディスクを前提としたファイルシステムIOいじって喧嘩するなよww
393(1): 2019/06/26(水)21:25 ID:LXNNeckR(1) AAS
何言ってんだ
ページキャッシュはファイルシステムの機能ではないだろ
394: 2019/06/26(水)22:04 ID:08MS9y/0(1) AAS
SSD向けのファイルシステムならもうあるからな
395: 2019/06/26(水)22:48 ID:6o+Ir3lv(2/3) AAS
>>393
> ページキャッシュはファイルシステムの機能ではないだろ
ではないにしても最終的にこの人が弄ったのはfs/配下なんでしょ?
何れにしてもそんなコアな部分を、nvmeの為に変更しますとか言ったら
揉めるのはしょうがない。
396: 2019/06/26(水)23:23 ID:OjXYcy1P(1) AAS
どちらかというと仮想メモリ周辺の話じゃないか
397: 2019/06/26(水)23:31 ID:6o+Ir3lv(3/3) AAS
何にしても特定機能の為に汎用部分弄ったら怒られるのはしょうがない。
398(1): 2019/06/27(木)07:53 ID:1kwJgDpi(1) AAS
非常に根本的が疑問があるんだが
ダイレクトI/Oより遅いページキャッシュってなんか話がおかしくね
ページキャッシュってオンメモリならストレージインターフェースより速いはずでは…?
399: 2019/06/27(木)10:34 ID:j+m7QE0N(1) AAS
ページキャッシュが無い環境を使ったことがないから分からんな
どうなんだろうな
400: 2019/06/27(木)13:32 ID:Va09TTiq(1) AAS
>>398
オンメモリでもページキャッシュの管理コストが絶対に発生するので
昔はストレージアクセスが文字通り桁違いに遅かったので管理コストは
無視しても差し支え無かったけど今はそうも言ってられなくなったってことかと
401: 2019/06/27(木)21:45 ID:icJgPc2A(1) AAS
ダイレクトIOが遅いって言ってるのは
rawデバイスでDB扱うレベルの話でOK?
でないとRAMがSSDに。ページキャッシュのコストがあるとはいえ遅いという話にはならんと思うんだが
402: 2019/06/27(木)22:50 ID:LI96p1HW(1) AAS
NVMeも通り越して、3DXpointだかあの辺のDRAMの数分の1くらいまで速いメモリを使うようになったら
ページキャッシュ経由するより直で読み書きした方が良くね?って話ならまだわかるけど
いくらNVMeでもフラッシュメモリ使っててページキャッシュはオーバーヘッドだからもう要らないみたいな話なら、何言ってんだお前…ってなる
403: 2019/06/28(金)17:51 ID:b8zcOuzC(1) AAS
jfs使てる人おらんの
404: sage 2019/06/28(金)18:01 ID:1jOqGt+U(1) AAS
>> 391
これって、次見るとわかるけど
外部リンク:lkml.org
要は、一般的な場合ではなくて、非常に大きくて(しかもアクセスパターン考えると)キャッシュになじまない
ような大きなデータのときにはページキャッシュのオーバーヘッド大きい、また(そのような場合には)
キャッシュに使うようなLRUみたいな汎用なアルゴリズムでなくてアプリケーションの方が素性が分かっているからそっちにキャッシュさせろと。
いうごく当たり前のこと言っている。しかも発言者は数字はだしてないが、多分95%くらいのアプリケーションは
全然いまのページキャッシュでも問題ないということも言っている。
つまり のこりの数値は私の感覚だが5%の大きなデータセットを使うDB(たとえばOracle)、big data crunchingとか
の場合を話をしているわけで、どこを見るかですれ違いは無理もないかもしれないがなんだかな。
省10
405: 2019/06/28(金)20:21 ID:GazpYCiw(1) AAS
対話をする気がないか、諦めてるんじゃないの?
406: 2019/06/28(金)20:40 ID:WA1on6xu(1) AAS
流れを見てないからわからんけど
これだけ見ると老害化してるやん
407: 2019/06/28(金)21:03 ID:KMXUlWzl(1) AAS
最近の書込みキャッシュ付きの RAID コントローラだと、NVMe/SSD に対しては
キャッシュを通さず直接書き込むほうが早いからそうしているらしい。
ちまちま4KBずつどのキャッシュを抹消していいかを計算しながらの、
ページテーブル書き換えながらの、だと本当に遅いんじゃないかね。
408: 2019/06/28(金)21:47 ID:UfcHNutv(1) AAS
消去がボトルネックというなら納得かな
409(3): 2019/06/29(土)00:02 ID:aGo2YBvo(1) AAS
RAID-Zのオーバーヘッドが今一つ分からないわ…。
パリティ+1の倍数分のブロック単位で区切るから、無駄が出る事が有るよって事?
スプレッドシートの数式見てもピンと来ないぞ…。
block size in sectors …、in sector ってどゆこと?単純に使用するブロックの数?
外部リンク:www.delphix.com
410(1): 2019/06/29(土)11:34 ID:55acDkj4(1/2) AAS
>>409
block size in sectors はファイルシステム側のブロックサイズ(またはデータベースのブロックサイズ)で、
OSがファイルシステムに対して書き込むを要求する基本サイズだね。
in sectors は KB 単位じゃなくてセクタ単位で書きましたよ、この書き方ならブロックサイズ 512B の人も
4KB の人も同じ表で良いよね、ってだけじゃないかと。
411(1): 2019/06/29(土)11:46 ID:55acDkj4(2/2) AAS
以下チラ裏。個人的解釈。
シートの Example にあるディスク7本のRAID-Z1を考える。
ブロックサイズ(プログラムやデータベースからの1度の書き込み要求のサイズ)が大きい場合は、
ディスク本数7−パリティ数(RAID-Z"1")=6なので、基本6セクタごとにパリティ1セクタが付与される。
RAID-5 と違ってブロックサイズが6セクタ未満の場合はパリティが1セクタ付与されるだけ。
例えば3セクタならパリティ1個追加して4セクタ分書き込む。
RAID-5 なら6セクタ+パリティ1個の7セクタ単位でしか書けない。
ただしRAID-Znは n+1 セクタ単位で書き込む必要があり、条件を満たさない場合は足りないセクタ分
パディングされる。 RAID-Z1 は n=1 なので書き込みセクタ数は2の倍数でなければならない。
なので2セクタ書き込む場合は、パリティ足して3セクタではなく4セクタ。
省5
412(1): 409 2019/06/30(日)00:08 ID:Iwm+1v/G(1) AAS
>>410-411
おお、ありがとう。データとの比率だったのね。スッキリしてきたよ。
最近ZFSについて調べ始めたのだが、いろいろと難しい…。
分かっていない所だらけなんだが、
・>>in sectors は KB 単位じゃなくてセクタ単位で書きましたよ → 使用されたブロックの数という認識で良い?
・ブロックと表現されているものは、NTFSで言うクラスタみたいなもん
・ブロックサイズは、4、8、16、32、64、128KBで可変(DBの人は8KBをセットする?)
・書き込まれるファイルのサイズによって、ブロックサイズとブロック数が変わってくる
という事であってますか?
413(1): 2019/06/30(日)03:37 ID:QfL+H/59(1) AAS
>>412
俺も ZFS についてはど素人なので下記内容については詳しい人による査読希望。
参照先の文脈においては、
(スプレッドシートの縦軸における)ブロック → 一回の書き込み量であってLinuxのファイルシステムのブロックサイズではない。
セクタ → ディスクに書き込む際の最小単位。 参照ページの2番目の図の P0 とか D0 の箱1個分。
セクタブロック → セクタと同義と解釈。
フィジカルブロックサイズ → セクタサイズと解釈。
(私見ではLinuxのファイルシステムの場合だと基本ブロック=セクタ=4KBなので厳密にどっちの話をしているか曖昧)
だと解釈。
> ・>>in sectors は KB 単位じゃなくてセクタ単位で書きましたよ → 使用されたブロックの数という認識で良い?
省9
414(1): 2019/07/02(火)01:12 ID:15r1RiO6(1) AAS
>>413
うーん…、頭がこんがらがってきた。
外部リンク[html]:docs.oracle.com
「ブロックサイズが自動的に調整されます」というのは、何を指示している…?
415: 2019/07/02(火)02:26 ID:vY+H/LKm(1/2) AAS
画像リンク[jpg]:i.stack.imgur.com
画像リンク[jpg]:i.stack.imgur.com
画像リンク[png]:genomewiki.ucsc.edu
画像リンク[png]:genomewiki.ucsc.edu
画像リンク[png]:genomewiki.ucsc.edu
やはりext4が攻守最強か
416: 2019/07/02(火)02:32 ID:VNdE/qGn(1) AAS
パフォーマンスとかコストとかならそうなんだろうけど、
透過圧縮とか正当性の検証とかとなるとzfsのが上ってかext4じゃ無理
417: 2019/07/02(火)05:18 ID:FKCbYBRA(1) AAS
xfsは重複排除とCoWに逆マッピングも対応したのは聞いてたけど
フォーマットの段階でオプション有効化する必要があったのか
今使ってるxfsとは全く別物だなこりゃ
外部リンク:strugglers.net
418(1): 2019/07/02(火)07:23 ID:dV8XE8AH(1) AAS
鯖屋は大変だな
俺みたいな一般人は黙ってext4使ってりゃいいんだろ?
現状はそれで過不足ないし臨機応変に使うFSを吟味しろとかやってられん
419: 409 2019/07/02(火)07:59 ID:7tOiBm/F(1/2) AAS
>>414
> > ・ブロックサイズは、4、8、16、32、64、128KBで可変(DBの人は8KBをセットする?)
> フィジカルブロックサイズは固定。
この文書からするとここが間違い(フィジカルブロックサイズは固定ではない)ですね。
元の文書でデータベース向けに 6KB に調整したってのがあるがそれがこれってことでしょう。
ソースを弄って調整した可能性もあったし、サイズが可変は間違いという話もあったので固定だと思っていました。
420: 2019/07/02(火)08:18 ID:7tOiBm/F(2/2) AAS
>>418
企業向けの大きいストレージは保守がハードとミドルウェアでセットになってないとNG。
加えて10年ぐらい前に luster や gluster fs, zfs ベースの製品が雨後の筍のように出てきたけど皆失敗した。
現状信頼されてるのは Isilon (OneFS) で、その下に NetApp (WAFL)。
HPE の 3PAR (AdaptiveFS?しらん) も評判下げずに続けてるようだ。 IBM の gpfs 使う製品もある。
言えるのは全てプロプラエタリで、オープンソース・フリーソフトの製品は企業は怖くて使ってられないみたいね。
なので鯖屋もストレージ屋に丸投げするしか仕事がないんじゃないかな。
421: 2019/07/02(火)18:13 ID:vY+H/LKm(2/2) AAS
オープンソースは
企業がバックにいないと話にならないよね
そういう意味ではRedHatが公式に支えているxfsがベスト
422: 2019/07/02(火)20:23 ID:RJ/Pz5R6(1) AAS
企業に支えられていないファイルシステムってどれのことだ?
423: 2019/07/02(火)20:45 ID:CdZ1Kw09(1) AAS
プロプラ由来かOSS由来か…って事なんじゃね
424: 2019/07/02(火)21:28 ID:rRMzFXGI(1) AAS
Reiserfs
出所したから復活するってのは嘘だったのかな
425(3): 2019/07/02(火)22:16 ID:9meA9UgT(1) AAS
2chスレ:linux
↑ここから誘導されてきたファイルシステム素人なんですけど
ext4が十分ではない場合って例えばどんな場合がありますか。
そしてext4では十分ではない場合にxfsやbtrfsを使えばその問題を解消できるんですかね。
ext4が対応できない問題って大抵のファイルシステムが対応できなさそうに思うんですけど……。
426(1): 2019/07/02(火)22:24 ID:+bA9GvGw(1) AAS
個人利用なら今でもreiserfs有用だと思う
あの早さが必要で諸々理解して使うなら
reiser4fsの開発開始しないかなしないだろうな
>>425
ext4遅い
ext3よりreiserfsの方が倍くらい早いんじゃないか?という感動は忘れられん
427: 2019/07/03(水)00:05 ID:NZGhw/Gn(1) AAS
>>426
速度の問題があるんですね。
意識したことなかったです……。
バカな質問に答えてくださいありがとうございます。
428: 2019/07/03(水)00:53 ID:Qt/N9GEP(1) AAS
今時パフォーマンスを最優先にするならF2FSでしょう
reiserfsはもう相対的にそこまで早くもないし
外部リンク[php]:www.phoronix.com
429: 2019/07/03(水)01:20 ID:ZZuB/vaR(1) AAS
そして障害時の対応で時間を食うと
430: 2019/07/03(水)01:22 ID:V5c8y5zy(1) AAS
>>425
>2chスレ:linux
こういう人って zfs も LVM に乗せて LV リサイズしたら壊れたって騒ぐんだろうな
431: 2019/07/03(水)01:44 ID:E6xhFUOk(1) AAS
用途にも寄るしな
安定性が課題のFSはテストならまだしも実用は怖い
個人デスクトップ用途だと小さめのファイル扱いはSSDだとそれほど差を感じないだろうが
大きなサイズの扱いはSSDでも時間かかる、これが早くなると体感がかなり違う
とするとReiserFSは安定してるし、デスクトップ用途かなり良さそう
432: 2019/07/03(水)03:41 ID:v76vN8mT(1) AAS
そんな終わったFSを前提にされても
433: 2019/07/03(水)11:23 ID:lvGvaRtu(1) AAS
>>425
うちは透過圧縮が欲しいから/をbtrfsにしてる奴がある(ZFSはツリー外のモジュールとか面倒くさいしfuseも使いたくない)
早いCPU+遅いHDDの組み合わせでディスクアクセスがボトルネックになってるような環境だと結構目に見えて高速化されるよ
ぼんやりとしか使ってないってのもあるけど3年ぐらい使ってて特にトラブルは無いな、まあデータを置こうとは思わんけど
つかswapファイルに対応したりとか普通に開発継続してんのにRedHatが抜けたってだけで放置とか色々言ってるやつはアレやな
434: 2019/07/03(水)12:13 ID:Y5ON4Ylq(1) AAS
だってRed HatのAndy Grover様も
Btrfsはメーリングリストが断末魔で埋め尽くされていてクソって言ってるんだもん
外部リンク:strugglers.net
435: 2019/07/03(水)16:06 ID:IxUC1S3v(1) AAS
btrfsは互換性とか影響範囲とか考えずにどっかで再設計すれば違う展望もあっただろうになあl
436: 2019/07/03(水)20:49 ID:pn6xgYzw(1) AAS
断末魔と団地妻って似てるな
437(1): 2019/07/04(木)08:58 ID:MPcWxAgH(1) AAS
btrfsの後釜になれるかもしれないbcachefsがそろそろLinuxカーネルのメインラインに入るぞ
おそらく次かその次のバージョン
438: 2019/07/04(木)09:09 ID:5FppRmLC(1) AAS
メーリングリストが団地妻で埋め尽くされるとか股間が熱くなるな
ファイルシステムが乱立ってのもなんだかなぁ
zfsをパクって機能削減してxfsと足して2で割り切れない感じでいいと思うんだが
439: 2019/07/04(木)09:13 ID:t19oAjJ9(1) AAS
そういうお前も新しいの作ろうとしてんじゃん
440(2): 2019/07/04(木)10:30 ID:66v4UI/A(1) AAS
bcachefsのホームページ見たら
最初の一文からアレを意識しすぎぃぃぃ
>We prioritize robustness and reliability over features and hype:
>私達は機能と誇大宣伝よりも堅牢性と信頼性を優先します。
外部リンク:bcachefs.org
441: 2019/07/04(木)12:10 ID:rpGqPEX9(1/2) AAS
究極たるzfsを崇めよ
442: 2019/07/04(木)15:51 ID:P64f5rak(1/3) AAS
>>440
先生!堅牢性と信頼性より機能と過大宣伝を優先したファイルシステムが多すぎてどれか特定できません!
443(1): 2019/07/04(木)15:52 ID:P64f5rak(2/3) AAS
しかも
外部リンク:mstdn.jp
らしいし。
444: 2019/07/04(木)16:54 ID:+XLHt8Ha(1) AAS
>>443
そのベンチマークは1年前で古いこっちの最新の結果を見た方が良い
外部リンク[php]:www.phoronix.com
XFS安定という結果には変わりないけど
445(1): 2019/07/04(木)17:09 ID:6XXEq2Nj(1) AAS
bcachefsは新しいけどベースがbcacheだからすでに信頼性はそれなりにありそう
まだ使ったことないけど期待はしておく
446: 2019/07/04(木)17:18 ID:JEN2SxWZ(1/2) AAS
F2FSってフラッシュストレージ向けのくせに最近はHDDのサポートもしてきてるんだよな
HDDで使うことはないだろうけど
447: 2019/07/04(木)19:12 ID:rpGqPEX9(2/2) AAS
枯れてないFSなんて地雷やで
448: 2019/07/04(木)19:29 ID:1YidJb1m(1) AAS
そうは言ってもxfsも最近は新機能追加しまくりだし
枯れてるの定義は結構難しいぞ
449: 2019/07/04(木)20:03 ID:P64f5rak(3/3) AAS
MINIXファイルシステムを使おう!
450: 2019/07/04(木)20:32 ID:z0Pbt8nE(1) AAS
最強に安定しているのはntfs
なお
451: 2019/07/04(木)20:53 ID:zNLNx3om(1) AAS
>>437
始まったな
452(2): 2019/07/04(木)22:44 ID:N/xMrX9J(1) AAS
windowsで安定してマウントできるファイルシステムは今はどれなんだ?
ext4ですらなんか怪しい感じなんだよなぁ
上下前次1-新書関写板覧索設栞歴
あと 550 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.037s