X
トップページ⇒Linux
1002コメント310KB
ファイルシステム総合スレ その18
レス数が1000を超えています。これ以上書き込みはできません。
0341login:Penguin
垢版 |
2019/01/15(火) 13:06:56.35ID:2Ah+Qrqf
Ubuntuどうするだろ
0343login:Penguin
垢版 |
2019/01/23(水) 02:31:34.66ID:3xXFOHSL
jfsって使ってる人どれくらい残ってるんだろう

これに新しいReiserfsにRedhatが新しく作ると言われてる奴が加わると思うと、胸が熱くなる
0344login:Penguin
垢版 |
2019/01/23(水) 18:35:07.23ID:0M8bthjo
UX4800で主流だったvxfsってどうなったんだろ
0345login:Penguin
垢版 |
2019/01/31(木) 19:49:57.57ID:eyiJg58C
olacleのzfsアプライアンスのボリュームをwindows10からsmbアクセスしたとき、大文字小文字の違いしかないファイルペアがあると、それらが8文字の長さの別のファイル名に見えるのはどういう機能なのでしょうか。
NFSでCentOSでマウントして、"hello.txt"と"Hello.txt"を作成すると、Windowsでは
HE~B3GZT.TXT
HE~C3GZT.TXT
という2つのファイルに見えます。
0346login:Penguin
垢版 |
2019/02/01(金) 08:04:15.23ID:N0xuylqN
>>345
Windowsはケースセンシティブじゃないから…
0347login:Penguin
垢版 |
2019/02/05(火) 23:09:56.64ID:KE7i+wC/
ext4で大文字小文字の区別をしないモードが開発されているらしい
0348login:Penguin
垢版 |
2019/02/06(水) 20:07:35.87ID:wB6R+SSI
それはそれでまた阿鼻叫喚の予感が…
0349login:Penguin
垢版 |
2019/02/08(金) 19:16:10.92ID:JCux+jot
ケースセンシティブでなきゃ死ぬ環境にも問題がありそうな気がする
0350login:Penguin
垢版 |
2019/02/08(金) 22:49:20.26ID:gM5IfNf+
昔、別の板でだけど
FAT32の外付けディスクにWin2000で大文字小文字だけの違うファイルを作って
それをWin98で読んだらどうなるかってのの話題があったな

FATの特性(エントリべた書き)もあるだろうけど
dirで表示されるファイルとエディタで開くファイルが違うとか、
移動させようとすると別な方が移動されるけど残った方が読めるようになるとか
いろいろ挙動不審だったらしい
0351login:Penguin
垢版 |
2019/02/15(金) 13:03:48.45ID:4tPOtJVd
>>345
FS側じゃなくてsambaのname manglingじゃねえの
Windowsで使えない文字とかもSamba経由だとそうなる
0352login:Penguin
垢版 |
2019/03/06(水) 12:57:44.81ID:GYShYGFU
釈放されたんだから早くreiser4復活しろよ
0353login:Penguin
垢版 |
2019/03/07(木) 02:54:37.96ID:6s6dEvVm
ようやく時代がreiser4に追いつくか？
0354login:Penguin
垢版 |
2019/03/07(木) 09:33:29.95ID:MuV+t1Gm
今はbcachefsのほうが期待されてるだろう
0355login:Penguin
垢版 |
2019/03/11(月) 00:35:21.09ID:UOCKT9C0
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に移行すべきかなかなか良いスタンダードが確立してないよねぇ
0356login:Penguin
垢版 |
2019/03/11(月) 00:40:43.65ID:IigLLh3C
btrfsはトラブるたんびにモグラ叩き、の繰り返しだったろうに何故に実運用しようとするのか
0357login:Penguin
垢版 |
2019/03/11(月) 00:52:12.93ID:5TJmB3dg
video encodingかw
エンコ厨のアニヲタは氏ねばいいよw
0358login:Penguin
垢版 |
2019/03/11(月) 03:25:35.52ID:Iugc1R92
btrfsは失敗だもう捨てろ
0359login:Penguin
垢版 |
2019/03/11(月) 03:39:15.17ID:obZ/zwS+
btrfsのスナップショットは作る分にはいいけど…
0360login:Penguin
垢版 |
2019/03/11(月) 10:13:10.16ID:nc+22c0z
もうNILFS2は誰も見てくれないのかなあ。
結構好きで/homeに使っているのだけれど。。。
0361login:Penguin
垢版 |
2019/03/11(月) 23:14:39.58ID:SU9pN+Q4
どんなメリットがあって使っているの
0362login:Penguin
垢版 |
2019/03/12(火) 20:49:05.55ID:yL9gOqQR
>361
Logファイルシステムなんでファイル操作ごとにチェックポイントができるから保存されている限り任意の時点のファイルシステムの状態が復元できるんで、
あ、消しちゃったとか、間違えて書き換えちゃった時にすぐ取り返せる。
ルートで対象のチェックポイントをスナップショットに変更してマウントする作業する必要があるけど。。。
ファイルシステム止めずにスナップショットが得られるので他の作業しながらコンシステンシー気にせずにバックアップが取れる。
書き込み量とストレージのサイズによるけどデフォで1時間で設定で24時間位は遡れるようにしているので割と気軽にファイル操作している。
とは言っても実際にファイル取り返さないといけないケースは1年に数回程度だけど。
0363login:Penguin
垢版 |
2019/03/16(土) 17:38:18.22ID:RacPXVIy
このディスクのファイルシステム何かわかる人いませんか・・・・・・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
0364363
垢版 |
2019/03/16(土) 17:50:40.75ID:RacPXVIy
あ、ディスク自体はパナのVIERAに外付けHDDとして接続してたTV録画HDDです。
HDD自体はsmartやら、ddやらの読出し結果からは異常はないっぽくて、
どうも中のファイルシステムがおかしくなってるっぽいなんとか復旧したく。

各パーテション、CodeがFFFFでファイルシステムが何かわかりません。
fileの結果からは、/tmp/mntとなってるので、UNIX系の何かだとは思うんですが・・・・
0365login:Penguin
垢版 |
2019/03/16(土) 18:42:10.51ID:QAw47Obs
レコーダで初期化したHDDは独自のファイルシステムになってるもんじゃないの？
そうでないと録画データの引っこ抜きとかが容易になるわけで。
0366login:Penguin
垢版 |
2019/03/16(土) 19:11:00.46ID:FKDx4ojb
> 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
そんなことしてたら、コストに見合わない
安定性やバグ取りにサポートまで必要なことに手を出すほど、メーカーはヒマじゃない
せいぜい多少の細工をして外部から読みにくくすることがあるかも程度
0367363
垢版 |
2019/03/16(土) 21:15:49.38ID:RacPXVIy
ありがとうございます。独自ファイルシステムだとコスト的にあわなさそうというのは同意見です。
TV側のOSkernelレベルからカスタムする必要がありそうですし。


吸い出したddをもとに、現状、以下をやってます。

・別HDDへのｄｄでの丸コピでどうにかならないか
　　→　HDD個体識別はGUIDでやってるだろうという推測ベースで激遅コピー中。HDD異常ではなさそうなので望み薄。

・ddとったイメージをいろんなOSでマウントして中身をみてみる
　　→　USF2対応のFreeBSDでマウントしてみたけど、なぜかデバイスファイルのリンクがきれててNG。
　　　　GUIDとか、gpt上のファイルシステム№、ラベルとかを振りなおしてもだめでした。
　　　　ddイメージのfileの結果はUSF2だけど、gptのcode上はUSF2を示すA503ではなく、
　　　　FFFFで、リザーブ№というか、末番なのが果てしなく怪しい。

・マウントせずにファイルを見れるツールを使ってファイルだけ吸い出してみる
　　→　大量の分割ファイル（mp3、mlv？）。あとSQliteとかいうDBMS関連と思われるファイル（dbx、sqlite、txt）
　　　　某社みたいにmpegファイルとして直で保存してなくて、DBMS内に格納していそうな予感。
　　　　DB論理破壊なら絶望的・・・・・。そもそも構造もよくわからんし・・・・。


現状からすると、UNIX系をベースにファイルシステム、保存方法の両方に細工がされてそうに見えます。
DB解析はあきらめて、ちょっとファイルシステムが壊れてるだけです！の方向で継続してま・・・・・
東芝のTVにしとけばよかったなぁ・・・・
0368363
垢版 |
2019/03/16(土) 22:17:05.43ID:RacPXVIy
てきとうにやってたら━(ﾟ∀ﾟ)━DB構造見えてきたー
https://imgur.com/pg50Nq7

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

ということで全力でDBデータ吸い出し中。
0369login:Penguin
垢版 |
2019/03/16(土) 22:54:00.06ID:RacPXVIy
TV録画HDDまるごとddイメージ用の2TB、
TV録画HDDのパーテションごとddイメージ2用のTB、
パーテションごとddイメージの一応swabイメージ用の2TB、
DB吸い出し用の2TB。空き容量ガー。
今日はもうddでHDDコピーしながらDB吸い出し仕掛けて寝ることにしま・・・・

もし同じような境遇でデータ救えた人がいればアドバイスいただきたく・・・
0370login:Penguin
垢版 |
2019/03/18(月) 19:49:09.41ID:Vfq3Yari
デコードできるのそれ？
0371login:Penguin
垢版 |
2019/03/18(月) 20:09:35.84ID:23E+fOK/
録画データ壊れてて読み込んだ時点で死んでるとかじゃなければDB修復したら元のTVで見れるでしょ
0373363
垢版 |
2019/03/21(木) 01:42:47.79ID:/l10lWhU
はい。結局マウントかけずにフアイルを読み出すツールだと、情報が断片的にしか読めずDB復旧にはいたりませんでした！あと、ddの完コピディスクも予定通りダメなとこまでコピーされてだめ！南無！
0374363
垢版 |
2019/03/21(木) 01:45:46.80ID:/l10lWhU
結局、gpartのFFFFコードの小細工を突破して、正攻法でマウントして読み込んでffckなりするしかなさそうですが、これはうちのスキルではむりんご。
0375login:Penguin
垢版 |
2019/04/09(火) 13:17:11.49ID:1OOoyLh/
【速報】削除後、起動しているだけでデータが復元できなくなるという性質がLinuxのファイルシステムに存在することが判明
https://cloud.watch.impress.co.jp/topics/dds1904/

>Windowsでは、1回削除してもファイルシステム上にはフォルダ構成が残っているのですが、
>Linuxに関しては、削除後はしばらくそのままにしているだけでどんどん消えていきます。
>起動しているだけでデータが消えるという性質がLinuxのファイルシステムにはあります。
0376login:Penguin
垢版 |
2019/04/09(火) 13:22:56.97ID:lhCkt0bg
ファイルシステム名すら書かずに
0377login:Penguin
垢版 |
2019/04/09(火) 13:39:29.81ID:izrDON32
セキュリティ的にはそのほうがいいんじゃない？
0378login:Penguin
垢版 |
2019/04/09(火) 13:41:03.99ID:xKrw21om
>>375
Linuxでは削除したデータの復活が難しいって話でしょ?
データが勝手に消えるという意味ではないぞ
0379login:Penguin
垢版 |
2019/04/09(火) 14:45:23.63ID:MWJmYr9/
ファイルシステムの仕様の話でバグでもなんでもないよな
それにファイルシステム上から完全に削除したファイルの復元なんてWindowsにしろLinuxにしろ保証なんてしてないし
0380login:Penguin
垢版 |
2019/04/10(水) 11:00:23.00ID:4T4hCHHJ
ext4との比較かな
そんな性質あるのか？ssdの場合か？
0381login:Penguin
垢版 |
2019/04/10(水) 11:51:08.21ID:sqoFbBjM
ext4は結構戻せるからxfsのことでないかな
0382login:Penguin
垢版 |
2019/04/11(木) 07:56:59.03ID:4Cyx3VjH
>>377
一般的には、そうだよね。
記事の内容は、視点がフツーじゃない。
0383sage
垢版 |
2019/05/02(木) 07:41:59.61ID:uuWYZZoh
>> 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の投稿者はどうやって知ったんだろう？
0384login:Penguin
垢版 |
2019/05/03(金) 02:19:19.70ID:MTUS+yEB
ファイルのヘッダ見るだけでファイルタイプがわかるように、
その人もパーティションのヘッダを見てファイルシステムがわかるんしゃないかな。
ファイルシステムにシグネチャとかあるのか知らんけど。
0385login:Penguin
垢版 |
2019/05/03(金) 12:16:35.70ID:Wzb7upON
無かったら mount -t auto なんて出来ないぞ
0387login:Penguin
垢版 |
2019/06/05(水) 14:08:52.34ID:rn1dV4UN
AES-NIが使えなくなってそこまで遅くなってるんだろう
暗号化をAESからchacha20に切り替えたらかなり改善されると思う
0389login:Penguin
垢版 |
2019/06/13(木) 01:37:16.29ID:vP00iu9C
>>387
ChaChaもChaChaでSSE/AVX使えないのはつらいぞ
0390login:Penguin
垢版 |
2019/06/16(日) 06:51:50.05ID:fORVbt/P
ARXはあまりアーキテクチャ依存しないから速いよ
0391login:Penguin
垢版 |
2019/06/26(水) 02:22:44.66ID:wL+APPob
改心したはずのトーバルズ氏がまたもや感情的な暴言
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氏は応じている。
0392login:Penguin
垢版 |
2019/06/26(水) 15:14:51.68ID:6o+Ir3lv
>>391
>ページキャッシュはいまも、ダイレクトIOよりかなりスピードが遅い。そしてNVMeのSSDが高速になればなるほど、
>そのギャップは広くなりつつある。PCIe 4のSSDで、この問題はますます明白になるだろう。もはやページキャッシュを
>使用する理由は、旧態依然としたディスクストレージを使う手頃な価格のシステムやmmap() をサポートするためだけになりつつある

じゃあnvme用に新しいファイルシステム考えれば良いんじゃね？って気はするけどね。
磁気ディスクを前提としたファイルシステムIOいじって喧嘩するなよｗｗ
0393login:Penguin
垢版 |
2019/06/26(水) 21:25:29.86ID:LXNNeckR
何言ってんだ
ページキャッシュはファイルシステムの機能ではないだろ
0394login:Penguin
垢版 |
2019/06/26(水) 22:04:26.08ID:08MS9y/0
SSD向けのファイルシステムならもうあるからな
0395login:Penguin
垢版 |
2019/06/26(水) 22:48:54.02ID:6o+Ir3lv
>>393
> ページキャッシュはファイルシステムの機能ではないだろ

ではないにしても最終的にこの人が弄ったのはfs/配下なんでしょ？
何れにしてもそんなコアな部分を、nvmeの為に変更しますとか言ったら
揉めるのはしょうがない。
0396login:Penguin
垢版 |
2019/06/26(水) 23:23:02.57ID:OjXYcy1P
どちらかというと仮想メモリ周辺の話じゃないか
0397login:Penguin
垢版 |
2019/06/26(水) 23:31:21.49ID:6o+Ir3lv
何にしても特定機能の為に汎用部分弄ったら怒られるのはしょうがない。
0398login:Penguin
垢版 |
2019/06/27(木) 07:53:35.03ID:1kwJgDpi
非常に根本的が疑問があるんだが
ダイレクトI/Oより遅いページキャッシュってなんか話がおかしくね
ページキャッシュってオンメモリならストレージインターフェースより速いはずでは…？
0399login:Penguin
垢版 |
2019/06/27(木) 10:34:39.89ID:j+m7QE0N
ページキャッシュが無い環境を使ったことがないから分からんな
どうなんだろうな
0400login:Penguin
垢版 |
2019/06/27(木) 13:32:07.45ID:Va09TTiq
>>398
オンメモリでもページキャッシュの管理コストが絶対に発生するので
昔はストレージアクセスが文字通り桁違いに遅かったので管理コストは
無視しても差し支え無かったけど今はそうも言ってられなくなったってことかと
0401login:Penguin
垢版 |
2019/06/27(木) 21:45:22.84ID:icJgPc2A
ダイレクトIOが遅いって言ってるのは
rawデバイスでDB扱うレベルの話でOK?
でないとRAMがSSDに。ページキャッシュのコストがあるとはいえ遅いという話にはならんと思うんだが
0402login:Penguin
垢版 |
2019/06/27(木) 22:50:29.23ID:LI96p1HW
NVMeも通り越して、3DXpointだかあの辺のDRAMの数分の1くらいまで速いメモリを使うようになったら
ページキャッシュ経由するより直で読み書きした方が良くね？って話ならまだわかるけど
いくらNVMeでもフラッシュメモリ使っててページキャッシュはオーバーヘッドだからもう要らないみたいな話なら、何言ってんだお前…ってなる
0403login:Penguin
垢版 |
2019/06/28(金) 17:51:59.02ID:b8zcOuzC
jfs使てる人おらんの
0404sage
垢版 |
2019/06/28(金) 18:01:49.33ID:1jOqGt+U
>> 391

これって、次見るとわかるけど
https://lkml.org/lkml/2019/6/14/127
要は、一般的な場合ではなくて、非常に大きくて（しかもアクセスパターン考えると）キャッシュになじまない
ような大きなデータのときにはページキャッシュのオーバーヘッド大きい、また（そのような場合には）
キャッシュに使うようなLRUみたいな汎用なアルゴリズムでなくてアプリケーションの方が素性が分かっているからそっちにキャッシュさせろと。
いうごく当たり前のこと言っている。しかも発言者は数字はだしてないが、多分９５％くらいのアプリケーションは
全然いまのページキャッシュでも問題ないということも言っている。
つまり　のこりの数値は私の感覚だが５％の大きなデータセットを使うDB（たとえばOracle)、big data crunchingとか
の場合を話をしているわけで、どこを見るかですれ違いは無理もないかもしれないがなんだかな。

ページキャッシュの話を読んでて、次の話を思い出した。昔Sun Sparc V6だったか、bitblt 命令が入って、
白黒画面程度だったらCPUだけで簡単なウィンドウサポートができるようになった。
ただし、、MC６８Kなんかの場合にCPUだけでやって困ったのが、カラー画面の書き換えしただけで
キャッシュが使われてしまって肝心のユーザアプリケーションのデータがキャッシュから追い出されることがある。
つまりカラー画面のデータって結構大きいので、そこを書き換えるとアプリケーションのデータがキャッシュから
おいだされてしまうことがままある。
Sun Sparcの場合には、bitblt関係の命令っで使ったデータはキャッシュしないことで
この問題を解決して、なるほどと思った。
巨大なデータセットがページキャッシュをバイパスするのも同じような話なんだけども、
なんでLinusは理性ある対話ができないのだろう？
0405login:Penguin
垢版 |
2019/06/28(金) 20:21:42.62ID:GazpYCiw
対話をする気がないか、諦めてるんじゃないの？
0406login:Penguin
垢版 |
2019/06/28(金) 20:40:28.14ID:WA1on6xu
流れを見てないからわからんけど
これだけ見ると老害化してるやん
0407login:Penguin
垢版 |
2019/06/28(金) 21:03:39.64ID:KMXUlWzl
最近の書込みキャッシュ付きの RAID コントローラだと、NVMe/SSD に対しては
キャッシュを通さず直接書き込むほうが早いからそうしているらしい。
ちまちま4KBずつどのキャッシュを抹消していいかを計算しながらの、
ページテーブル書き換えながらの、だと本当に遅いんじゃないかね。
0408login:Penguin
垢版 |
2019/06/28(金) 21:47:13.92ID:UfcHNutv
消去がボトルネックというなら納得かな
0409login:Penguin
垢版 |
2019/06/29(土) 00:02:34.09ID:aGo2YBvo
RAID-Zのオーバーヘッドが今一つ分からないわ…。
パリティ+1の倍数分のブロック単位で区切るから、無駄が出る事が有るよって事？
スプレッドシートの数式見てもピンと来ないぞ…。
block size in sectors …、in sector ってどゆこと？単純に使用するブロックの数？

https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz
0410login:Penguin
垢版 |
2019/06/29(土) 11:34:54.48ID:55acDkj4
>>409
block size in sectors はファイルシステム側のブロックサイズ(またはデータベースのブロックサイズ)で、
OSがファイルシステムに対して書き込むを要求する基本サイズだね。
in sectors は KB 単位じゃなくてセクタ単位で書きましたよ、この書き方ならブロックサイズ 512B の人も
4KB の人も同じ表で良いよね、ってだけじゃないかと。
0411login:Penguin
垢版 |
2019/06/29(土) 11:46:31.18ID:55acDkj4
以下チラ裏。個人的解釈。
シートの Example にあるディスク７本のRAID-Z1を考える。
ブロックサイズ(プログラムやデータベースからの１度の書き込み要求のサイズ)が大きい場合は、
ディスク本数７－パリティ数(RAID-Z"1")＝６なので、基本６セクタごとにパリティ１セクタが付与される。

RAID-5 と違ってブロックサイズが６セクタ未満の場合はパリティが１セクタ付与されるだけ。
例えば３セクタならパリティ１個追加して４セクタ分書き込む。
RAID-5 なら６セクタ＋パリティ１個の７セクタ単位でしか書けない。

ただしRAID-Znは n+1 セクタ単位で書き込む必要があり、条件を満たさない場合は足りないセクタ分
パディングされる。 RAID-Z1 は n=1 なので書き込みセクタ数は２の倍数でなければならない。
なので２セクタ書き込む場合は、パリティ足して３セクタではなく４セクタ。

Example に戻って１度の書き込みのセクタ数が１６の場合、
セクタ1-6+パリティ + セクタ7-12+パリティ + セクタ13-16+パリティ
の計19セクタ、n+1の倍数の制限でパディングが１セクタ追加されて総計20セクタ必要。

パリティとパディングは 20-16 で 4 セクタ。
データに対するパリティとパディングの比率は 4/16 で 25% になる。
0412409
垢版 |
2019/06/30(日) 00:08:50.88ID:Iwm+1v/G
>>410-411
おお、ありがとう。データとの比率だったのね。スッキリしてきたよ。
最近ZFSについて調べ始めたのだが、いろいろと難しい…。

分かっていない所だらけなんだが、
・>>in sectors は KB 単位じゃなくてセクタ単位で書きましたよ → 使用されたブロックの数という認識で良い？
・ブロックと表現されているものは、NTFSで言うクラスタみたいなもん
・ブロックサイズは、4、8、16、32、64、128KBで可変（DBの人は8KBをセットする？）
・書き込まれるファイルのサイズによって、ブロックサイズとブロック数が変わってくる
という事であってますか？
0413login:Penguin
垢版 |
2019/06/30(日) 03:37:15.39ID:QfL+H/59
>>412
俺も ZFS についてはど素人なので下記内容については詳しい人による査読希望。

参照先の文脈においては、
(スプレッドシートの縦軸における)ブロック → 一回の書き込み量であってLinuxのファイルシステムのブロックサイズではない。
セクタ → ディスクに書き込む際の最小単位。 参照ページの２番目の図の P0 とか D0 の箱１個分。
セクタブロック → セクタと同義と解釈。
フィジカルブロックサイズ → セクタサイズと解釈。
(私見ではLinuxのファイルシステムの場合だと基本ブロック＝セクタ＝4KBなので厳密にどっちの話をしているか曖昧)
だと解釈。

> ・>>in sectors は KB 単位じゃなくてセクタ単位で書きましたよ → 使用されたブロックの数という認識で良い？
使用されたフィジカルブロック数という認識ですね。

> ・ブロックと表現されているものは、NTFSで言うクラスタみたいなもん
Linux スレ的にはそう。 フィジカルブロックならそう。 スプレッドシートの文脈のブロックなら違う。

> ・ブロックサイズは、4、8、16、32、64、128KBで可変（DBの人は8KBをセットする？）
フィジカルブロックサイズは固定。

> ・書き込まれるファイルのサイズによって、ブロックサイズとブロック数が変わってくる
フィジカルブロックサイズは固定でブロック数だけ変わる。
zfs で動的ストライプ幅って言ってるのはフィジカルブロックサイズ(RAID装置によってはチャンクサイズって呼んでる部分)
が動的に変化するのではなく、パリティグループ(データ＋パリティ,2番目の図の色が同じ箱のセット)の幅が動的ってだけ。
0416login:Penguin
垢版 |
2019/07/02(火) 02:32:52.56ID:VNdE/qGn
パフォーマンスとかコストとかならそうなんだろうけど、
透過圧縮とか正当性の検証とかとなるとzfsのが上ってかext4じゃ無理
0417login:Penguin
垢版 |
2019/07/02(火) 05:18:02.15ID:FKCbYBRA
xfsは重複排除とCoWに逆マッピングも対応したのは聞いてたけど
フォーマットの段階でオプション有効化する必要があったのか
今使ってるxfsとは全く別物だなこりゃ
https://strugglers.net/~andy/blog/2017/01/10/xfs-reflinks-and-deduplication/
0418login:Penguin
垢版 |
2019/07/02(火) 07:23:04.59ID:dV8XE8AH
鯖屋は大変だな
俺みたいな一般人は黙ってext4使ってりゃいいんだろ？
現状はそれで過不足ないし臨機応変に使うFSを吟味しろとかやってられん
0419409
垢版 |
2019/07/02(火) 07:59:51.04ID:7tOiBm/F
>>414
> > ・ブロックサイズは、4、8、16、32、64、128KBで可変（DBの人は8KBをセットする？）
> フィジカルブロックサイズは固定。
この文書からするとここが間違い(フィジカルブロックサイズは固定ではない)ですね。
元の文書でデータベース向けに 6KB に調整したってのがあるがそれがこれってことでしょう。
ソースを弄って調整した可能性もあったし、サイズが可変は間違いという話もあったので固定だと思っていました。
0420login:Penguin
垢版 |
2019/07/02(火) 08:18:06.21ID:7tOiBm/F
>>418
企業向けの大きいストレージは保守がハードとミドルウェアでセットになってないとNG。
加えて10年ぐらい前に luster や gluster fs, zfs ベースの製品が雨後の筍のように出てきたけど皆失敗した。
現状信頼されてるのは Isilon (OneFS) で、その下に NetApp (WAFL)。
HPE の 3PAR (AdaptiveFS?しらん) も評判下げずに続けてるようだ。 IBM の gpfs 使う製品もある。
言えるのは全てプロプラエタリで、オープンソース・フリーソフトの製品は企業は怖くて使ってられないみたいね。
なので鯖屋もストレージ屋に丸投げするしか仕事がないんじゃないかな。
0421login:Penguin
垢版 |
2019/07/02(火) 18:13:16.85ID:vY+H/LKm
オープンソースは
企業がバックにいないと話にならないよね
そういう意味ではRedHatが公式に支えているxfsがベスト
0422login:Penguin
垢版 |
2019/07/02(火) 20:23:04.94ID:RJ/Pz5R6
企業に支えられていないファイルシステムってどれのことだ？
0423login:Penguin
垢版 |
2019/07/02(火) 20:45:36.79ID:CdZ1Kw09
プロプラ由来かOSS由来か…って事なんじゃね
0424login:Penguin
垢版 |
2019/07/02(火) 21:28:31.67ID:rRMzFXGI
Reiserfs
出所したから復活するってのは嘘だったのかな
0425login:Penguin
垢版 |
2019/07/02(火) 22:16:53.32ID:9meA9UgT
https://mao.5ch.net/test/read.cgi/linux/1557401718/
↑ここから誘導されてきたファイルシステム素人なんですけど
ext4が十分ではない場合って例えばどんな場合がありますか。
そしてext4では十分ではない場合にxfsやbtrfsを使えばその問題を解消できるんですかね。
ext4が対応できない問題って大抵のファイルシステムが対応できなさそうに思うんですけど……。
0426login:Penguin
垢版 |
2019/07/02(火) 22:24:04.87ID:+bA9GvGw
個人利用なら今でもreiserfs有用だと思う
あの早さが必要で諸々理解して使うなら

reiser4fsの開発開始しないかなしないだろうな

>>425
ext4遅い
ext3よりreiserfsの方が倍くらい早いんじゃないか？という感動は忘れられん
0427login:Penguin
垢版 |
2019/07/03(水) 00:05:11.18ID:NZGhw/Gn
>>426
速度の問題があるんですね。
意識したことなかったです……。
バカな質問に答えてくださいありがとうございます。
0429login:Penguin
垢版 |
2019/07/03(水) 01:20:53.54ID:ZZuB/vaR
そして障害時の対応で時間を食うと
0431login:Penguin
垢版 |
2019/07/03(水) 01:44:17.52ID:E6xhFUOk
用途にも寄るしな
安定性が課題のFSはテストならまだしも実用は怖い

個人デスクトップ用途だと小さめのファイル扱いはSSDだとそれほど差を感じないだろうが
大きなサイズの扱いはSSDでも時間かかる、これが早くなると体感がかなり違う
とするとReiserFSは安定してるし、デスクトップ用途かなり良さそう
0432login:Penguin
垢版 |
2019/07/03(水) 03:41:45.20ID:v76vN8mT
そんな終わったFSを前提にされても
0433login:Penguin
垢版 |
2019/07/03(水) 11:23:23.07ID:lvGvaRtu
>>425
うちは透過圧縮が欲しいから/をbtrfsにしてる奴がある(ZFSはツリー外のモジュールとか面倒くさいしfuseも使いたくない)
早いCPU+遅いHDDの組み合わせでディスクアクセスがボトルネックになってるような環境だと結構目に見えて高速化されるよ

ぼんやりとしか使ってないってのもあるけど3年ぐらい使ってて特にトラブルは無いな、まあデータを置こうとは思わんけど

つかswapファイルに対応したりとか普通に開発継続してんのにRedHatが抜けたってだけで放置とか色々言ってるやつはアレやな
0434login:Penguin
垢版 |
2019/07/03(水) 12:13:29.85ID:Y5ON4Ylq
だってRed HatのAndy Grover様も
Btrfsはメーリングリストが断末魔で埋め尽くされていてクソって言ってるんだもん
https://strugglers.net/~andy/blog/2017/01/10/xfs-reflinks-and-deduplication/
0435login:Penguin
垢版 |
2019/07/03(水) 16:06:18.82ID:IxUC1S3v
btrfsは互換性とか影響範囲とか考えずにどっかで再設計すれば違う展望もあっただろうになあｌ
0436login:Penguin
垢版 |
2019/07/03(水) 20:49:55.88ID:pn6xgYzw
断末魔と団地妻って似てるな
0437login:Penguin
垢版 |
2019/07/04(木) 08:58:47.97ID:MPcWxAgH
btrfsの後釜になれるかもしれないbcachefsがそろそろLinuxカーネルのメインラインに入るぞ
おそらく次かその次のバージョン
0438login:Penguin
垢版 |
2019/07/04(木) 09:09:45.05ID:5FppRmLC
メーリングリストが団地妻で埋め尽くされるとか股間が熱くなるな

ファイルシステムが乱立ってのもなんだかなぁ
zfsをパクって機能削減してxfsと足して２で割り切れない感じでいいと思うんだが
0439login:Penguin
垢版 |
2019/07/04(木) 09:13:41.09ID:t19oAjJ9
そういうお前も新しいの作ろうとしてんじゃん
0440login:Penguin
垢版 |
2019/07/04(木) 10:30:19.24ID:66v4UI/A
bcachefsのホームページ見たら
最初の一文からアレを意識しすぎぃぃぃ
＞We prioritize robustness and reliability over features and hype:
＞私達は機能と誇大宣伝よりも堅牢性と信頼性を優先します。
https://bcachefs.org/
0441login:Penguin
垢版 |
2019/07/04(木) 12:10:02.17ID:rpGqPEX9
究極たるzfsを崇めよ
0442login:Penguin
垢版 |
2019/07/04(木) 15:51:02.60ID:P64f5rak
>>440
先生！堅牢性と信頼性より機能と過大宣伝を優先したファイルシステムが多すぎてどれか特定できません！
0445login:Penguin
垢版 |
2019/07/04(木) 17:09:39.55ID:6XXEq2Nj
bcachefsは新しいけどベースがbcacheだからすでに信頼性はそれなりにありそう
まだ使ったことないけど期待はしておく
0446login:Penguin
垢版 |
2019/07/04(木) 17:18:29.96ID:JEN2SxWZ
F2FSってフラッシュストレージ向けのくせに最近はHDDのサポートもしてきてるんだよな
HDDで使うことはないだろうけど
0447login:Penguin
垢版 |
2019/07/04(木) 19:12:45.96ID:rpGqPEX9
枯れてないFSなんて地雷やで
0448login:Penguin
垢版 |
2019/07/04(木) 19:29:25.21ID:1YidJb1m
そうは言ってもxfsも最近は新機能追加しまくりだし
枯れてるの定義は結構難しいぞ
0449login:Penguin
垢版 |
2019/07/04(木) 20:03:25.18ID:P64f5rak
MINIXファイルシステムを使おう！
0450login:Penguin
垢版 |
2019/07/04(木) 20:32:20.56ID:z0Pbt8nE
最強に安定しているのはntfs
なお
0452login:Penguin
垢版 |
2019/07/04(木) 22:44:03.98ID:N/xMrX9J
windowsで安定してマウントできるファイルシステムは今はどれなんだ？
ext4ですらなんか怪しい感じなんだよなぁ
0454login:Penguin
垢版 |
2019/07/04(木) 23:01:52.19ID:nCIQ4/jH
>>452
ext2fs+ext4

これでだめだったらwindows窓から投げ捨てろ
0455login:Penguin
垢版 |
2019/07/05(金) 00:04:02.89ID:tcFjwaW7
wsl2が来るまで待て
0456login:Penguin
垢版 |
2019/07/05(金) 00:10:18.86ID:j7UvDQ62
仮にntfsがオープンソースになってカーネルにマージされたら
互換性も考えてほぼ一択化になるだろうな
0457login:Penguin
垢版 |
2019/07/05(金) 00:23:35.79ID:G1guSEeh
>>454
ext2fsって開発が滞ってないか？
それに、環境によって、最新版だとマウントできないみたいだし。
実際自分のところもできなくて、いくつか戻す必要があった。
0458login:Penguin
垢版 |
2019/07/05(金) 00:51:32.72ID:w6qq3pqZ
ファイルシステムのシェアってどんなもんなんだろうな
デバイス数では地味にF2FSが上位かもしれない
0459login:Penguin
垢版 |
2019/07/05(金) 02:22:44.82ID:54nYef5x
NTFSそれ自体の評価って高いの？
それともNTFSの概念や設計が評価できるの？
0460login:Penguin
垢版 |
2019/07/05(金) 02:40:31.93ID:7kZq9gYf
ディスクのハード故障を除けばNTFSで致命的な状態に陥った経験は無いな
0461login:Penguin
垢版 |
2019/07/05(金) 02:53:50.58ID:q3JGl+2T
>>459
NTFSは特に良いところもなく、ファイル破損が良く起きる経験しかない
0462login:Penguin
垢版 |
2019/07/05(金) 03:00:14.05ID:j7UvDQ62
全世界のPC初心者に有償で提供してるだけあって
少なくともWindows上ではクッソ安定してる
Winを使ってるような層を相手に安定してるんだから異次元としか言い様がない
0463login:Penguin
垢版 |
2019/07/05(金) 03:02:08.04ID:q3JGl+2T
いやそういうの要らないから
対立煽りってやつ？
0464login:Penguin
垢版 |
2019/07/05(金) 04:11:17.66ID:SYL5tGuC
安定していると言ったら対立煽りに見える思考やばいだろ
0466login:Penguin
垢版 |
2019/07/05(金) 06:48:52.45ID:54nYef5x
>>462
なるほど。そういう見方もあるな。
Unixは基本的にファイルシステムをある程度理解してるから
Windowsの大半の利用者みたいな使い方はしないわな。
その上で安定してるというのであればすごい。
でもそんなに安定してる？
0467login:Penguin
垢版 |
2019/07/05(金) 07:42:17.19ID:q3JGl+2T
ntfsは電源断などのファイル破損が起こりやすいところとか
度々ext系ほかと比べられてるけど、同じ話ループしすぎなような
0468login:Penguin
垢版 |
2019/07/05(金) 08:25:02.29ID:54nYef5x
どうでもいいけどWikipediaのBrtFSの記事すっごく宣伝調だね……
0470login:Penguin
垢版 |
2019/07/05(金) 12:10:41.83ID:kGpLF8uq
＞「今のLinuxにNTFSレベルにマトモなファイルシステムなぞない」
まで読んだ
0471login:Penguin
垢版 |
2019/07/05(金) 12:25:54.82ID:yalE+Jvn
アンチMSには理解し難いだろうけど、エンドユーザーが利用可能でよくメンテされて機能的にNTFS以上のファイルシステムってちょっと思いつけない、あるなら例示して？…ってなるな。
ああ、「俺の好きなFS」じゃないんで。まあ言っても理解できないだろうが…

もちろんWindowsから扱う場合の話で、互換環境で同等の信頼性があるとは思えんが。
それでもUFSやextよりはずっとマシ
0472login:Penguin
垢版 |
2019/07/05(金) 12:26:03.28ID:8tR6yfC3
そういえばBSDのハマー2の評価はどうなの？
0473login:Penguin
垢版 |
2019/07/05(金) 12:28:53.02ID:yalE+Jvn
Linux環境だと、データセンター並みに巨大なボリュームを扱うとか、ウェアレベリングの無いフラッシュメモリをストレージにする組み込みみたいな特殊用途でない個人ユースなら、消去法でext4が無難か…
0474login:Penguin
垢版 |
2019/07/05(金) 12:30:53.10ID:yalE+Jvn
>>468
たまにあるよね、読者を説得というか、折伏？しようとしてる記事。
0475!ninja
垢版 |
2019/07/05(金) 12:40:54.45ID:rX9H6RAi
デスクトップとしてLinuxを使用して写真の現像とか色々しているけれど
ext4で問題になった事はないです。(安定しています)
因みにWindowsはカメラのファームアップとOSアップデート位しか使わない。
0476login:Penguin
垢版 |
2019/07/05(金) 14:25:39.16ID:qDrdSQQO
別に個人が普通に使うならどれでも滅多に困らない
0477login:Penguin
垢版 |
2019/07/05(金) 17:01:26.55ID:5Oj7dNKU
外付けHDDをLinuxで使う場合、
FAT32は無いものとして、
NTFSとexFAT、どちらのほうが無難？
0478login:Penguin
垢版 |
2019/07/05(金) 17:18:10.07ID:aHzpu2WI
外付けHDDだってことは、複数のOSからmountすることもあるだろうから
exFATが無難というか最良かと
0479login:Penguin
垢版 |
2019/07/05(金) 17:29:29.45ID:0uxDVNFV
>>472
DragonflyBSD使てる日本人は居らん
0480login:Penguin
垢版 |
2019/07/05(金) 23:39:13.82ID:QVfQ7xAQ
COWありでまともに使えるファイルシステムはどれなんだー
0481login:Penguin
垢版 |
2019/07/06(土) 00:04:47.81ID:8LM9xkHS
xfsでしょそりゃ
ただしフォーマットし直さないとCoWは有効化出来ないけど
0482login:Penguin
垢版 |
2019/07/06(土) 04:51:15.15ID:g9aj4tWg
xfsのcowってまともに使えるのか？
最近使えるようになったばかりだろ
新しいファイルシステムと同じようなもの
0483login:Penguin
垢版 |
2019/07/06(土) 04:59:40.34ID:8LM9xkHS
xfsのメンテナが自分のPCで
CoW導入で使えるようになった
新機能の重複排除を使ってると言ってるのだから安心していいかと
0484login:Penguin
垢版 |
2019/07/06(土) 05:20:44.07ID:VaeT5YKG
そりゃファイルシステムのメンテナなら自分のPCで動かしてて当然だろうな
0485login:Penguin
垢版 |
2019/07/06(土) 05:27:27.89ID:L3XPzqxa
俺はbtrfsのメンテナがbtrfsを常用しているとは思えない
0486login:Penguin
垢版 |
2019/07/06(土) 05:32:05.88ID:g9aj4tWg
常用してなくても動かしてはいるだろ
0487login:Penguin
垢版 |
2019/07/06(土) 07:08:26.31ID:JWtFUONt
btrfsのお陰でニュースサイトは信用ならないものだということを再認識した
ボラクルの政治力（）がそれをさせたのだろうか、それとも
0489login:Penguin
垢版 |
2019/07/06(土) 07:54:59.98ID:RB1jb8Q5
「btrfsは透過圧縮が凄い！！」
みたいな宣伝ならまだ分かる。
実際には
「btrfsは他のFSよりも堅牢！安全！」
みたいに、大事なデータこそbtrfsみたいな言い方してるからタチが悪い 。
0491login:Penguin
垢版 |
2019/07/06(土) 11:46:12.10ID:4pSPVA6e
>>483
ストレージなんて導入後１年とか経過したら急激にパフォーマンスが悪化したみたいな話は少なくないわけで。
データ置くんだから色々なハード×運用アプリ×負荷条件×期間で運用して実績積んだ上じゃないと安心
なんてとても言えないんじゃ。
0492login:Penguin
垢版 |
2019/07/06(土) 22:08:19.81ID:PDOwGV40
>>488
オラクルが始めたプロジェクト
0493login:Penguin
垢版 |
2019/07/06(土) 23:47:58.49ID:5GCvrZe5
オラク●って、会社が関係すると残念なイメージ。
Solaris ヨロなんだけど。
0494login:Penguin
垢版 |
2019/07/07(日) 03:37:25.09ID:DBQmyWlt
Btrfs は RAID1 にサイズの異なるディスクを追加してどうヤリクリしてくるか眺めるFS
0495login:Penguin
垢版 |
2019/07/07(日) 22:55:34.83ID:wHKJWVtP
メタな話だけどなんでこのスレ犬板にあんの？ム板とかじゃなくて。
0496login:Penguin
垢版 |
2019/07/07(日) 23:36:16.83ID:LnsdbLSY
Linuxはファイルシステムの選択肢が多いから、どのファイルシステムを使うのがベストなのかを語るスレだからじゃないの？
ファイルシステムの実装について語るスレだったらプログラム板にあってもおかしくないかもしれないが、
そんなコアな人は5chじゃなくて各OSSファイルシステムのMLとかでやりとりしてるんじゃないの。

自分でコードを書く人向けなのがプログラム板で、ソフトウェアをユーザーとして使う人向けなのがそれ以外の板だと思うけどね。
じゃなきゃハード関係の話題以外はなんでもかんでもプログラム板ってことになっちゃうでしょう。
0497495
垢版 |
2019/07/08(月) 06:57:24.61ID:AnURrIsm
>>496
言われてみればそうだな。
確かに多くの種類のファイルシステムを「使う」のはLinuxやBSDユーザーだな。
そしてその実装は5chで議論することじゃないな。
俺がバカでしたw
0498login:Penguin
垢版 |
2019/07/08(月) 08:52:01.68ID:3iNxio62
btrfsが問題あるっぽいのはわかる。わかるんだけど、サブボリュームとか便利すぎて乗り換えれない。長らく使っててクラッシュしたの一回だけだし、性能もソコソコだし、バックアップ気軽に取れるし
0499login:Penguin
垢版 |
2019/07/08(月) 09:09:49.39ID:PqTeDeaF
>>498
そのファイルシステム
静かに壊れているかもしれないぞ？
試しにbtrfsckをして確認してみた方がいい
0500login:Penguin
垢版 |
2019/07/08(月) 09:27:52.78ID:w3Gb5F7g
>>498
その点でいうとzfsがいいんだよなぁ
0501login:Penguin
垢版 |
2019/07/08(月) 09:28:36.91ID:c9rRPEoT
btrfs は静かに壊れるという経験はないなあ。
壊れるときはあっという間にエラーログ吐きまくって盛大にぶっ壊れる。
btrfsの唯一(?)凄いのところは、ぶっ壊れても頑張れば相当サルベージできるところ。
面倒くさいからバックアップから復旧するけど。
0502login:Penguin
垢版 |
2019/07/08(月) 11:23:09.26ID:3iNxio62
>>499
btrfs check やってみたよ！
問題なかった

zfsは遅いイメージがあるのとライセンス的に……
0503login:Penguin
垢版 |
2019/07/08(月) 15:53:33.33ID:ZuNR36h3
個人的にはzfsは速度より古いPCを再利用しようとした時にメモリを食うのがネック過ぎる
削りに削ったFreeBSDですらdedupしてないのに2Gでもきつい
0504login:Penguin
垢版 |
2019/07/09(火) 01:21:48.35ID:ATXfrt0N
そんなカスみたいな環境で使うことは想定してないしな
0505login:Penguin
垢版 |
2019/07/09(火) 10:36:21.37ID:PmpiXixe
AppleがZFSを諦めたぐらいだからお察し
0507login:Penguin
垢版 |
2019/07/09(火) 14:58:02.10ID:p5VdkUCQ
appleがzfsを採用しなかったのは暗号化に対応していなかったからだぞ
ZoLは最近になって暗号化に対応したけどな
0508login:Penguin
垢版 |
2019/07/10(水) 11:40:51.24ID:nTeldC4a
/dev/sdc に刺さったPVから作られたLVMがあるんだけど、このディスクを /dev/sdb に
繋ぎ変えたいんだけど、繋ぎ変えるだけでそのまま使えますか？
何か作業が必要？
0510login:Penguin
垢版 |
2019/07/10(水) 20:53:42.68ID:ystpoF80
>>508
lvm.conf で vgscan で除外するデバイス一覧に /dev/sdb が入ってなければOK。
lvm.conf を修正したなら initramfs 再作成もお忘れなく。
0512login:Penguin
垢版 |
2019/07/12(金) 15:39:16.18ID:Gk95DGyH
昔特に考えもなく/bootを除いたOS丸ごとZFSにしてたのを
OS更新に伴って見直そうと思うんだけど
とりあえずメインで使うのは引き続きZFSにして
/boot←fat32(esp)
/tmp←ext4
くらいしか思い付かないんだけど他に良い案とかないかな？
0513login:Penguin
垢版 |
2019/07/12(金) 15:53:09.43ID:Wh9lI3H9
もう何年もずっとtmpにはtmpfsを使っている…もちろん推奨などしない
0514login:Penguin
垢版 |
2019/07/12(金) 15:57:49.66ID:pfDdKblt
メイン以外の定義を決めてくれないと答えようがない
0515login:Penguin
垢版 |
2019/07/12(金) 15:59:17.82ID:a2hc7ITq
/boot ext4
/boot/efi fat32
にするものらしい
0516login:Penguin
垢版 |
2019/07/12(金) 16:02:09.99ID:pfDdKblt
bootはxfsにすると高速起動するよ
地味な変更だけど効果は大きいからオススメ
0517login:Penguin
垢版 |
2019/07/12(金) 16:34:46.25ID:Gk95DGyH
>>513
それちょっと良いかも。検討してみるよ

>>515-516
/boot xfs
/boot/efi fat32
で試してみるよ。出来ることなら高速起動の方が良いもんね

>>514
特にオススメが無いor迷ったらZFSにするくらいの意味で捉えて頂ければ
0518login:Penguin
垢版 |
2019/07/12(金) 17:11:53.45ID:sHZS1XdB
メモリが潤沢な環境で/tmpの下のいくつかのディレクトリをtmpfsにするのは有意だけど
/tmp全体をtmpfsにするのはtmpfsのドキュメントで禁忌にされてるので、やるならまあown riskで
0519login:Penguin
垢版 |
2019/07/12(金) 17:12:43.46ID:sHZS1XdB
× 有意
〇 有意義
0520login:Penguin
垢版 |
2019/07/12(金) 18:11:52.90ID:ZSiArtpk
むしろ最近のディストロは/tmpまるまるtmpfsが割と普通な気が
その禁忌って書いてあるドキュメントって読んでみたいんだけどどれ？
0521login:Penguin
垢版 |
2019/07/12(金) 20:37:16.63ID:9P7R948V
Fedoraがやってるんだから問題ない
とりあえず迷ったらFedoraがどうしてるか見るのがいい
全ての設定はFedoraから流れていく
0522login:Penguin
垢版 |
2019/07/12(金) 22:07:44.94ID:29vUxDs3
Fedoraは先進的で実験的らしいから実装一発目の機能とかは怖いイメージ((((；゜Д゜)))
0523login:Penguin
垢版 |
2019/07/13(土) 13:05:37.63ID:fcJUubh5
/tmpは普通にtmpfsだろ
/var/tmpは違うけど
0525login:Penguin
垢版 |
2019/07/15(月) 11:17:17.22ID:BML/RJbp
RHEL7 は systemd だけど tmpfs ではないな。 (Fedora は人柱？)

例えばメモリ 192GB 搭載のサーバで /tmp に tmpfs 使ってる場合、OS、サービス、
仮想マシン等で190GBメモリを使ってたら、/tmp に書き込める量って2GBだけで
それ以降はスワップアウトって事だよね？
なんか心許ないなぁ。
0526login:Penguin
垢版 |
2019/07/15(月) 19:48:13.96ID:Ii92h755
tmpfsに書き込むデータよりも先に他のデータがスワップアウトされるけどな
0527login:Penguin
垢版 |
2019/07/15(月) 19:56:32.39ID:mvcgcerj
前提条件がおかしいわな
空きメモリが10%以下の状態とかtmpfs関係なくメモリ不足
0528login:Penguin
垢版 |
2019/07/15(月) 20:45:12.78ID:jA364y5E
個人利用で仮想マシン動かしつつ動画編集もやりたいって場合でも
メモリ64GBあれば平気そうかな
今メモリ安いからちょっと奮発すればいける
0529login:Penguin
垢版 |
2019/07/15(月) 21:39:47.11ID:BML/RJbp
>>527
解析用途の場合は10%以下でも特にメモリ不足って感じはしないなぁ。
0530login:Penguin
垢版 |
2019/07/15(月) 22:57:15.14ID:smBs7w2W
/tmpの容量が気になるほどの巨大ファイルを置くような使い方、する？
0531login:Penguin
垢版 |
2019/07/15(月) 23:39:07.37ID:BML/RJbp
>>530
解析用途であらかじめ使うのがわかってる場合は /tmp 以外に NVMe とかで別途高速なデバイス用意する。
しかしミスって /tmp に書くバカもいる。
0532login:Penguin
垢版 |
2019/07/15(月) 23:47:09.55ID:abOBY2uh
なんでそんな特定状況で対処もわかってる話でtmpfs使うとか言い出すん？
0533login:Penguin
垢版 |
2019/07/16(火) 05:46:05.80ID:cLso77RL
.oO(いまさら禁忌は /tmp じゃなくて /var/tmp だった…なんて言えそうにない雰囲気だな)
0534525
垢版 |
2019/07/16(火) 08:19:48.24ID:pVYPD0D6
>>532
RHEL7 では /tmp が tmpfs ではない話の中で、なぜ tmpfs を使わないかの理由について
候補を挙げてるだけで、tmpfs 使っちゃダメって言ってる人とは別の人です。
0535login:Penguin
垢版 |
2019/07/16(火) 12:15:47.45ID:h7Uk/eM5
/var/tmpは再起動してもデータが残っていないと駄目だからtmpfsが禁止なんて当然だよな
0536login:Penguin
垢版 |
2019/07/16(火) 23:26:48.78ID:usQ9SNx3
インチキなブログのtipsだと/var/logもtmpfs指定したfstab晒してたりして舌がﾚﾛﾚﾛってなる
0537login:Penguin
垢版 |
2019/07/17(水) 09:58:56.10ID:AFXHMKqq
まあ昔のSSDだとlogもtmpfsに突っ込みたくなる気持ちは分からなくもない
0538login:Penguin
垢版 |
2019/07/17(水) 10:39:03.48ID:bt1cpQOM
まあデメリットとかわかった上で自分がやる分には全然いいと思うけど人に進めるもんじゃないってのはあるね
0539login:Penguin
垢版 |
2019/07/17(水) 12:44:08.44ID:8muhHKDE
bcachefsがカーネルにマージされたら即座に導入するわ
ファイル名長が緩和されるのが素晴らしい
現状だとWindowsで解凍可能なファイルがLinuxではファイル名長の関係で
ひと工夫しないと解凍不可能だったりして不便すぎる
0540login:Penguin
垢版 |
2019/07/18(木) 03:50:29.60ID:NlMiN+2I
>>539
例えば？
正直ファイルシステムの出来はともかく
ファイル名に関してはext4とかの方が柔軟な気がするんだけど。
0541login:Penguin
垢版 |
2019/07/18(木) 10:30:47.46ID:qpBAOMYJ
例えばも何もファイル名長って書いてあるやん
そのあたりの諸元でLinux系fsの大半に問題が出るのは常識だと思ってたけど
0542login:Penguin
垢版 |
2019/07/18(木) 11:22:32.09ID:JDRv+q9U
LVMで確保されたストレージのサイズ変更を
久しぶりにやってみた。lvextendでLVの
サイズを変更して、xfs_growfsでユーザから
見える空き容量を増やす簡単なお仕事だが、
何度やってもドキドキしちゃうな。
0543login:Penguin
垢版 |
2019/07/18(木) 12:36:42.61ID:/3OmbnoQ
>>539
こんなの作られてたのか
btrfsはダメみたいだしZOLは導入めんどくさいから
出来が良いといいんだけどなぁ
0545login:Penguin
垢版 |
2019/07/18(木) 18:31:40.18ID:LlSTNp3u
>>542
拡張ならまだよい。
縮小するお仕事は、大変だよ？
0546login:Penguin
垢版 |
2019/07/18(木) 19:03:55.38ID:NlMiN+2I
>>545
それでファイルシステム破壊したことあるw
家のサブ機だったから自己責任だったけど
あれ全く縮小の準備が整ってなくても何の警告もなしに実行するんだね。
少なくとも2016年では。
0547login:Penguin
垢版 |
2019/07/18(木) 19:45:18.30ID:YgfrHJvj
>>546
おれもルートファイルシステムを縮小しようとして、起動しなくなったことがある。
バックアップから戻した。以後試してない。
0548login:Penguin
垢版 |
2019/07/19(金) 22:22:13.23ID:9+hwCVUH
bcachefsの開発者ってpatronで資金提供者集めてるんだな
0549login:Penguin
垢版 |
2019/07/19(金) 22:29:05.21ID:DJejSRGa
マジか
寄付しとこ
0550login:Penguin
垢版 |
2019/07/19(金) 23:01:06.73ID:rvNOTbce
大口スポンサーの要求が参照リンクの実装だったらしく
今急ピッチで実装しているみたいだな
0551login:Penguin
垢版 |
2019/07/19(金) 23:01:58.65ID:rvNOTbce
これが実現するとbtrfsやxfsのような形式での重複排除も可能になる
0552login:Penguin
垢版 |
2019/07/19(金) 23:21:10.11ID:KCjCfW9P
なんでbcacheなんか拡張することにしたのか疑問だったけど
このKent Overstreetって人がbcache本体の作者でもあったのか
ずっとfacebookがやってるやつとごっちゃになってたわ
0553login:Penguin
垢版 |
2019/07/19(金) 23:28:54.90ID:rvNOTbce
bcacheの作者がbcachefsの作成に移行した影響で
大元のbcache自体が全然更新されていないという状況になってる
オープンソースって実際には1人抜けたら立ち行かないようなプロジェクトばかりよね
0554login:Penguin
垢版 |
2019/07/19(金) 23:38:05.63ID:Ss290YYV
bcashefsのベースになってるから下手に弄れなくなったんだろ
あるある過ぎて笑えんけど
0556login:Penguin
垢版 |
2019/07/20(土) 03:51:57.90ID:WfYnTXWF
ext4に続いてF2FSも大文字小文字を区別しないようにするオプションが作られているらしい
0557login:Penguin
垢版 |
2019/07/20(土) 06:23:21.98ID:Mi7o95f1
どこ読んでるかわかんないけど、コメントちゃんとあるように見えるけど
0558login:Penguin
垢版 |
2019/07/20(土) 08:08:29.10ID:bPfJoXMV
寄付なんて殆どが直接募集した奴が何割吸い取るかもわからない詐欺みたいなもんだぞ
0559login:Penguin
垢版 |
2019/07/20(土) 08:44:45.83ID:/RW5DImO
本人が集金してるんですがそれは
0561login:Penguin
垢版 |
2019/07/20(土) 22:18:28.70ID:zeHgvHr/
なにその機械翻訳みたいな文章
0562login:Penguin
垢版 |
2019/07/21(日) 07:22:04.94ID:ROhY0MNF
>>561
chromeで自動翻訳してくれるからそのまま貼った。
0563login:Penguin
垢版 |
2019/07/23(火) 03:28:06.87ID:SCZ5bl9v
>>454
Ext2Fsdをインストールしてるとリムーバブルメディアを取り外せなくなるからアンインストールした

>>459
ファイルを更新した直後に青画面や停電などでクラッシュすると
次回起動時に該当ファイルが0で埋められる挙動があってデータを失ったことがある
ソフトはバックアップを作ってから更新するタイプだったがご丁寧にもバックアップまで0で埋められた
0564login:Penguin
垢版 |
2019/07/23(火) 03:45:44.40ID:SCZ5bl9v
>>440 >>445
bcachefsは知らんが
bcacheは安定性に難あり
条件を満たすとカーネルがメモリやスタックの汚染を報告して十数分後から数時間後にシステムが確実にクラッシュする
多数ある条件を回避していって最近になってようやく安定稼働に持ち込めた
0565login:Penguin
垢版 |
2019/07/23(火) 03:47:57.79ID:eYVlzNHh
それファイルシステムのせいじゃないだろ
0566login:Penguin
垢版 |
2019/07/23(火) 07:13:59.96ID:y0KQNHxf
xfsも一時期酷かったけど今は高評価だし、直ってれば何でもええよ
0567login:Penguin
垢版 |
2019/07/23(火) 08:55:55.62ID:gjJlsP0Z
何かを利用するって事は、その下側の使ってる部分の品質を上回れない事でもあるからなぁ
安定したばっかのを使うってのは（ｒｙ
0568login:Penguin
垢版 |
2019/07/23(火) 10:34:20.54ID:y0KQNHxf
そういうのを使ってあーでもないこーでもないと情報を交換したりバグを報告するのがOSSユーザーの嗜みであり楽しみでは？
0569login:Penguin
垢版 |
2019/07/26(金) 00:00:48.02ID:jkGHHOAL
今まで何もわからずUFA使ってたけど新NAS作ろうとして調べれば調べるほどファイルシステムが選べないわ
どれも一長一短あるしまるでリーマン予想を解いているみたいだ
0570login:Penguin
垢版 |
2019/07/26(金) 00:23:48.04ID:kTNN9g4P
いやxfs一択でしょ
0572login:Penguin
垢版 |
2019/07/26(金) 18:49:37.46ID:/zAUPOSD
windowsから読み書きできない時点で、
XFSのせいではないが、候補から外したくなる
0574login:Penguin
垢版 |
2019/07/26(金) 20:48:37.30ID:/zAUPOSD
緊急時、データだけでも確保したいときのことを考えちゃうんだよ
XFSって、プラットフォームによってはLinuxからでも読めないことあるしなぁ
市販のNASで一度懲りたわ
0575login:Penguin
垢版 |
2019/07/26(金) 21:09:09.29ID:McqAipQp
そんなこと言い出したらNTFS最強って話になってくるし
0576login:Penguin
垢版 |
2019/07/26(金) 21:12:57.73ID:rbHyg+XJ
読めるファイルシステムでバックアップ取りなよ
0577login:Penguin
垢版 |
2019/07/27(土) 01:35:01.82ID:Ut6QMCX/
windows関係ないけど、xfsの何がという話をしないから
信心深いのかな？くらいにしか思わない
自分ならext4で無難かな
0578login:Penguin
垢版 |
2019/07/27(土) 10:50:20.98ID:95325KkT
>>577
RHEL7 のファイルシステムサイズの上限が ext4 は 50TB、xfs が 500TB。
2U サイズのラックマウントサーバだと 3.5インチHDDが12本は載るからext4
だと１パーティションに収まらないのよね。

上限は RHEL6 の時は 16TB だったからその頃から xfs を選択せざるを
得なくなった人が多い。
RHEL7 以降デフォルトが xfs になってるから不具合も一番潰されてるだろう
から、一番安心して使える。

何を以て安心っていうかというと、どれだけ多くのディスク/RAID装置で、
どれだけ多くの故障パターンを経験して来たかだと思ってる。
なので普及率はバカにできない。

>>574
カーネルを新しくするか逆に古くする、マウントオプション色々試す、はやった？
0579login:Penguin
垢版 |
2019/07/27(土) 11:50:18.10ID:c6O4WNXP
>>565
仮想マシンのゲストのWindows(10とXP)がクラッシュしたときも再現したのでNTFS実装の挙動で間違いない
俺はそれを見たとき対策を諦めた
0580login:Penguin
垢版 |
2019/07/27(土) 11:52:02.12ID:c6O4WNXP
同じNTFSでも2000ではファイルを閉じるときに必ず物理書き込みする挙動があって
クラッシュしたときにファイルが壊れる経験は皆無だった
0581login:Penguin
垢版 |
2019/07/27(土) 11:53:55.94ID:c6O4WNXP
XFSの噂はよく聞くが、どのベンチマークでもメタデータ更新系の成績がかなり悪い点は気になっている
細かいファイルをよく扱うLinuxとは相性悪いんじゃないだろうか？
0582login:Penguin
垢版 |
2019/07/27(土) 12:09:30.28ID:RKarvGRO
複数のファイルの遅延書き込みを溜め込みつつ、特定のファイルのフラッシュが必要になったら
確実にそのファイルへの変更結果をファイルシステムに矛盾が発生しない順序で
即座に物理層に反映・・・って、実は思ってる以上に複雑

その辺りは資本の力で開発されたファイルシステムに軍配が上がる
0583login:Penguin
垢版 |
2019/07/27(土) 13:47:26.05ID:6zG70b0r
遅くてもいいから壊れないものを
0584login:Penguin
垢版 |
2019/07/27(土) 13:47:41.85ID:Ut6QMCX/
>その辺りは資本の力で開発されたファイルシステムに軍配が上がる
んなこたーない、ntfs厨はもうこないでほしい
0585login:Penguin
垢版 |
2019/07/27(土) 14:09:34.66ID:RKarvGRO
何故NTFSに限定したのだろうか・・・
0586login:Penguin
垢版 |
2019/07/27(土) 14:17:25.71ID:Ut6QMCX/
限定したよ、だから何
帰れ
0587login:Penguin
垢版 |
2019/07/27(土) 14:34:02.96ID:SmtkTd2f
上にもあるが現在は正解がないというのが真実な気がする
正解がないので各派閥が宗教のように自分が使っているFSだけを信じ続けている
デジタルなのにやってることは人類が太古から続けているアナログ的な宗教に行き着くというのが感慨深い
0588login:Penguin
垢版 |
2019/07/27(土) 14:47:59.82ID:RKarvGRO
商用のファイルシステム以外はzfsとextの中間に位置する様なシロモノがないからな
その辺りにbtrfsが位置する予定だったんだろうけど、蓋を開けてみたらアレだったしな
0589login:Penguin
垢版 |
2019/07/27(土) 15:44:12.94ID:ynbj8IZE
>>578
ARMアーキテクチャのNASで使われているXFSは、
x86アーキテクチャのマシンからは、
エンディアンの違いで読めないことがあったんだよ。
（知ってたらゴメンね）

読む方法はある（シェアウェア）らしいし、
最近はバグらしきもの（FSかドライバか）が取れたらしいけど。


>>580
Linux物理マシンをext3で使ってたとき、
sync コマンドと、ALT＋SysRq＋s はなんか習慣的に押してたなw
まぁ、気休め程度にしかならんだろうけど。
0591login:Penguin
垢版 |
2019/07/27(土) 19:23:55.42ID:mQu6FNvv
クラッシュ耐性上げるにはCoWしか無いんだよな
bfrfs不安定と言われているけど突然の停止にはxfsやext4より壊れにくい
0592login:Penguin
垢版 |
2019/07/28(日) 02:04:51.78ID:OAxz9Pyz
xfsにもフォーマット時のオプションで
CoWが可能になったの知らないのか
0593login:Penguin
垢版 |
2019/07/28(日) 09:43:26.39ID:8zKDGL71
>>591
メタデータについてはジャーナリング機能の実装段階でそれ相応の物が
入ってて、CoWでは耐性上がりようがないって認識だわ。

そもそもシステムコールで明示的に呼び出さない限り CoW にならないわけで、
CoW ではなくスナップショットファイルシステムというべきじゃないかな。
0594login:Penguin
垢版 |
2019/07/28(日) 21:18:10.31ID:CB5E+oZy
今までファイルが壊れた経験があるファイルシステム
・btrfs
・ntfs
0595login:Penguin
垢版 |
2019/07/29(月) 10:42:58.53ID:AMCKbOHw
ファイルシステムの頑健性っていうのはソフトウェアのレイヤーで全てが語れるわけじゃない
あるファイルシステムのある機能が、あるディスクアレイでは頑健性を上げることもあれば逆もありえる
仮想マシンだってそう、むしろレイヤーが重なる上にハードウェアチートまであるから
クラッシュ時の挙動がファイルシステム側由来なのかなんてfs設計者でも簡単には分からん
0596login:Penguin
垢版 |
2019/07/29(月) 19:08:03.66ID:4QwhTaJH
スナップショットとシンプロビジョニングはオープンソースだとテストのやり込みが足りない・
テスト量がシステムの修正に追いついていないせいで安定しないイメージだわ。
これら＋RAID-Z/VRAID系は長期利用時のフラグメンテーション対策がお留守な感じなんで
スナップショット等が必要な業務環境でオープンソース系ファイルシステム使うのは怖い。
0597login:Penguin
垢版 |
2019/07/29(月) 19:58:02.26ID:zJDJcz0l
RAID-ZってZFS以外使ってるんだっけ?
今のSolarisとFreeBSDとZoL,どれが一番安定してるんだか
0598login:Penguin
垢版 |
2019/07/29(月) 22:46:46.27ID:4QwhTaJH
>>597
Linux 外だが Isilon の OneFS がストライプ長可変なのでほぼ同じもの。
こちらは RAID-Z4 相当まで実装してる。
0599login:Penguin
垢版 |
2019/07/30(火) 03:59:06.50ID:qLodTkR5
>>597
Solaris
0600login:Penguin
垢版 |
2019/07/30(火) 05:28:26.62ID:HF8yxYK2
>>597
意味がわからないけどRAID-Z=ZFSだろ？
0602login:Penguin
垢版 |
2019/07/31(水) 16:24:21.03ID:esTiVmHP
JFSやXFSで満足しないならもうLinuxを棄てるしかないんや
0603login:Penguin
垢版 |
2019/07/31(水) 16:49:32.80ID:Wv68Jyik
>>602
バイバイsoralis
君のことはもう忘れたよ
0604login:Penguin
垢版 |
2019/08/01(木) 04:08:51.36ID:BMyzMKl4
次元、五右衛門　久しぶりだなー
カール　今日はご主人様と一緒じゃないのか？
（カールという名前はわしの他はもう　Soralis様しか知らないはずだ。）
Soralis？　そうか、お前のご主人は Soralisってえのか..。
.....
.....

銭形: Oracleはとんでもないものを盗んでいきました。
　　 それは貴方のファイルシステムです。
0605login:Penguin
垢版 |
2019/08/01(木) 05:02:38.99ID:rA7aLj1x
もしかして：Solaris
0606login:Penguin
垢版 |
2019/08/01(木) 07:08:56.64ID:/5jO1LjD
soralis?solaris?
誰でぇ、それは
0608login:Penguin
垢版 |
2019/08/03(土) 04:46:19.02ID:okf0cS5M
結局色々やってext4に行き着いた
0609login:Penguin
垢版 |
2019/08/03(土) 07:21:09.50ID:67ZtkjFh
アップデートもないしほとんど使っている人はいないと思うけどメインのNoteの/homeをnilfs2で運用初めてそろそろ10年。

それ以降PC自体が3代目でPC替えたらDDではなくてcpで移したので10年連続で同じパーティションを10年運用したわけではないけど、FSが飛ぶような深刻な自体は使い始めに操作を間違ったときくらい。

Nilfs2の仕様上FSフルにしてしまうと面倒なことが起こるけど、それも10年で2回程度。

概ね24時間分ぐらいは遡れるようにしているので間違って書き換えたり消したりしてもすぐ取り返せる安心感が嬉しくて使っている。
といってもその作業も10年で3回程度だけど。。。
0610login:Penguin
垢版 |
2019/08/07(水) 15:48:47.13ID:tHruglCb
CoW版のXFS使ってみたけどめっちゃ安定してるわ
完全に常用も可能な漢字
0611login:Penguin
垢版 |
2019/08/07(水) 16:06:32.13ID:D6dfz/XB
そんなゴミみたいな煽り文句は他所でやれ
0612login:Penguin
垢版 |
2019/08/07(水) 16:13:26.51ID:VOvKzyRf
最低限どういう手法でテストしたのか位は書いてもらわんと何も意味ないわな
0613login:Penguin
垢版 |
2019/08/07(水) 19:19:11.92ID:eVw1mf5N
そのくらいゆるふわ意見だと我が家のbtrfsも一度もデータ飛んだこと無いし、動画圧縮で凄く容量削減してるし、山ほどスナップショット撮れてるし、ものすごくtrimできるし、死ぬほど安定してる
0614login:Penguin
垢版 |
2019/08/08(木) 16:07:29.83ID:BnM28ZaO
100台月ぐらいメタデータ・シーケンシャル・ランダムアクセスの混在負荷テストすりゃいいかなと思っている
0615login:Penguin
垢版 |
2019/08/09(金) 12:25:30.55ID:2xxnQ7nf
Ubuntu 19.10からZFSのサポート強化　2019/08/09 08:33　後藤大地
https://news.mynavi.jp/article/20190808-874101/

Canonicalは8月7日(米国時間)、「Enhancing our ZFS support on Ubuntu 19.10 - an
introduction - Ubuntu Blog｜Ubuntu Blog」において、この秋にリリースが予定されて
いる「Ubuntu 19.10」のデスクトップ版からZFSのサポート機能を強化する予定だと伝えた。

このまま順調に開発が進めば、Ubuntu 19.10 Dekstopでは実験的という位置づけながらも、
ルートファイルシステムをZFSで構築することが可能になると見られる。

Canonicalは今後、ZFSの採用範囲を広げるとしており、順次新しいUbuntuでZFSの利用を
拡大することが予想される。また、デスクトップ版は最初の取り組みとしており、今後
サーバ版にもZFSの適用が拡大する見込み。ZFSは人気の高いファイルシステムであり、
多くのユーザーに歓迎されると思われる。

LinuxにおけるZFSの利用に関してはライセンスにおいて長い間疑念が存在している。
Canonicalは数年前にライセンスに関して調査を行い、LinuxにおけるZFSの利用はライセン
ス違反にはならないという結論を出しており、それ以降、UbuntuでZFSを利用するための
取り組みを続けている。

ZFSはモダンなファイルシステムの1つ。ストレージ・アプライアンスやストレージ・シス
テム、NASで広く採用されている。提供されている機能が豊富で、さまざまな稼働実績が
あり、ユーザーから高い支持を得ている。Linuxディストリビューションの中でも高い人気
があるUbuntuでZFSが利用しやすい状況になることで、ZFSの利用範囲が広がると見られる。
0616login:Penguin
垢版 |
2019/08/09(金) 16:56:19.31ID:9F/SVKov
文字数の割には情報量の薄っすい記事だな。
具体的にどう拡大するのか何も書かれていない。
0617login:Penguin
垢版 |
2019/08/09(金) 19:21:58.09ID:rfEV2Og4
Ubuntu は技術的という意味以外で危ない橋を渡ってくれていいな。
Debian派なので、使ってないが。
0618login:Penguin
垢版 |
2019/08/10(土) 06:20:36.38ID:ZWJAdRCH
LinuxにはXFSやJFSという素晴らしいFSがあるというのに
btrfs(笑)
0619login:Penguin
垢版 |
2019/08/10(土) 23:06:34.79ID:2XkczDqc
そろそろOSやデバイスによらない究極のファイルシステムを誰か作って欲しいわ
0620login:Penguin
垢版 |
2019/08/11(日) 00:16:24.96ID:oUkRG+KV
求められてるものが違うから無理でしょ
0621login:Penguin
垢版 |
2019/08/11(日) 00:55:00.87ID:Uf+U5nYS
そもそもファイルシステム自体がOSの一部だからな
0623login:Penguin
垢版 |
2019/08/11(日) 04:25:14.47ID:ha8y5VIz
FAT32というほとんど全ての環境でサポートされている素晴らしいファイルシステムがあるぞ
0624login:Penguin
垢版 |
2019/08/11(日) 08:25:51.10ID:fbfbhXo0
ていうか「普通に」使う分にはFAT32でも十分な気がする。
そんな馬鹿デカい容量を扱わんし
0625login:Penguin
垢版 |
2019/08/11(日) 09:45:05.49ID:iIn5DM/X
OSの一部というよりOS設計に密結合しとるから、ファイルシステムだけ分離してもあまり意味が無いというか
0626login:Penguin
垢版 |
2019/08/11(日) 13:26:31.69ID:cuLqexzl
理想のファイルシステムって何よ？
0628login:Penguin
垢版 |
2019/08/11(日) 15:23:31.80ID:zxPpiGnO
OSから独立していても、特定のOSや企業が関わると党派性の餌食になって正当な評価が得られなくなってしまうので
具体的にはAppleとMicrosoft
アップルに関わると不当に高評価しようとする勢力によって歪められ
マイクロソフト由来のものは不当に低評価される傾向にある
前者はMac/BSD採用前後のZFSを巡る扱いにおいて顕著であり
後者はNTFSの長年にわたる(低)評価について異論を待たない

まあ平たく言えばゲハ脳のリンゴ信者の声ばかりでかくて実態を反映してない
ノイジーマイノリティうぜえって話で終わる
0629login:Penguin
垢版 |
2019/08/11(日) 20:51:04.63ID:b1ksZLfY
>>626
バグが無くて、使い方によらず高速で、
いかなる時もデータが失われず、
物理的な制限もないとか。

現状の物理的な容量を超えて、
無制限に記録できたりしたら、
喜ぶ人ば多いんんじなかろうか。
0630login:Penguin
垢版 |
2019/08/11(日) 21:29:32.28ID:3JMjmUyB
>>624
FAT32じゃだめ理由は容量じゃなくて、
セキュリティとUnicode対応だよ

セキュリティは、システムドライブとして使うなら必須だが、
いろんなマシンに接続する外部ストレージだと意味ないので無くても良い
でもUnicode対応は必須
0631login:Penguin
垢版 |
2019/08/12(月) 01:09:10.91ID:d4sdreTy
FAT32はUTF16LEに対応している
0633login:Penguin
垢版 |
2019/08/12(月) 02:40:46.93ID:NokuNn6B
>>630
>>631でも書かれてるとおりUnicode対応してると思うけど？
0635login:Penguin
垢版 |
2019/08/13(火) 02:42:34.19ID:aG+MUqdm
exFATが4G超えもUNICODEも対応した理想の外部ストレージ用ファイルシステムになるはずだったんだけどな
ライセンスの問題なのかlinuxではネイティブ対応せず使い勝手が悪い
FAT32がWindows/Linux/MacどころかBIOSが認識してフラッシュの書き換えに使えるのと比べると汎用性が低い
0636login:Penguin
垢版 |
2019/08/13(火) 04:50:56.59ID:hjIX5LBa
>>635
MSの規格を使うと、惑わされてろくなことがない。
0637login:Penguin
垢版 |
2019/08/14(水) 06:07:09.42ID:j+CrCYgD
LinuxでのexFATはもうすぐネイティブサポートされるかもしれない
サムスンがクローズドで開発していたんだけど間違えてgithubに公開したらGPL違反だとバレてオープンソース化した
それをLinuxのメインラインに取り込んでしまおうと言う議論がされている
特許についてはMSが去年OINに参加したから問題ないと思われる
0639login:Penguin
垢版 |
2019/08/14(水) 08:15:42.47ID:wXe1OdwF
そういえばOIN入ってたなmicrosoft
昔はOINの敵だったのにかわったもんだ
0640login:Penguin
垢版 |
2019/08/14(水) 12:22:52.78ID:mQ9mwTdn
Githubで公開しちゃった奴は、こうなる流れを見越していたんか。
0641login:Penguin
垢版 |
2019/08/14(水) 14:26:38.36ID:wc+Iy5bm
公開と言うよりも正義の告発だろう
GPL違反に加担する行為に良心の呵責が耐えられなかったのさ
0642login:Penguin
垢版 |
2019/08/14(水) 21:45:17.18ID:AVLJRAxc
なんか、彼の国らしい話だな
0643login:Penguin
垢版 |
2019/08/15(木) 05:46:12.96ID:W1sEpxJ4
>>637
MSが加盟した時点で、特許問題クリアされてるし、MS側からカーネルドライバーのリファレンス実装や、ユーティリティが出てくるの時間の問題なように思うけど。
0645login:Penguin
垢版 |
2019/08/15(木) 20:20:35.65ID:la00X25b
>>644
あ！
去年の今頃ファイルの上にext4のファイルシステムつくってループバックマウントしたんだけど
またXFSでdropbox使えるようになった！
0647login:Penguin
垢版 |
2019/08/15(木) 23:57:45.40ID:q1J1ZnUl
>>644
homeをnfsマウントしてたらやっぱりDropboxつかえないんだよね？
0648login:Penguin
垢版 |
2019/08/21(水) 22:13:21.76ID:1QPw9kaw
FAT32がUnicodeに（一応）対応していたとは知らなんだ。
0649login:Penguin
垢版 |
2019/08/21(水) 22:36:35.26ID:1QPw9kaw
ついでに言うと日本産業規格で定義されているとも知らなんだ（俺が無知すぎるだけw）
0650login:Penguin
垢版 |
2019/08/21(水) 23:41:34.91ID:M7Fu+WRI
FAT32どころかFAT16もFAT12も同様
0651login:Penguin
垢版 |
2019/08/21(水) 23:51:24.49ID:0CXkpgBN
「どころか」の使い方おかしいだろ
0652login:Penguin
垢版 |
2019/08/22(木) 01:16:51.67ID:dj60c2S0
「AどころかBもX」
と言った時は
「Aは前提として（時として当たり前に）XだがAよりXっぽくないBもまたXである（驚きの感情）」
という含意があるんだから，使い方としては全うな部類だろう。
FAT32はUnicodeに対応してるけど，それより他の機能で劣るFAT16・FAT12にさえUnicode対応である（驚きの感情）
0653login:Penguin
垢版 |
2019/08/22(木) 05:33:27.83ID:1Yr3egmY
流れから、FAT32はJIS規格だけど古いFAT16,FAT12もJIS規格だ（まぁ順当にそうだろう）、という解釈も
0655login:Penguin
垢版 |
2019/08/22(木) 11:06:57.22ID:NSVYAGiU
ファイルシステムはサイズがPBを超えてからが勝負
0656login:Penguin
垢版 |
2019/08/22(木) 12:20:02.77ID:m9kjglry
Unicode対応はFAT12でもVFATなら対応可能って奴じゃないの?
MS-DOSで見ると謎の文字列になるやつ
FreeDOSでもそうじゃなかったっけ?
UEFIはどうだったか覚えてない

>>655
個人で勝負に挑むには、月間の消費電力どれくらいになるんだろう
0657login:Penguin
垢版 |
2019/08/22(木) 12:21:32.17ID:jWTG6YZX
FAT64を作れば最強じゃね？
0658login:Penguin
垢版 |
2019/08/22(木) 12:36:54.87ID:m9kjglry
新たに作らなくてもexFATでいいんじゃね?
0659login:Penguin
垢版 |
2019/08/22(木) 16:22:24.42ID:pq9swZ6w
誰かVirtual Data Optimizerを試した
人はいませんか？RHEL 7.5から使える
重複排除の機能拡張っぽいのだが。

https://github.com/dm-vdo
0661login:Penguin
垢版 |
2019/08/25(日) 20:40:25.94ID:hTk0r0Sf
exFATはほぼFATじゃないでしょ。少なくともFAT32やらとはかなり互換性を失なってる…筈。
0662login:Penguin
垢版 |
2019/08/26(月) 14:38:35.90ID:ebuP7us/
ディスクの扱える最大容量が違うのに
互換性なんて持たせられるはずがないべ
0663login:Penguin
垢版 |
2019/08/26(月) 18:10:15.54ID:Q2M/7GD/
bcachefsの登場で
中身のファイル名が長すぎて解答できないRARファイルが
いよいよ解凍可能になるぜ
0664login:Penguin
垢版 |
2019/08/27(火) 23:26:23.88ID:cl90n3Lm
40年前に100EBのファイルシステムを想定したFS作ってればよかったのに
0665login:Penguin
垢版 |
2019/08/28(水) 00:51:29.92ID:roj4LxzO
そんなの作ってもメモリ不足で使えねえよ
0666login:Penguin
垢版 |
2019/08/28(水) 02:44:43.76ID:K9W23MUl
大容量でもメモリ不足にならないよう作れるだろうに。。
0667login:Penguin
垢版 |
2019/08/28(水) 03:13:56.82ID:XY99YJWD
仮にメインメモリが不足しなくっても上位bitが無駄になりまくって記憶媒体の無駄遣いになってたろう
当時のKB単価知らんのけ？
0668login:Penguin
垢版 |
2019/08/28(水) 03:24:40.69ID:jakMXSf+
俺がコンピュータを使い始めた頃は1MBうん十万なんて時代だったしな
0669login:Penguin
垢版 |
2019/08/28(水) 07:49:31.84ID:j5W+ovEv
ビット単位で惜しんで実装する時代だったな
そんなもん設計しても実装して運用出来るメモリ容量がない
0670login:Penguin
垢版 |
2019/08/28(水) 07:59:58.47ID:db/ocE9c
>>664
64KBあれば個人には使い切れない(笑)
と云われていた時代に何を云うとるか(笑)
0671login:Penguin
垢版 |
2019/08/28(水) 08:09:15.90ID:jUTn4eZr
ﾋﾞﾙｹﾞｲﾂ「640KBのメモリがあれば十分」はデマだった [無断転載禁止]c2ch.net
https://medaka.5ch.net/test/read.cgi/prog/1501886166/l50

ビルゲイツが言ったとされる「640KBのメモリがあれば十分なはずだ」は実はデマでした
本人自ら行っていないと明言しており、第三者の調査でもそのような発言は見つかっていません

http://pc.watch.impress.co.jp/docs/2005/0427/hot367.htm
>　「640KBのメモリがあれば十分なはずだ」なんてことを言った覚えはないんだけど。
>　2005年のWinHECは、ビル・ゲイツ会長のこんなジョークともボヤキとも受け取れる言葉で始まった。

その発言の動画　　　　
https://www.youtube.com/watch?v=ElDgsQAzrLo
> Bll Gates at WinHEC. Claimed to have never said that computer would never need more than 640K memory

インタビューで、そのようなことは言っていないと明言しています。
https://web.archive.org/web/20110202030010/http://www.usnews.com/usnews/biztech/gatesivu.htm
Q. Did you ever say, as has been widely circulated on　
the Internet, "640K [of RAM] ought to be enough for anybody?"

No! That makes me so mad I can't believe it! Do you realize the pain the industry went through while the
IBM PC was limited to 640K? The machine was going to be 512K at one point, and we kept pushing it up.
I never said that statement?I said the opposite of that.

The '640K' quote won't go away -- but did Gates really say it? (ビルゲイツは本当にそういったのか？）
http://www.computerworld.com/article/2534312/operating-systems/the--640k--quote-won-t-go-away----but-did-gates-really-say-it-.html

第三者の調査でも、根拠なしの主張を根拠に主張しているだけ（ループしてる）で
最初の出典が存在しないことを突き止めています。
http://quoteinvestigator.com/2011/09/08/640k-enough/

つまりビルゲイツは「640KBのメモリがあれば十分なはずだ」なんて 一言も言っていません。
これは英語サイトでは当時検証済みの話です。 情弱日本人が知らないだけです。
0672login:Penguin
垢版 |
2019/08/28(水) 08:09:50.50ID:jUTn4eZr
いつの間にか「ビルゲイツ 640KB」で検索したら↑のスレが
一番目に来るようになってるなｗ
0673login:Penguin
垢版 |
2019/08/28(水) 08:20:42.08ID:U92vyvJf
>>667
お前が設計したら無駄になりまくるからといって
それがもっとも効率が良い設計だと思わないで
0674login:Penguin
垢版 |
2019/08/28(水) 08:38:43.64ID:XY99YJWD
>>673
100EBを表現しなければならない可能性のあるとこには必ずそれだけのbitが必要になる筈なんだが
可変長符号化だってコスト0（bit）って訳じゃないんだぞ
0675login:Penguin
垢版 |
2019/08/28(水) 08:47:45.84ID:/ip8C1e4
考え方次第で最初に全サイズを読み込んでそれに基づいたbit割り振るようにすればいいだけなのでは？
0676login:Penguin
垢版 |
2019/08/28(水) 09:27:43.57ID:XY99YJWD
そのサイズは何bitでわかる？ｗ
0677login:Penguin
垢版 |
2019/08/28(水) 10:29:36.59ID:U92vyvJf
>>674
100EBを表現しなければならない状況でそれに必要なbitを使うのは無駄ではない
問題は100EBを表現しなくてもいい状況で無駄に使わないことだろ
0678login:Penguin
垢版 |
2019/08/28(水) 10:33:24.68ID:XY99YJWD
>>677
だから1byteなのか2byteなのか3byteなのかの可変長符号にもコスト掛かるっつってんだよｗ
0679login:Penguin
垢版 |
2019/08/28(水) 11:26:30.77ID:U92vyvJf
>>678
コストが掛かるのは当然だ
コストゼロでなければ「無駄になりまくって」るというならお前の頭がおかしい
0680login:Penguin
垢版 |
2019/08/28(水) 12:33:20.72ID:XjV2vzUW
そもそも容量増加スピードなんてのは予測できるわけでそれに合わせてFSもロードマップ作って拡張すりゃよかったんだよ
0681login:Penguin
垢版 |
2019/08/28(水) 21:30:25.06ID:XY99YJWD
当時のKB単価もビット判定やら何やらに掛かるステートも知らずに、後出しで難癖付けるだけなんて簡単でいいよな
てかそう思ったんならおまえが普及させりゃ良かっただろっていう
0682login:Penguin
垢版 |
2019/08/28(水) 21:35:39.43ID:+xLGKmxQ
今だと瓦HDDに最適化したファイルシステム開発したら歓迎されそう
（もうどこかやってるかな？）
0683login:Penguin
垢版 |
2019/08/29(木) 01:12:11.08ID:VQiAWJJ4
瓦HDDの中でホスト側で制御するものは、その手のファイルシステムを前提にしている
0684login:Penguin
垢版 |
2019/08/29(木) 01:16:27.76ID:VQiAWJJ4
瓦は読み込みと書き込みの最小単位が異なる点でSSDと同じなので
SSD向けのファイルシステムが効果的な可能性が高い
例えばCoWやバケット単位の管理を採用したやつ
0687login:Penguin
垢版 |
2019/08/29(木) 09:17:06.65ID:57E44Kd+
最近は反MSの連中よりMSのほうがOSSに貢献してる
0688login:Penguin
垢版 |
2019/08/29(木) 09:31:29.66ID:oTY9cNJu
ntfsも公開してくれよん
0689login:Penguin
垢版 |
2019/08/29(木) 10:37:08.37ID:IgCGENYH
>>685
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
0690login:Penguin
垢版 |
2019/08/29(木) 11:53:24.06ID:ayv/fTUM
>>688
NTFSは公開してもファイルシステムの高度なセキュリティ能力を
Linuxにマッピングできないのであまり意味がないな
0691login:Penguin
垢版 |
2019/08/29(木) 12:26:30.72ID:5xSjyKa3
>>682
瓦最適化はWDの中の人がbtrfsにパッチ投稿中。
0693login:Penguin
垢版 |
2019/08/29(木) 18:31:46.62ID:3gIOV6hV
>>691
はえー。俺の鯖ちょうど瓦でbtrfsだわ、ありがてえ
0694login:Penguin
垢版 |
2019/08/29(木) 20:54:27.48ID:7ODgbVNJ
>>687
反MSって具体的になに？Oracleとか？
0695login:Penguin
垢版 |
2019/08/29(木) 21:12:57.84ID:V76BsNE3
Windows Storage Server 2016の重複排除機能、優秀すぎてﾜﾛﾀ
0696login:Penguin
垢版 |
2019/08/29(木) 21:56:07.88ID:71eCL6Dr
>>689
どちらかというと、ユーティリティ側の出来がよくなってほしいな(´･ω･`)

今、fsck.exfatがチェック出来るだけ状態だからね。
マウントするだけならfuse経由でできるし。
0697login:Penguin
垢版 |
2019/08/29(木) 22:30:20.18ID:/Ysvkkai
>>695
今のところ重複排除がまともに運用できるのWindows Serverだけだな
ZFSも一応使えるけど使う人居ないだろって感じの実装
0698login:Penguin
垢版 |
2019/08/30(金) 01:10:38.60ID:49Usa2R4
>>690
同じ理由でextXもWindows上では使い勝手が非常に悪い
NTFSもextXもシステムに特化しすぎて細かい仕様がなじまない
低機能なFATがいまもデータ交換用に普及してる理由でもある
0700login:Penguin
垢版 |
2019/08/30(金) 01:18:35.79ID:49Usa2R4
exFATは他の近代ファイルシステムに合わせてメタデータをファイル化したのはいいけど
FATが固定テーブルのままだから空き領域ビットマップも固定テーブルで良かったと思う

あとFATエントリが32bitのままだから16TB超えると影響出始める
リムーバブルで16TBは当分先とは言え将来はわからないぞ
0702login:Penguin
垢版 |
2019/08/30(金) 04:24:29.13ID:itEjT5Wb
>>700
> あとFATエントリが32bitのままだから16TB超えると影響出始める

exFATの理論上の最大ボリュームサイズは128PB（ペタバイト）だよ
128 * 1024TB = 131,072 TB。実装上の問題で 512TBが推奨とされてるけど

https://en.wikipedia.org/wiki/ExFAT
0703login:Penguin
垢版 |
2019/08/30(金) 04:38:30.70ID:itEjT5Wb
なるほど、FAT32は名前に反してクラスタ数として28bitしか使ってなかったのか。（exFATは32bit）
1クラスタのサイズがFAT32は32KBまでだから、FAT32の理論上のボリュームサイズは8TB

exFATでは32bit全部を使うから、これだけでも128TBまで使えることになるが、
さらに1クラスタの最大サイズが32KBから32MBに増えたから、理論上のボリュームサイズは128PBになるんだな

FAT32もexFATも実際の実装はそこまで対応してないから減るわけだけど
将来的に対応の必要性があれば互換性を保ったまま増やせるわけか
0704login:Penguin
垢版 |
2019/08/30(金) 11:49:45.26ID:xVO3b390
>>691
btrfsなんて不安定で微妙なFSじゃなくってext4とかXFSで瓦対応してクレヨン……
と思ったが瓦はCoW向きなのか
だったら仕方ないかorz
0705login:Penguin
垢版 |
2019/08/30(金) 18:29:14.36ID:BfSogZjl
マジかよ今後はexfat一択じゃん
0706login:Penguin
垢版 |
2019/08/30(金) 19:36:46.24ID:wK/ekzyO
でもexfatってジャーナリングファイルシステムじゃ無いんでしょ
0707login:Penguin
垢版 |
2019/08/30(金) 20:17:53.57ID:BfSogZjl
マジかよじゃあexfat要らね
0708login:Penguin
垢版 |
2019/08/30(金) 21:52:37.76ID:xOfxtSvx
やっぱりntfsが最強だな
0710login:Penguin
垢版 |
2019/08/31(土) 01:01:49.85ID:PjcUVRL7
xfsのCoWがどんな感じかだな
btrfsはCoWだけじゃなくパケットライトのような構造でSSDへの負担の軽減と効率化を図っている
副作用でデータベースのようなランダム書き換えを繰り返す用途と非常に相性悪いけどな
0711login:Penguin
垢版 |
2019/08/31(土) 07:09:26.49ID:R786WVAl
>>706
> でもexfatってジャーナリングファイルシステムじゃ無いんでしょ

ジャーナル対応は可能だよ。
0712login:Penguin
垢版 |
2019/08/31(土) 09:11:35.30ID:PjcUVRL7
可能なのと実装しているのは大きく違う
ext2にジャーナルファイルを追加してext3としたように後付ならどうにでもなるが
それでも名前を変えるレベルの変更になる

互換性が重要なリムーバブル向けで大きな変更はできないだろうな
exFATは冒険を避けたのか内部的にはけっこう中途半端な拡張になっている
0713login:Penguin
垢版 |
2019/08/31(土) 11:53:17.85ID:M9ADFjBr
ディレクトリエントリ構造がvfat引き継いでんのがクソ
0715login:Penguin
垢版 |
2019/08/31(土) 14:12:33.52ID:JnSDyXRZ
kwskっていうのはクソの理由だぞ。
vfat引き継いでるということの説明をされても
クソの理由にはならないからな
ってかvfat引き継いでないがなｗ
0716login:Penguin
垢版 |
2019/09/03(火) 17:02:34.99ID:yL/ahKNe
Linuxに関して言えば，
組込みLinuxが入ってる携帯端末とかはexFATを採用しそう。
そうじゃないのはXFSやext4でいい(「でいい」というか，「が十分使える計算機資源がある」
0717login:Penguin
垢版 |
2019/09/03(火) 17:44:40.69ID:xfgJCc5v
exFATを使うというのが単に外部ストレージのファイルシステムとして受け付ける(マウントして読み書きに対応できる)という話なら対応が進むだろうが、
システムやユーザーディレクトリがexFAT上に置かれるようになる、システムパーティションとしてexFATが採用されるという話なら、それは無いんじゃないの？

システムパーティションとしてFATやexFATを利用可能な実装、あるならそれがデフォルトの実装というものが実在するなら、むしろ見てみたい(提示して欲しい)。
パーミッションなにそれという無法の罷り通る組み込み実装というものが実在するなら恐ろしい話だ。

NTFSならUNIXの(POSIXの)パーミッション機能を全て内包した上でより高度かつ緻密な権限設定なども可能だが、それらの機能をUNIXからは満足に扱えず持ち腐れるしかないし、
NTFSをシステムパーティションとして設定可能なディストリというものも記憶に無い(Windowsとの共存を念頭に既存のNTFSパーティション内に構築されるものならあったが)
0718login:Penguin
垢版 |
2019/09/03(火) 19:05:09.69ID:B9+IOgvJ
Androidではf2fsとext4が使われているな
これは端末によって分かれる
それとユーザー領域にsdcardFSとか言うのが使われている
0720login:Penguin
垢版 |
2019/09/03(火) 20:37:54.95ID:2aAU5+p7
>>717
今でも使えるか知らないけどUMSDOSというFAT用の拡張があるよ
仕組みはVFATのような感じで長いファイル名とパーミッション等を使える

いにしえの文書
ttp://archive.linux.or.jp/JF/JFdocs/archive/UMSDOS-HOWTO.html

それとNTFSのACLと同等の機能はXFS等でも使えるようになっているよ
0721login:Penguin
垢版 |
2019/09/03(火) 20:56:32.09ID:2aAU5+p7
>>717
ACL関係もいにしえの文書だけど
ttps://www.itmedia.co.jp/enterprise/0403/06/epn01.html

POSIX ACLはSamba以外では積極的に使われない機能だから
あまり解説されていないだけ
0722login:Penguin
垢版 |
2019/09/04(水) 01:58:46.87ID:AfE9OQrQ
>>721
NTFSと同等なのはPOSIX ACLじゃなくてNFSv4 ACLとか、HFSやAPFSに実装されている方
0723login:Penguin
垢版 |
2019/09/09(月) 22:59:51.66ID:SszYAJmS
互換性は別にして、機能としてPOSIX ACLになくて、NTFSやNFSv4 ACLにある物って何があるの？
デフォルト値とかが違ってWindowsと全く同じ挙動にはできないけど、機能的には同等だと思ってた。
0724login:Penguin
垢版 |
2019/09/10(火) 02:47:59.60ID:7v2JkFhP
>>723
POSIX ACLはパーミッションの素直な拡張で、
・ユーザーやグループ毎にRWXの3種類の許可のオンオフ
・ディレクトリにデフォルト値を設定して子孫に継承させる
だけ。

NTFSの方は、そもそも権限が13種類ぐらいあって複雑怪奇。例えば、
・属性(タイムスタンプとか)の読み込みだけ許可
・ファイルへの追記だけ許可(上書きは不可)
・ファイルは作れるけどサブディレクトリは作れないディレクトリの実現
・ファイルの削除権限をファイル自体に設定
・ファイルを作れるけど消せないディレクトリの実現
・ACL自体の変更権限や所有者の変更権限を設定
などが可能。継承も、
・ファイルとディレクトリで別々に設定
・子には継承させるが孫には継承させない設定
ができる。更に
・許可/拒否の設定が両方ある
・ACLの適用順を明示的に設定できる
ので、ホワイトリスト式とブラックリスト式を複雑に組み合わせられる(これはGUIでは設定不可で、コマンドでやる)
0725723
垢版 |
2019/09/10(火) 03:14:54.16ID:ux9dqJdd
>>724
おお。確かに全然違う。NTFSそんなに機能あったのか。
勉強になった。ありがとう。
0726login:Penguin
垢版 |
2019/09/10(火) 04:08:11.19ID:QHsS5imR
機能的にはミニコンやメインフレームで大規模なDB載せるような用途にも対応できるような作りだしねえ…
これでもう20年も実績あるんだから、いっぱしのファイルシステムですな >NTFS
0727login:Penguin
垢版 |
2019/09/10(火) 04:31:51.09ID:c/QawrHU
そのNTFSの機能はだいたいZFSで網羅してるな
0728login:Penguin
垢版 |
2019/09/10(火) 05:23:00.38ID:h9c2d3nY
ZFSで網羅してるとして、何のコマンドでやるの？
ZFS専用コマンド？
0729login:Penguin
垢版 |
2019/09/10(火) 06:24:47.98ID:hXcE461p
ZFSってIRIX発祥だったように記憶しているのだけど
IRIXはつまり一般的なPOSIXの枠を超えたACLを独自に実装していたということですかね？
0731login:Penguin
垢版 |
2019/09/10(火) 06:41:05.19ID:c/QawrHU
>>730
自己レス
ごめん
chmod A3=user:venkman:read_acl:allow filename はSolaris
freebsd はsetfaclでやる実装だった「
0732login:Penguin
垢版 |
2019/09/10(火) 13:55:09.50ID:6sIzNa2X
> 729

XFSはIRIX
ZFSはSolarisです。
0734login:Penguin
垢版 |
2019/09/10(火) 16:55:49.82ID:+5M9tkhk
>>724
詳しい解説サンクス！
多すぎて頭がフットーしそうだよお
0735login:Penguin
垢版 |
2019/09/10(火) 16:56:33.60ID:+5M9tkhk
>>730,731
こっちも詳しい解説サンクス！
0736login:Penguin
垢版 |
2019/09/10(火) 19:00:28.68ID:nfLMQN5s
>>732
ああそうだ、IRIXはXFSだったわごめん
おれ個人では普通に信頼してるFSだけど、Linux界隈では個人だと使ってる人あまり見ないよね…
0737login:Penguin
垢版 |
2019/09/11(水) 01:29:58.78ID:U4ts0n/J
LinkStationのデフォルトがXFSだったはずたから知らないうちにXFS使ってる人は案外いそう
0738login:Penguin
垢版 |
2019/09/11(水) 02:15:06.94ID:XGTr0XqS
CentOS7のデフォルトがXFSだから、個人でも使っている人は沢山いるはず
0739login:Penguin
垢版 |
2019/09/11(水) 09:22:32.33ID:Im0aUzbI
NTFSってマジで「多」機能なんだな
0740login:Penguin
垢版 |
2019/09/11(水) 20:34:04.82ID:U4ts0n/J
多機能すぎてその詳細を理解してる人も使いこなせる人も少ない…MSにさえ
おまけにフルに機能使いこなそうと思ったら非公開API使わなきゃいけないとかいう残念さ
0742login:Penguin
垢版 |
2019/09/12(木) 08:02:48.44ID:A7RqdNx4
素直にXFS使っとけ
0743login:Penguin
垢版 |
2019/09/12(木) 14:07:40.59ID:kpioEvUr
XFSは多機能すぎて誰も使いこなせない
0744login:Penguin
垢版 |
2019/09/13(金) 10:02:05.12ID:/kG8R/3p
LinuxのXFSにもGRIOあるのかなぁ
0745login:Penguin
垢版 |
2019/09/15(日) 08:26:10.55ID:A0tbtNjH
EROFSがLinux5.4でメインライン入りするらしい
リードオンリーファイルシステムだから使いどころは限られるが
すでにスマホで動いているので実績はある
0749login:Penguin
垢版 |
2019/09/16(月) 01:54:38.69ID:rJPiMVYE
huawaiのスマホのsystemパーティションでEROFS使われてるのか
androidのsystemは元々リードオンリーでマウントされてたから有用だろうな
0750login:Penguin
垢版 |
2019/09/16(月) 21:49:59.06ID:8Mnz6MjR
くだらない質問で恐縮なのだが、
既存の、RW可能なファイルシステムで作成したボリュームをROでマウントするのはわかる。

しかしリードオンリーのファイルシステムとなると、
マウントするボリュームは、一体どのような手段で作成されるのだろうか？

卵が先か、鶏が先か…
0751login:Penguin
垢版 |
2019/09/16(月) 22:16:57.15ID:Fjxy1taP
>>750
.iso (ISO9660 ファイルシステム、DVD-ROM 等に使われるリードオンリーのファイルシステム)
ファイル作ったことないですかそうですか
0752login:Penguin
垢版 |
2019/09/16(月) 22:20:45.35ID:M+XuPW8F
>>750
別のファイルシステムから変換するのでは？
少なくともISO9660はそういう感じだよね。

原理的に、仕様がわかっていて、どういう風にファイルを用意したいか決まっていれば、
ビット列は生成可能なのだから、鶏が先か、卵が先かという問題ではないような気がするけど。
0753login:Penguin
垢版 |
2019/09/16(月) 22:23:33.54ID:v2xaK5dV
erofs-utilsに入っているmkfs.erofsで作るらしい

ttps://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/tree/README
0754login:Penguin
垢版 |
2019/09/17(火) 00:23:24.54ID:tEkIjiM2
>>750
いや、roなファイルシステムも使用時にroでマウントしてるだけで
作成時はイメージファイル上にFSを作ってrwマウントしてファイルコピーするだけ
0755login:Penguin
垢版 |
2019/09/17(火) 02:01:04.20ID:C2z//eYW
>>753
圧縮の有無に違いはあるけど、使い方はSquashFSみたいな感じらしい
0756login:Penguin
垢版 |
2019/09/17(火) 09:41:47.16ID:mAQfPWIi
>>754
なるほど，まあ当然っちゃ当然そうだよな。
0757login:Penguin
垢版 |
2019/09/17(火) 12:22:17.37ID:8KO1t32N
>>754
isofsはwrite()が実装されてないらしいし、rwマウントしてコピーってのはちょっと違うのでは？
0758login:Penguin
垢版 |
2019/09/17(火) 21:24:20.70ID:2Wuln3eF
fuseとかでrwマウント出来るようにした物はあるだろうけど、最初からrwでマウント出来たらroファイルシステムじゃないだろｗ
0759login:Penguin
垢版 |
2019/09/17(火) 22:27:12.02ID:q0qVtnVz
ro専用のファイルシステムって、誰が書き込むの？
0760login:Penguin
垢版 |
2019/09/17(火) 22:50:56.62ID:uhDzaob2
mkfsが｢XXバイト目にマジックナンバー書き込んでYYバイト目にはこのフラグの値書き込んで｣みたいにやってる時に一緒にファイルも書き込むだけ
0762login:Penguin
垢版 |
2019/09/21(土) 23:27:31.72ID:bKqCk4Ie
重複排除なんてバックグラウンドでやればいいだけじゃないの？
0763login:Penguin
垢版 |
2019/09/22(日) 05:53:45.18ID:CqaW/Zfz
今時のバックアップソフトや専用NASはリアルタイムに重複排除出来る
0764login:Penguin
垢版 |
2019/09/30(月) 15:09:29.89ID:/fxpH8Tk
>>762
重複するデータが既にストレージ上に存在するのなら後続の書き込みは行われないのが理想
0765login:Penguin
垢版 |
2019/10/01(火) 01:58:35.48ID:xLonTYnk
>>764
コピーするときだけで十分だろ
どうせ上書きしたら内容は変わるんだし
0766login:Penguin
垢版 |
2019/10/01(火) 02:38:11.33ID:C0EfQGgt
重複データは書き込み時に判定というのは実際どう判定するのか
書き込み前に一度ファイルを舐めて双方のハッシュでも比較するのか、すごい手間だな
そんなものシステムワイドでファイル作成時や最終書き込みの時にハッシュ引いてファイルの属性データの方に持たせておけばいいのに
それでもハッシュの衝突とか無いとも限らないしな…どうやって検出すればいいんだ

…などと考え始めると眠れなくなる
0767login:Penguin
垢版 |
2019/10/01(火) 03:54:30.13ID:O/YTzUB3
うん、だからバックアップでやればいいんじゃねーのって思ってる
最終的にはファームウェア側で実装するのもありかもね
0768login:Penguin
垢版 |
2019/10/01(火) 04:01:48.13ID:O/YTzUB3
>>766
ファイルレベルでハッシュ比較しても駄目だよ。
少しデータが変わっただけの巨大なファイルで重複排除ができなくなる。

でもまあそういう例って仮想イメージのスナップショットぐらいしか無いんだよねｗ
んで、仮想イメージは仮想マシン側がスナップショットを差分で保存してくれるから関係ない

ファイルレベルならバックグラウンドでファイル検索して
ファイルサイズが同じ→中身を比較→全部一緒ならハードリンクにする
これだけで十分だろう
0769login:Penguin
垢版 |
2019/10/01(火) 04:34:23.91ID:LD5IBfg0
ログファイルとか重複排除すると効果大きいんだけどな
一般家庭の用途だとストレージのほとんどがメディアファイルで埋まるから効果薄いよね
0770login:Penguin
垢版 |
2019/10/01(火) 08:13:43.35ID:O/YTzUB3
>>769
なんで同じ内容のログファイルが
大量にできるんだ？

圧縮ならまだしも何の意味もないだろ
0771login:Penguin
垢版 |
2019/10/01(火) 08:17:03.18ID:O/YTzUB3
Windowsは95の時代からドライブの圧縮機能があって
昔はお世話になったもんだが、他のファイルシステムには
そういう機能あるのかな？
0772login:Penguin
垢版 |
2019/10/01(火) 10:03:19.94ID:oU66RV/q
>>770
そもそもファイル単位という前提が間違ってる
0773login:Penguin
垢版 |
2019/10/01(火) 10:26:58.35ID:mUwF5icW
>>772
ブロック単位とか言いたいんだろうが、何単位であっても
ログファイルなんて同じ内容にはまずならんだろうが

1バイト違っていたりアドレスがずれてるだけでも
だけでも違うものと判断されるんだからさ
0774login:Penguin
垢版 |
2019/10/01(火) 22:11:05.16ID:d4igWScA
ZFS とか重複排除はかなりメモリ食うらしいね

NTFS は指定日数経過後のファイルに対してだけ実行するとか
バックグラウンドで実行/高負荷時には実行しないとか
使用メモリ制限とか色々オプションがあるみたい

モードも一般/VDI/バックアップと用途向けに用意されてる
中小規模、ホームユースで考えると NTFS の方式はわかりやすくて
かつ優秀だと思う
0775login:Penguin
垢版 |
2019/10/01(火) 22:33:23.76ID:acLZahM8
確かNTFSの重複排除は対象ディスク領域1TiBあたり1GiBのメモリを確保することが推奨されていて、
これはZFSでの重複排除使用時の推奨値と変わらないはずですよ。

重複排除での処理単位のブロックサイズが同じ程度なら、
管理情報のオーバーヘッドはそれほど変わらんでしょう。
0776login:Penguin
垢版 |
2019/10/01(火) 22:34:34.00ID:acLZahM8
あ、推奨値じゃなくてこれぐらい消費しますよの目安だったかも。
0777login:Penguin
垢版 |
2019/10/01(火) 23:59:37.95ID:d4igWScA
>>775
メモリ使いすぎないオプションもあるよって書いたんだが...
0778login:Penguin
垢版 |
2019/10/02(水) 10:24:24.64ID:MFUU2o8w
NTFSって複雑奇怪な仕様のくせにムダに安定してるよな
0779login:Penguin
垢版 |
2019/10/02(水) 20:38:07.52ID:gqMjbdgw
NTFSの重複除去処理って理想的な実装じゃね？

https://www.gmo.jp/report/single/?art_id=234

> 重複除去機能はWindows Server2012ですでに搭載されていましたが、
> 最新のWindows Server 2019の重複除去では、重複除去率とパフォーマンスが改善されており、
> ファイル単位ではなくバイナリのデータ単位で重複を検出して除去するため、
> 大幅に重複除去率が向上しています。

> 重複除去は一度設定すればボリューム内のすべてのファイルが対象となり、定期的に実行されます。
> 書き込みごとに圧縮される場合、継続的なパフォーマンスの懸念がありますが、
> 重複除去はスケジュール設定が可能なため、慢性的なパフォーマンスへの影響を回避することができます。
0780login:Penguin
垢版 |
2019/10/03(木) 00:59:58.79ID:OEBySPhx
NTFSは本当に優秀だ
NT3.1の頃から業務で使っているが、FS起因でのトラブルには一度も遭遇したことがない
さすが天才カトラーが設計しただけある
0781login:Penguin
垢版 |
2019/10/03(木) 02:03:54.40ID:7cVKYu14
MSの開発者のスキルは世界一だからね
本当凄いよ
0782login:Penguin
垢版 |
2019/10/03(木) 08:52:36.44ID:tzg7uxom
優秀つっても Isilon や NetApp とかの後追いじゃないか？
OneFS, WAFL, NTFS 以外は完全において行かれた感がある。
zfs や btrfs はそれなりに資金力ある企業傘下だったが残念だ。
0783login:Penguin
垢版 |
2019/10/03(木) 08:52:50.20ID:47VJX03k
昔との互換性を重視して、仕様は謎みたいな話もあったけどNTFSは問題ないのか？
0784login:Penguin
垢版 |
2019/10/03(木) 15:39:46.94ID:06JgUDhC
zfsはSunがあんなことにならなければ…
0785login:Penguin
垢版 |
2019/10/05(土) 20:56:50.83ID:6SloAFsk
NTFSの仕様はマジで謎。
0786login:Penguin
垢版 |
2019/10/22(火) 03:48:30.37ID:sLMeSFJA
Ubuntu 19.10でZFSをルートファイルシステム利用やっとかよ
0787login:Penguin
垢版 |
2019/10/22(火) 04:05:31.06ID:sWREnU7X
ルートにzfs使うことある？
0790login:Penguin
垢版 |
2019/10/24(木) 07:14:24.88ID:e5plJI2y
ZFSの優秀さはメモリと引き換えなのでパソコンクラスのメモリ量だとあまり使えない
0791login:Penguin
垢版 |
2019/10/24(木) 14:36:52.38ID:87akmZa+
パソコンクラスってよく分からない表現だな
今のサーバーはほとんどPCサーバーになってきてるのに
0792login:Penguin
垢版 |
2019/10/24(木) 15:34:41.99ID:V0q9EpU/
パーソナルなやつだろ
0793login:Penguin
垢版 |
2019/10/24(木) 19:01:35.46ID:XtN2MzoY
ZFS出た2005年当時のメモリなんてどれだけだったと思ってるんだ
0794login:Penguin
垢版 |
2019/10/25(金) 09:09:25.10ID:Krt8XDYr
うちのパソコンはメモリ512GBだけど足りないかな？
0795login:Penguin
垢版 |
2019/10/25(金) 09:54:42.46ID:dtRwUszk
OpenZFSはメモリ要件が改善されたらしくはあるけど
キャッシュヒットが環境によって変わるとはいえメモリの必要量が明確に分からないのは正直つらい
L2ARCの追加もメモリ消費するらしいから安易にできないし
でもZILとかスナップショットとか透過圧縮とか使いたい
0796login:Penguin
垢版 |
2019/10/25(金) 10:31:10.97ID:fu1VNf4G
NASでZFSのdedup onで使ってるけど2TBでメモリ10Gも使わない
メモリ512GB積んでおけば100TBぐらいまでは対応できそうだから個人だとこれで十分そうだ
0797login:Penguin
垢版 |
2019/10/25(金) 13:35:51.25ID:+KpuEA9M
重複排除設定で使用済みブロックが2TBも使ってるなら相当ゴツいシステムだな
0798login:Penguin
垢版 |
2019/10/25(金) 23:24:59.22ID:IP6r7udF
重複排除ってサイズが1バイトずれてるだけのやつも
排除してくれるの？
0799login:Penguin
垢版 |
2019/10/25(金) 23:52:06.19ID:dtVaeIT3
な訳ねー
0800login:Penguin
垢版 |
2019/10/25(金) 23:54:37.46ID:IP6r7udF
あんまり排除できなくないか？
同じファイル見つけたらハードリンクに
置き換えるツールで十分そうｗ
0801login:Penguin
垢版 |
2019/10/25(金) 23:57:34.59ID:dtVaeIT3
そうだよ、専ら仮想鯖みたいな同じユーザランドが無数に作られる様な用途を想定してるんだろう
0802login:Penguin
垢版 |
2019/10/26(土) 01:22:02.81ID:vQVY0Sjj
一日1万枚ぐらいエロ画像を漁ってると20%ぐらいはかつて落としたエロ画像だったりするから
重複排除は容量の20%ぐらい浮く計算になる
0803login:Penguin
垢版 |
2019/10/26(土) 01:25:37.95ID:bm797MDp
>>802
そういうのって重複ファイル削除ツール使えばいいだけなんじゃない？
重複させておく必要ないでしょ？
0804login:Penguin
垢版 |
2019/10/26(土) 01:29:08.15ID:Pwsut+Es
重複排除はリアルタイムである必要はないわな
ZFSが採用しているようなリアルタイムでの重複排除はメモリを食うし
デスクトップ用途ではデメリットの方が大きい。
XFSの重複排除はパフォーマンスに影響しないし実際に使っているけど便利だよ。
0805login:Penguin
垢版 |
2019/10/26(土) 02:04:42.61ID:/XO9wWRE
後で重複を排除するとなると重複かどうかがわからないから結局一度書き込みに行く事になる
zfsはデスクトップ用途だとアレだけどサーバ用途だと理に適ってはいる

あと画像だと今や同じ画像が違うファイル形式であちこちに散乱してたり
同じJPEGでも品質が違ってたりするからあんまし意味ないんじゃ？
0806login:Penguin
垢版 |
2019/10/26(土) 02:47:15.22ID:bm797MDp
でも書き込むたびに、これ重複してるかな？って
確認してたら、書き込みが遅くなるじゃん
0807login:Penguin
垢版 |
2019/10/26(土) 06:32:43.54ID:/XO9wWRE
それを高速化する為にメモリ内にハッシュの類を持ってるんだろうに
0808login:Penguin
垢版 |
2019/10/26(土) 10:45:29.30ID:ZfJ5IMnc
でも書き込むごとに、データのハッシュ値を計算してるんですよね？
0809login:Penguin
垢版 |
2019/10/26(土) 11:39:20.84ID:+7ZIaVI7
>>807
非同期書き込みなら書き込み遅いのは気にならないが同期書き込みについては
遅くなるのは致命的だよな

同期・非同期で重複排除をバックグラウンドでやるかリアルタイムでやるか決め
られるだろうけど仮想環境用途の仮想ディスクとかはその上の同期・非同期って
NAS側まで伝わるのかね

>>808
ZFSの場合はハッシュの計算以外にもRAIDの計算もしているが、それをいうなら
商用NASハードはそれで百本越えのHDDとか面倒みながら処理してるわけで
ハッシュ計算はそんなに負担ではないのでは？
0810login:Penguin
垢版 |
2019/10/26(土) 11:54:16.15ID:kG6Y+7fi
いやめちゃくちゃ負担だけど
やらなきゃ駄目だから
0811login:Penguin
垢版 |
2019/10/27(日) 15:53:27.45ID:eiS+LtlM
>>800
重複排除はファイル単位ではなくブロック単位
もしファイル単位ならそりゃハードリンクと同じだ
0812login:Penguin
垢版 |
2019/10/27(日) 17:06:24.41ID:707D9EX6
異なるファイルでブロックが同じってまずないだろ？
0813login:Penguin
垢版 |
2019/10/27(日) 23:20:14.99ID:3lwG/9wl
それをファイルレヴェルでやってたらでかいファイルの一部が変更されただけで
ハッシュの類を再度算出しなおさなきゃいけなくなる
0814login:Penguin
垢版 |
2019/10/28(月) 00:15:16.75ID:IKPi8ihE
>>812
世代でバックアップとってるファイルとかゲストOSのイメージとか
0815login:Penguin
垢版 |
2019/10/28(月) 20:47:04.72ID:dxvlefLW
ファイル単位の重複排除もあるらしい。
更新されなくなったファイルを圧縮するついでにやる？だったかな。
他にもウイルススキャンとかも定期的に走らせるとかあるからハッシュの
再計算を何かのついでにすることで負担は減らせそうだね。
0816login:Penguin
垢版 |
2019/10/28(月) 22:31:04.60ID:9iH4PItu
>>814
そういうのって仮想マシンソフト側が対応してますよね？
0817login:Penguin
垢版 |
2019/10/28(月) 23:10:44.32ID:WlwazsDj
ファイル単位でやるにしてもどうしても大きさに制限ができる
COWの事を考えるとどうせブロック単位に回帰する
0818login:Penguin
垢版 |
2019/10/29(火) 00:52:41.78ID:fdP/pgCQ
>>816
横から失礼
同じ仮想マシンイメージのPCを移動ユーザープロファイルで利用する
ならわかるが、サーバだと初期イメージから離れていくだけだから
差分に対しては仮想マシンソフト側での吸収は難しいと思うが

>>817
データベースの表領域を考えるとそうだけど、それ故最近アクセスしていない
ファイルに限定してるんじゃないかな
そうなると話は変わって逆に大きさがわかる/ファイルサイズがわかるのは
寧ろメリットになってしまう

ブロック単位に回帰する理由を挙げるならスナップショットやシンプロ
ビジョニング、ブロック単位のレプリケーションなど併用すると効率的な
機能要件挙げるべきかな
0819login:Penguin
垢版 |
2019/10/29(火) 03:00:41.08ID:L6q0zJPq
自宅のCDデータ倉庫で排除率のシミュレーション'(zdb -S)したけど1%も無くてがっかりだった
やっぱZFSの重複排除は仮想化とセットなんかな
バックアップは取得時だけソフトで差分の処理するほうが安くできそうだし
0820login:Penguin
垢版 |
2019/10/29(火) 08:54:54.57ID:tiBJfX00
>>819
zfsは仰る通りだと思う。
コピーオンライトのお陰でスナップショットが高速・少容量な感じに仕上がってる。
0821login:Penguin
垢版 |
2019/11/16(土) 21:42:02.73ID:JSAAagCz
重複排除に夢を見ないほうがいいよ
元から圧縮をはじめとする各方面で無駄を無くす努力がなされている現状で
小手先の策は効果がない
0822login:Penguin
垢版 |
2019/11/20(水) 20:25:14.01ID:6yGwAp7b
そうか？今日保存したエロ画像は以前見てHDDのどこかに保存したような気がするんだが
0823login:Penguin
垢版 |
2019/11/20(水) 20:40:58.51ID:oxDwVSd5
同じ画像に見えてもバイナリ的に同一じゃない要素があってなぁ
というかそういう画像を探すための同一画像判定をしてくれるアプリがあったな
0824login:Penguin
垢版 |
2019/11/21(木) 05:47:34.09ID:FXPGTnmV
画像はまだいいけど同一の動画を判定するのは難しそうだなあ
できるソフトあるのだろうか？
0825login:Penguin
垢版 |
2019/11/21(木) 09:09:11.59ID:xIJF9Sc2
Googleなら持ってるだろうが
0826login:Penguin
垢版 |
2019/11/21(木) 09:58:12.19ID:qhCu6Ui0
おれは一期一会派だから
0827login:Penguin
垢版 |
2019/11/21(木) 20:44:46.78ID:FOikuE8m
>>826
年々規制が厳しくなるからいつか後悔するぞ
0828login:Penguin
垢版 |
2019/11/23(土) 07:34:28.58ID:RKp6gT6E
すでに御禁制の品です
0829login:Penguin
垢版 |
2019/11/26(火) 09:21:12.69ID:WiM8NUkS
>> 826

俺は市毛良枝派だった。
0830login:Penguin
垢版 |
2019/11/26(火) 19:19:34.18ID:dryjMwbD
仮想マシンのイメージのように重複排除が効果的なものはあるけど
そういうのは個別に専用の仕組みで対応したほうが早い
例えば掲示板の画像なら重複を探してハードリンクを貼るスクリプトを定期的に回すだけで事足りる
一応btrfsは重複ブロックを探して共有するプログラムが用意されている

さまざまなリスクと制約を負ってでもリアルタイムにファイルシステムでやる必要性が少ない
0831login:Penguin
垢版 |
2019/11/26(火) 22:41:02.69ID:KV/Dsi98
>>830
いやそれだったら画像を保存するだけのプール作ってそこだけdupすればいいだけ
0833login:Penguin
垢版 |
2019/11/27(水) 01:10:07.14ID:vV9+H2A1
これでexFATが汎用性最強になったね
0834login:Penguin
垢版 |
2019/11/27(水) 01:36:26.23ID:twkxM08i
でもジャーナリングファイルシステムじゃないからなぁ
0835login:Penguin
垢版 |
2019/11/27(水) 01:39:22.97ID:BHucuGJr
全く用途が違うだろ・・・
何を見当違いな
0836login:Penguin
垢版 |
2019/11/27(水) 03:08:57.62ID:zVRigbnf
そう言えばRaiserさんはFS開発に戻らないんだろうか
0837login:Penguin
垢版 |
2019/11/27(水) 07:27:41.14ID:yuP2HKak
そもそもSDXCカードの標準に採用されてるのに読み書きできない方がおかしい
0838login:Penguin
垢版 |
2019/11/27(水) 10:28:42.57ID:aEg54iqa
fatは先頭からデータ埋めてくだけだったけどexfatはそのへんどうなの?
0839login:Penguin
垢版 |
2019/11/29(金) 08:14:02.98ID:Vz7mdWod
スパースファイルのことなら対応してない
アロケーションのことなら実装次第でFATと変わらんだろう
メタデータの一部がファイル化してるが位置がころころ変わるものじゃないから断片化には影響しない
0841login:Penguin
垢版 |
2020/01/01(水) 11:10:00.15ID:scCDRay6
https://www.phoronix.com/scan.php?page=news_item&;px=Reiser5-Development

> Reiser5 File-System In Development - Adds Local Volumes With Parallel Scaling Out

> Hans is still serving his fifteen year sentence until 2023 for
> murdering his wife but can see parole eligibility as soon as next month (January 2020).

Hans Reiser仮釈放でReiser5爆誕
0842login:Penguin
垢版 |
2020/01/01(水) 12:31:59.53ID:20dym0cL
まじかｗｗｗ　まさか復帰するとは思わなかった
0843login:Penguin
垢版 |
2020/01/01(水) 21:13:48.67ID:p37tb7FW
キラーFSになるな
0844login:Penguin
垢版 |
2020/01/11(土) 02:19:39.98ID:UAAx1hWz
2020年1月10日　Don't use ZFS ―Linus，ZFSをマージしない姿勢をあらためて強調　階戸アキラ
https://gihyo.jp/admin/clip/01/linux_dt/202001/10

「Don't use ZFS. ―ZFSは使わない。その理由はシンプルだ。ZFSはこれまでずっと，バズワード以上の
何物でもなく，そして実感するのだけど，例のライセンシング問題は僕にとってZFSを価値のない存在と
思わせるだけだ」

1月6日，IT業界に特化したオンラインメディア「Real World Tech」のフォーラムで繰り広げられたある
スレッドにて，Linus TorvaldsはZFSをメインラインにマージする予定がないことをあらためて明確に主張
している。(中略)

今後のZFSの扱いについては「Oracleの正式なリーガル担当者が署名したオフィシャルレターが届くか，
もしくはラリー・エリソン自身が“⁠ああ，いいよ，手続きを進めよう⁠”といってZFSをGPLにするか，そういう
事態でも起こらないかぎり，僕はZFSに関するいかなる成果もマージしない」と強調，つづけて「ZFSの
コードやインタフェースを取り入れたければ，個々の環境（ディストリビューションなど）で好きにやるのは
かまわないが，訴訟好きなOracleの体質，さらにはライセンスに関する数々の疑念を考慮するなら，僕は
とても安心してそれをやる気にはなれない」とZFSをメインラインに取り入れない理由を説明している。

また，ZFSを直接カーネルに統合しないだけでなく，Shimレイヤのような透過的なインタフェースを通した
実装にも「まったく興味がない。我々にとってなんの価値もなく，Oracleに（Javaのような）コピーライト
訴訟のよいきっかけを与えるだけ」と一刀両断している。

旧Sun Microsystems由来のファイルシステム技術であるZFSに関しては，何度となくLinuxカーネルでの
実装が議論された過去があり，たとえばUbuntuでは2016年ごろからZFSをサポート，最新版の「Ubuntu
19.10」ではZFSをrootファイルシステムにしたインストールが可能となっている。Linusはこうしたディストリ
ビュータの動きに関しては「やらないほうがいいと思うけど，自分たちの責任でやるなら好きにやれば」という
スタイルを通してきたが，今回あらためてZFSのメインライン統合に対し，明確なNoを突きつけたといえる。
0845login:Penguin
垢版 |
2020/01/11(土) 04:42:55.15ID:jnlXzU71
マージ無いのはまあ当然だろう
ZFSの為だけに全てのコードをリスクに晒すわけにはいかない
0846login:Penguin
垢版 |
2020/01/11(土) 13:42:21.31ID:6TxpLfrk
枯れたjfsで運用しとる奴居らんの？
0847login:Penguin
垢版 |
2020/01/11(土) 13:44:36.61ID:6TxpLfrk
LinuxはSiliconGraphics謹製のxfsと添い遂げろ
0848login:Penguin
垢版 |
2020/01/11(土) 14:05:29.73ID:+MC8qtlu
jfs いいぞ。
と、言いたいけどAIX由来じゃなくてOS/2からだし
0849login:Penguin
垢版 |
2020/01/11(土) 16:12:02.81ID:ICeSTzlT
OS/2ってHPFSじゃないの？
0851login:Penguin
垢版 |
2020/01/11(土) 18:57:24.78ID:FZkUfr0E
>>849
wikipedia の jfs からだが、

1999年4月、新しい JFS が OS/2 Warp Server for e-business に、2000年10月には OS/2 Warp クライアントに向けてリリースされた。

1999年12月、OS/2 の JFS ソースコードがオープンソースコミュニティに提供され、それを受け JFS の Linux への移植が始まった。2001年6月、JFS for Linux の最初の安定版がリリースされた。
0852login:Penguin
垢版 |
2020/01/11(土) 19:17:27.72ID:ptgZv5Qn
JFSはビデオレコーダーとかのHDDのフォーマットに使われている場合が結構ある/あったか
今はXFSとかか？
0853login:Penguin
垢版 |
2020/01/13(月) 11:25:23.35ID:mGzs+Xmt
>>852
むしろレコーダーにはXFSが使われてるイメージ
0854login:Penguin
垢版 |
2020/01/14(火) 04:51:06.14ID:iZnsu89D
うちにちょっと古めのRegza(TV)が2台があるが、録画HDDが認識されなくなって
xfs_repairで3回くらい復活させたことがあるわ
0855login:Penguin
垢版 |
2020/01/14(火) 08:15:51.05ID:bK6lhlF1
ZFS厨死亡のお知らせ
ttps://www.phoronix.com/scan.php?page=news_item&px=Linus-Says-No-To-ZFS-Linux
0857login:Penguin
垢版 |
2020/01/14(火) 09:01:27.05ID:/3xc9qkj
じゃあbtrfs使いますかって話よ
俺はトラウマあるから無理
0858login:Penguin
垢版 |
2020/01/14(火) 09:36:14.17ID:Tzu77Qmb
>>855
今までと変えるつもりはないからこれ以上話を出すな、ってだけだと思うんだけど
RedHatがxfsベースで似た機能を持ったもの作るのと、ReiserFSがそこまで取り込んでくれるのを期待
0859login:Penguin
垢版 |
2020/01/14(火) 10:05:18.06ID:3ySwGeCo
>>856
法的な問題が解決されない関わらないっていうのを改めて明確にしただけだと思うけど
0860login:Penguin
垢版 |
2020/01/14(火) 11:40:03.53ID:kTd0knbb
ZFSなんかバズワードだって一刀両断は胸がすくね
Macが採用を謳ってからの持ち上げようったらおかしかった
0861login:Penguin
垢版 |
2020/01/14(火) 12:03:54.46ID:Co6d2U6R
linuxではバズワードかもしれないけれど、
FreeBSDなんかは、UFSの代替として一般化してると思うよ。
0862login:Penguin
垢版 |
2020/01/14(火) 14:46:05.21ID:s3yt3V1I
ソースも見ないアホが語っとるわ
リーナスが言ってるZFSはOracleのZFSのことであってOpenZFSではないぞ
0863login:Penguin
垢版 |
2020/01/14(火) 17:03:51.82ID:QOKr6lO9
xfsが進化しまくってるから問題ない
俺も早速1年くらいxfsのcowで使っているけど
btrfsとは違ってド安定で一切不具合はないよ
ただしメモリの使用量はなんか多い気がする
0864login:Penguin
垢版 |
2020/01/14(火) 17:24:05.89ID:vHb4j94C
>>863
xfsは昔からメモリ大好きっ子やけんな
0865login:Penguin
垢版 |
2020/01/14(火) 17:26:23.56ID:t+wcCOjj
スナップショットと圧縮が欲しいんだよー
0866login:Penguin
垢版 |
2020/01/14(火) 17:29:22.78ID:J8UtrzpS
>>862
ライセンスがGPLにならないかぎりは同じこと
0867login:Penguin
垢版 |
2020/01/14(火) 17:38:02.82ID:3ySwGeCo
>>862
誰にアホといってるのか分からんけど
OpenZFSだろうがライセンスが変わらない限り一緒だといってるだろ
0868login:Penguin
垢版 |
2020/01/21(火) 20:00:20.75ID:ugNUCPRp
たとえGPLになって取り込まれたとしてもZFSに使いどころがないわ
ガリガリ読み書きする部分にはメタデータアクセス遅すぎて使えん
ガチ性能と可用性が必要なところはハードウェアRAID組む
ニアライン用なら機能いらんからもっと安定してるやつ使う
0869915
垢版 |
2020/01/21(火) 22:45:23.84ID:iC7ldWE7
LinuxはZFS並みのファイルシステムができるまでまだまだかかりそうね
0870login:Penguin
垢版 |
2020/01/22(水) 00:52:27.43ID:RmlHZiYt
超サーバ用途には使わんし、かと言って一般的なPCじゃ必要メモリが大き過ぎて使えんし、
運用のハードルが高い割には使いどころが難しいのよね
0871915
垢版 |
2020/01/22(水) 00:59:56.25ID:97fPzXLY
使ったことないんじゃない？メモリ2GBでも快適だよ
今時のマシンなら16-32G積んでるしちゃんと使ってみてから評価すればいい
0872login:Penguin
垢版 |
2020/01/22(水) 01:20:43.99ID:sJWFkN+Y
2GBで快適に動くような使い方してるならZFSでなくてもいいのではって思うけどな
0873login:Penguin
垢版 |
2020/01/22(水) 01:58:33.39ID:wZeNZHAR
メタデータ触ると遅いしメモリ食いなのは確かだけどlvmでスナップショットはかなり無理矢理感あるし透過圧縮ないファイルシステムも多い
0874login:Penguin
垢版 |
2020/01/22(水) 07:16:30.83ID:97fPzXLY
snapshot、promote、細かいACL、send|reciveに透過圧縮など非RAIDでも恩恵はでかいよな
0875login:Penguin
垢版 |
2020/01/22(水) 11:38:59.85ID:sjf0Rz/o
>>874
だね
俺はデスクトップユーザーだからそれら機能の簡易版でもあればbtrでもxfsでも構わないのだが
現時点では選択肢がzfsしかない
0876login:Penguin
垢版 |
2020/01/22(水) 16:00:37.59ID:vGgGBPjr
うんうんZFSは素晴らしいみたいだからFreeBSDでつかっててね
0877login:Penguin
垢版 |
2020/01/23(木) 01:55:54.94ID:7qSP8O0Q
FreeBSDもOpenZFSになるのでLinuxで使いますね
0878login:Penguin
垢版 |
2020/01/23(木) 14:10:17.07ID:ZAgXInmL
有料でも良ければGPFSが最強なんだけどねえ
0879login:Penguin
垢版 |
2020/01/23(木) 14:14:08.14ID:ZAgXInmL
今時は1デバイスで100TB、トータル1PBぐらいのシステムを持っている個人も普通にあるよね
そういうとこで実運用に耐えるファイルシステム、って観点だとこれが以外と難しい
0881login:Penguin
垢版 |
2020/01/24(金) 18:35:07.98ID:mXgeSarq
巨大パーティションは下手すればエラーチェックもままならなくなるから
動画用でもない限り1T程度で切ることにしている
0882login:Penguin
垢版 |
2020/01/25(土) 04:40:01.22ID:hgworRLd
重複排除の実装によくハッシュが使われるがハッシュの計算と保存のコストが馬鹿にならない
例えばKSMは最初ハッシュで実装してたのに結局ツリーを作った上で直接比較する方法に変更した
0883login:Penguin
垢版 |
2020/01/25(土) 06:07:36.65ID:v2Q4em8k
NTFSって理論上は64ビットの番地だけど
現在の実装は32ビットなんだろ

(2^32-1)*2048KiBの8PiBくらいしか管理できない
0884login:Penguin
垢版 |
2020/01/25(土) 06:30:47.23ID:RUYaEyw5
そんな容量が要求される様な用途だとReFSが使われるんじゃ？
0885login:Penguin
垢版 |
2020/01/25(土) 07:53:48.04ID:TTbJFqbp
ファイルシステム上には64ビットで書かれてるよ、
読み書きするときに上位の32ビットを0に固定してるだけ。
たしか、4KBクラスタまでの時代で論理限界16EBとか言ってた。
今は2MBだから増えてる？
0886login:Penguin
垢版 |
2020/01/25(土) 10:14:39.57ID:9dDjJPoq
個人だとだいたい100TBもあれば足りるからな
0887login:Penguin
垢版 |
2020/01/25(土) 13:29:15.17ID:FQlZOJvl
まあストレージやメモリのこれだけあれば十分なんて数字は数年で倍になるし10年で2桁変わる
0888login:Penguin
垢版 |
2020/01/25(土) 15:54:16.50ID:Pn3gpz30
世の中にPBクラスの規模で動いてるファイルシステムって実際にあるのか…？
普通はそんな肥大化する前に設計の見直ししないか
0889login:Penguin
垢版 |
2020/01/25(土) 16:15:25.18ID:XUbXy/+j
10年前でメモリ80MBとかPentium IIを10年使っていらしたんですか？
0890login:Penguin
垢版 |
2020/01/25(土) 17:43:01.69ID:FQlZOJvl
10年前だとメイン機のRAMは8GB、サブ機で2GBだったかな
今はメインで64GBサブ機8GBだから、まあ10倍にはなっていないか
ストレージは1TB→20TB

さらに10年前、2000年時点だとRAM256MBストレージ4GB
1990年頃だとRAM4MBストレージ80MBくらいか

10年で10倍、25年で1000倍目安くらいだな
0891login:Penguin
垢版 |
2020/01/25(土) 20:54:00.55ID:9YpFJvCS
>>888
そこまでいくと実質的に青天井だからS3などのクラウドを選択するだろう
もう自前でストレージを持つ時代じゃない
0892login:Penguin
垢版 |
2020/01/26(日) 10:26:40.74ID:AHO9IC4m
>>888
資源系を筆頭にいくつかの業界や世界規模の大手企業ではPBなんて珍しくないよ
そういうところでは単一ネームスペースでアクセスできるところに意味があるからそうなる

>>891
むしろ逆、そこまで大きくなるとクラウドストレージはI/Oが高すぎて話にならなくなる
0893login:Penguin
垢版 |
2020/01/26(日) 11:00:01.44ID:OzJ+Z2xw
>>892
事業の性質によるだろう
多くのBtoCビジネスでは、必要なストレージ容量やIOはユーザー数に比例するから問題ない
それで赤字ならそもそも商売として成立しない
0894login:Penguin
垢版 |
2020/01/26(日) 11:21:19.88ID:kSy9PDTE
>>892
PBクラスのシステムのファイルシステムは実際は Lustre や GPFS
などの分散ファイルシステムで、その中身は ext4 などのファイル
システムを並列に並べたものだから、単一のファイルシステムとしては
PB 超えれてない

ここでの議論は単一のファイルシステムに限定したほうがいいと
思うんだがどうだろう
0895login:Penguin
垢版 |
2020/01/26(日) 11:44:24.23ID:kSy9PDTE
>>893
> 事業の性質によるだろう

具体的にはスパコン(HPC)と映像系だけかな

CIFS/NFS(autofs)/オブジェクトストレージあたりは複数のストレージを
束ねて１つのネームスペースに見せかけられるからそこそこ安定してて
こなれた価格のストレージを並べるから PB のファイルシステムは不要

テキトーなこと言うけど、PB クラスのファイルシステムが必要になる
のは１ファイルがTB超えるとか１バッチあたりの中間ファイルがTB超える
とかぐらいからじゃないかな
0896login:Penguin
垢版 |
2020/01/26(日) 11:53:39.27ID:AHO9IC4m
>>894
LustreもGPFSもPanFSも中身は独自でext4等の下層fsを持たないよ、何か別のものと勘違いしてない？
0897login:Penguin
垢版 |
2020/01/26(日) 12:22:35.09ID:AHO9IC4m
>>895
HPCはそうだけど映像系は実は必ずしも該当しない、ガチなとこは階層化ファイルシステム使うから
日本では技術力がないのか金があるのか知らないけど単一でゴリ押す映像系の話きくけどね

PB越え単一ファイルシステムが必要なのは、一ファイルの大きさが問題じゃなくて
アクセスする可能性があるファイルが大量にあって、かつテープでは遅すぎる場合
だから金融系・資源系・生命系みたいにデータが大量で時間が金に直結するところで良く使われる
0898login:Penguin
垢版 |
2020/01/26(日) 12:26:01.78ID:AHO9IC4m
>>896
おっとすまない、Lustreは下層がext4だった、ごめん勘違いしてたのは俺だった
でもGPFSやPanFSが下層を持たないのは本当
まあ現状エンタープライズのファイルシステムの最前線はGPFS vs PanFSみたいな雰囲気はある
0899login:Penguin
垢版 |
2020/01/26(日) 13:52:42.43ID:kSy9PDTE
>>897
それは失礼。 ちなみに Lustre は ext4 と他に ZFS の実装もあるそうな。

> アクセスする可能性があるファイルが大量にあって、かつテープでは遅すぎる場合

使ってる業種と使い方に異論はないんだけど単一ファイルシステムを使う理由が
それかというとちょっとなんか釈然としないなぁ

結局入力ファイルや中間ファイルを複数のファイルサーバに負荷分散するように組むのが
面倒くさいから使ってるってだけって印象だわ
面倒くさがらなった結果の一つが Hadoop/HDFS だと思ってます、ハイ
0900login:Penguin
垢版 |
2020/01/26(日) 14:09:39.49ID:aLHVJ+JL
1ファイル1'PBのエロ動画とかどうやって保存してるんだろう
0901login:Penguin
垢版 |
2020/01/27(月) 01:02:02.64ID:SjNVe4Yy
>>900
Display Portが2.7Gb/s最大なんで少なく見積もっても823時間分あるんだが
どういう人向けなのか説明Plz
0902login:Penguin
垢版 |
2020/01/27(月) 12:29:14.65ID:0w7PQcpt
>>901
DPは最大25Gbps出るしDSC使えばもっといける
そもそもファイルサイズとモニターへの転送速度は関係ないでしょ？
実際に販売する段階になったらエンコードして小さくするとしても編集前のマスターデータをそのまま保存しておく場合なら再生するモニター以上の解像度、フレームレート、色域が記録されていても保存に必要な容量が用意できれば全く問題ない
0904login:Penguin
垢版 |
2020/01/27(月) 18:07:52.96ID:udH3RDqL
8K24bitの24時間ハメ撮りAVだと無圧縮で計算上約8TBだな
0907login:Penguin
垢版 |
2020/02/02(日) 15:26:44.86ID:U7jFn1mT
RAIDはmd使った方が無難に思える
0908login:Penguin
垢版 |
2020/02/02(日) 17:40:25.51ID:HE+GXCHP
RAID10はmd raidよりbtrfsのほうが安定してる
RAID 1ならmdのほうがいいけど
0909login:Penguin
垢版 |
2020/02/02(日) 23:14:15.47ID:cDfryaOr
>>907,908
md の上に何乗せてるん? ext4? xfs?
0910login:Penguin
垢版 |
2020/02/02(日) 23:40:34.80ID:iaNiREzj
スーパー32Xに決まっておる
0911login:Penguin
垢版 |
2020/02/03(月) 05:01:47.23ID:9XLDxuL9
>>909
RAID1なら何でも乗っける
ESPの多重化もしたいし

それ以外ならファイルシステムのネイティブ機能の方がいいと思う
0912login:Penguin
垢版 |
2020/02/03(月) 11:50:13.47ID:1h1DB/oS
>>910
その発想はなかった。俺は評価する。
0913login:Penguin
垢版 |
2020/02/03(月) 23:45:36.62ID:OVT3+6Po
セガファンは面白いやつ多いのにセガはあれだな
0915login:Penguin
垢版 |
2020/02/11(火) 10:00:56.86ID:JmaZPai6
ZonefsはPOSIXに準拠していないので既存のファイルシステムを置き換えるものじゃないけどな
0916login:Penguin
垢版 |
2020/02/11(火) 22:35:10.14ID:F8Fgy0xz
f2fsじゃあかんのかね
0917login:Penguin
垢版 |
2020/02/15(土) 20:40:39.36ID:ko2/1+4j
F2FSは最大FSサイズが16TBなのがSMR HDDには今後ネックになる
0918login:Penguin
垢版 |
2020/02/15(土) 20:51:22.84ID:fQlV7izm
FlashFriendly File Systemだからな
HDDとか知らんよ
0919login:Penguin
垢版 |
2020/02/15(土) 21:41:41.41ID:7ROaKxuF
HDDも大容量キャッシュ付き瓦だとあんまりfs側でいじらない方がいいような気がする
0920login:Penguin
垢版 |
2020/02/15(土) 23:17:25.45ID:Aj0iDWta
WinFS でやりたかったDB の機能も付いたファイルシステムってあります？
0921login:Penguin
垢版 |
2020/02/16(日) 09:36:26.82ID:tFc9/bu5
>>920
じゃあそれDBでよくね？ってなってどこも開発やめた
0922login:Penguin
垢版 |
2020/02/16(日) 11:11:50.61ID:Cl0cNLYW
最近はDBのためにダイレクトIOのパフォーマンス上げる改善が多い
0924login:Penguin
垢版 |
2020/03/20(金) 16:46:34.76ID:oDz6Qr3S
btrfsはUUIDの変更が鬼門だな
メタデータとUUIDが紐付いているらしくてデータを読めなくなる
0926login:Penguin
垢版 |
2020/03/29(日) 19:29:33.05ID:A9QWVCnu
カーネル5.4で追加されたネイティブexFATは日付の処理にバグ有り

Windows7とfuse-exFATで作成したファイルを5.4のネイティブexFATドライバで見ると、
更新日付がちょうど 1ヶ月＋9時間 遅く表示される
アクセス日付は常に 1979/12/31 9:00:00 と表示される

5.4のネイティブexFATドライバで作成したファイルをWindows7で見ると、
更新日付とアクセス日付がちょうど 9時間 早く表示される
また、5.4のネイティブexFATドライバでマウントしなおすと上記の症状が起こる

つまり、
・読み書き共にタイムロケールが正しく反映されない (日本設定では9時間ずれる)
・読み込みのみ暦月がずれて読み込まれる (書き込み直後はキャッシュされるので症状が見えない)
0927login:Penguin
垢版 |
2020/03/29(日) 19:38:05.23ID:A9QWVCnu
あと、5.4のネイティブexFATは日本語処理は問題なかった
日付のずれは地味に困るから一旦fuse-exFATに戻す
0928926
垢版 |
2020/03/29(日) 20:21:00.98ID:A9QWVCnu
アクセス日付を更新するだけでも更新日付が一ヶ月後ろにずれることも分かった
サムネイル表示機能を有効にしてたから試しに開いたSDカードの日付情報も派手にやられた
0929login:Penguin
垢版 |
2020/04/08(水) 08:54:17.25ID:ctV6ZAP7
Windows10

5000個以上のPDFをAドライブからBドライブに移動させたら、ファイル数はそのまんまなのに総サイズが250MBも減少した
なんで？
0930login:Penguin
垢版 |
2020/04/08(水) 09:48:50.57ID:h2p5sSpc
圧縮ディスクだった
0931login:Penguin
垢版 |
2020/04/08(水) 16:48:38.17ID:nNfYJP3N
Aドライブってフロッピー？
0932login:Penguin
垢版 |
2020/04/08(水) 18:26:58.26ID:9nhczXSy
A側はexfat でアロケーションユニットサイズが 1MB (平均512KB/ファイル余計に消費)で、
B側はNTFSで同サイズが4KBで(同平均2KB/ファイル)だったって感じか？
(意図的にやらない限り 1MB なんて値にはならないはず)

それ以外の可能性としてはA側には隠しファイルがあってサイズは隠しファイル込みだった
0933login:Penguin
垢版 |
2020/04/09(木) 01:04:11.02ID:NYHCWS9d
exFatをWindowsで初期設定でフォーマットするとクラスタサイズが128KiBになる
1ファイルあたり平均64KiB余計に消費するので、64KiB×5000個=約312MiB
>>929 は順当な結果
0934login:Penguin
垢版 |
2020/04/09(木) 01:09:19.65ID:NYHCWS9d
1件1ファイルで保存するタイプのメールデータをexFatに保存すると大変なことになる
(1件ごとにほぼ128KiB無駄になる)
あとNTFSは約700バイト未満のファイルはメタデータに直接格納しちゃうから細かい設定ファイルやらメールデータの収納効率が非常に良い
0935login:Penguin
垢版 |
2020/04/09(木) 08:50:59.38ID:tHpWeU4o
Ubuntu 20.04β試していて初めて知ったんだけどlinux-5.3あたり（？）からNILFS2へ書き込もうとするとクラッシュする（といってもNIFS2を扱っているカーネルのサブシステムだけ）というトラップ（バグ）が仕掛けられてたのね。

/homeをNILFS2で運用していて18.04でバックポートカーネルを入れるとログインできなくなるんで何でだろうと思っていた。
当分18.04+5.0系カーネルで保持かなあ？
0936login:Penguin
垢版 |
2020/04/09(木) 10:29:58.44ID:wTSYL5PJ
NILFS2って保守されてるのか？
いつか消されるんじゃないかと思っているのだけど
0937login:Penguin
垢版 |
2020/04/09(木) 12:30:14.75ID:7wAsdCRN
4TB の外付けHDDを exFAT でアロケーションユニットサイズを NTFS と同じ 4kB で使う場合、
大きなデメリットってある？
それとも、アロケーションユニットサイズを変更するくらいなら、素直に NTFS で使ったほうがいい？

Linux でもネイティブ対応しそうな exFAT を考慮したいけど、
今までの外付けHDDが全部 NTFS なので、
ちょっと躊躇してしまう。
0938login:Penguin
垢版 |
2020/04/09(木) 12:47:50.43ID:f9lVta1Z
数十～数百GB程度ならexFATでも何でも構わんけど
テラバイトサイズのボリュームはジャーナリングファイルシステムでないと怖すぎないか
0939937
垢版 |
2020/04/09(木) 13:13:20.64ID:7wAsdCRN
>>938
確かに、ジャーナルのない点は少し気になるねぇ。

サルベージするときの復元率の違いも気になる。
FAT32 のときは、復元できても断片になることもあった。
もっとも、NTFS の場合、復元できなければ断片すら拾えないという感じだから、
優劣という感じじゃないしなぁ。
0940login:Penguin
垢版 |
2020/04/09(木) 17:40:41.92ID:vpGccY6F
>>936
ジャップ製モジュールはこれが怖い
0943login:Penguin
垢版 |
2020/04/10(金) 16:47:03.88ID:mZNoA7ar
>>937
そのFSを読めるOSが壊れたときなんて想定は別の同じOSを用意すればいいでしかないぞ
0944login:Penguin
垢版 |
2020/04/11(土) 22:41:34.77ID:XDts1cPd
>>937
Windows95/98と同じ程度の信頼性はあるはず
0945login:Penguin
垢版 |
2020/04/24(金) 00:01:20.91ID:OEQFvFGC
CoWはその性質上、空き領域をどんどん上書きするからSSDの速度低下が起きやすいようだ
定期的にトリムした方が良い、例えば毎朝と毎夕
マウントオプションでdiscardオプションを付けても良いがLinuxでは遅くなることが多い

fstrim -v /
0946login:Penguin
垢版 |
2020/05/03(日) 18:58:52.51ID:njMyCBBl
>>935
NILFS2開発者のMLにとりあえずの回避策が流れてた。
起動からマウントまでの間にそのFSのデバイスへの書き込みがあればいいので、
マウントの前に
dd if=/dev/なんとか of=/dev/なんとか count=1
みたいにダミーの書き込みを発生さればいいのだそう。
例えば、fstabから削除かnoautoにしてrc.localとかでdd, mountという流れとか。
0947login:Penguin
垢版 |
2020/05/05(火) 05:14:55.40ID:AUhfSTN7
>>946
ありがとう。

たぶんこれかな↓

https://marc.info/?l=linux-kernel&;m=158825033005228&w=2

自分の場合も/homeがnilfs2なんでどうしたものかな？？？というところですわ。
サブ機のほうはbtrfsに替えてUbuntu20.04に上げたけどメイン機の方はどうするかなあ？
0948login:Penguin
垢版 |
2020/05/26(火) 11:43:00.85ID:1H93WhIH
Btrfsとかzfsって一台のhddだけで運用するのはたいしてメリットないの？
0949login:Penguin
垢版 |
2020/05/26(火) 12:46:01.35ID:+ELcO//y
あるだろ
圧縮とかスナックショトとか 盛りだくさんだわ
>>948
0950login:Penguin
垢版 |
2020/05/26(火) 17:16:39.31ID:o4/8jJLs
デュアルブートしてたらNTFSのMFTがミラー毎壊れたんですけどなんとかMFTを修復できませんかね？
EaseUS Data Recovery Wizardを使うとディレクトリやファイル名がそのままでデータ救出できるんですけど
という事はMFTも修復できるはずですよね？
0953login:Penguin
垢版 |
2020/05/27(水) 12:56:13.77ID:XCSTzVNb
まだ始まったばかりだ！
Oracke先生の次回作にご期待ください
0954login:Penguin
垢版 |
2020/05/27(水) 20:57:11.66ID:acGll7c1
xfsのCoWを有効化したまま1年以上使ったけど時々フリーズするなやっぱり
あとメモリ使用量がちょっと大きすぎるね。
まだまだext4安定の時代は続きそうだ
0955login:Penguin
垢版 |
2020/05/27(水) 21:38:26.52ID:0U4TUkPK
それならBtrfsの方が安定してるな。できたばかりでこれからなんだろうけど
0957login:Penguin
垢版 |
2020/05/27(水) 22:26:06.40ID:sT3KZO5+
ext5開発開始まだー
0958login:Penguin
垢版 |
2020/05/28(木) 05:14:42.87ID:6u6TfIVC
うーむbtrfsで組んでる領域どうしよう
compress標準サポートが貴重なんだけどな。
乗り換え先おすすめ教えてください。
0959login:Penguin
垢版 |
2020/05/28(木) 09:40:13.16ID:lg5ytPVY
なんでBtrfsなんか選択したんや…
0960login:Penguin
垢版 |
2020/05/28(木) 09:46:17.62ID:bvSCyOR7
Synologyが推してるBtrfs
Googleが使ってるBtrfs
0961login:Penguin
垢版 |
2020/05/28(木) 09:54:45.61ID:EreFZKCr
btrfsはヤヴァいと何度言えば（ｒｙ
0963login:Penguin
垢版 |
2020/05/28(木) 11:26:26.96ID:ztRPopnD
なんだかんだでLinuxで高機能モダンファイルシステム使おうと思うととりあえず何も考えずに使えるのがBtrfsなんだよね。
こまめにバックアップ取りながら人柱のつもりで突っ込んだのに、意外と問題出ないし……
0964login:Penguin
垢版 |
2020/05/28(木) 12:31:52.81ID:A6PA4iBR
Google遣ってるならBtrfsの未来は明るいと思ってしまう不思議
0965login:Penguin
垢版 |
2020/05/28(木) 12:36:38.82ID:rCbDOGHF
>>963
俺も数年使ってるけど何も問題起きてないわ
ぼんやり使ってるだけだから気付いてないだけの可能性もあるけど
0966login:Penguin
垢版 |
2020/05/28(木) 14:51:58.35ID:kpVDAvmO
ぐぐたすヲもう忘れたのか?
0967login:Penguin
垢版 |
2020/05/28(木) 16:25:14.77ID:qJC8ExER
IT巨人で信頼できるのはMSだけだわ
Window以外はブッチギリで有能
0968login:Penguin
垢版 |
2020/05/28(木) 22:47:31.09ID:35G/ZT7g
Vista以降のWindowsもNTFSも優秀だよ
今時こんな堅牢なOSちょっと無いよ
0970login:Penguin
垢版 |
2020/05/29(金) 05:52:56.10ID:BCgb8iXY
そんなこと言ったらext4もxfsも使えんぞ
0971login:Penguin
垢版 |
2020/05/30(土) 22:19:12.00ID:rxDacgPJ
ext4もxfsもBtrfs程の問題は抱えてないだろうて
Btrfsは解決の目途が立ってない既知の問題点が多すぎる
0972login:Penguin
垢版 |
2020/05/31(日) 00:36:23.90ID:O/t7Lowh
具体的に何が既知の問題なんだ？
0974login:Penguin
垢版 |
2020/05/31(日) 00:56:48.74ID:O/t7Lowh
>>973
そこ見たら実験的な機能が多いのは分かるけど
普通に使って問題が起きるようなことは書いていないが
0975login:Penguin
垢版 |
2020/05/31(日) 01:04:37.63ID:4i1+bTSg
マウントオプションを貪らずに一切エラーが起きなきゃな
起きた時が問題だからbtrfs checkで全部を直せないとかマウントオプション云々だとか散々警告されてんだろうに
RedHatが匙を投げたって時点でお察し
0976login:Penguin
垢版 |
2020/06/01(月) 15:44:25.81ID:RZhBr4iC
Googleってbtrfs使ってんの？
0977login:Penguin
垢版 |
2020/06/01(月) 18:14:25.85ID:7+mv9XDP
redhat引き合いに出してbtrfsオワコン唱えるやつ多いけどbtrfs開発者がredhatやめたってだけ
んでまともに触れる社員いないfsはサポート無理ってのとチーム内にXFS開発者ならいっぱいいるからだって元社員がいってたぞ

googleは知らんが大御所で使ってる、貢献してるのはfacebookと富士通とかだな
0978login:Penguin
垢版 |
2020/06/01(月) 18:38:32.80ID:uT4k0Fz5
GoogleはChromeOS内のLinux環境で使ってるだけ
0979login:Penguin
垢版 |
2020/06/01(月) 18:40:48.93ID:2PrO6u28
>>978
それってけっこうデカくね？
0980login:Penguin
垢版 |
2020/06/01(月) 19:50:25.67ID:OAVwE/lA
遭遇してもクリーンインスコすりゃいいって程度のシステムならbtrfsでも問題にならんのだろうけどな

redhatの件が無くてもbtrfsは昔からモグラ叩きの繰り返しだし、
未だにRAIDやファイルチェック周辺すら完全にできてないし、どこに地雷があるかわからん
一部のfsのエラーを修復できませんって、そのエラーに遭遇した時にどうすんだよと
0981login:Penguin
垢版 |
2020/06/01(月) 21:36:44.83ID:9JaREmBh
クライアント(スナップショット/RAIDなし)で使えててもファイルサーバで
安心して使えるかというとそうじゃないからなあ
0982login:Penguin
垢版 |
2020/06/01(月) 21:56:25.70ID:2PrO6u28
スナップショットもRAIDも使ったし、オンラインでストレージ構成変えまくったけど問題出なくて（しかも構成変更が柔軟過ぎて）拍子抜けしたんだよなぁ。
ファイルサーバ用途でこそ輝くよこれ（バックアップはこまめにね）
0983login:Penguin
垢版 |
2020/06/02(火) 11:47:13.97ID:6oGgMjKL
ファイルサーバーっていう言葉で考えているものが全然違う二人で会話してる感じがする
0984login:Penguin
垢版 |
2020/06/02(火) 12:27:10.52ID:sg8jbCA1
Terastation クラスの NAS(Btrfs 利用だと Synology の製品)/エントリークラスか
会社のファイルサーバ(Isilon や NetApp やその対抗製品クラス)/
エンタープライズクラスかってことかな

クラウド化やセキュリティ強化が進むにつれてエントリークラスの需要は
落ちる/落ちてるんじゃないかな
0985login:Penguin
垢版 |
2020/06/04(木) 01:47:45.72ID:xNtEdgfL
ノートPCをCoW有効にしたXfsにしてるけど
メモリ使いすぎて本気で後悔してる。
省メモリなFSだとext4が良いのかな？
どこかにFSごとのメモリ使用量の比較データとかあたりしない？
0986login:Penguin
垢版 |
2020/06/04(木) 07:54:18.56ID:gBysGF/t
そんなにメモリ食うの？
0987login:Penguin
垢版 |
2020/06/04(木) 09:23:07.24ID:Bs6FKlOi
信じられないくらい食う
プロセスの合計メモリ使用量は大したことないのに
簡単にスワップ突入するよ。
0988login:Penguin
垢版 |
2020/06/04(木) 09:40:20.48ID:DMZuMarq
CoWとジャーナリングなら比べるのも愚かというレベル
0990login:Penguin
垢版 |
2020/06/04(木) 11:31:13.32ID:DQZXMKEK
>>985
使ってないけどメモリ制限できるんでは？
0991login:Penguin
垢版 |
2020/06/04(木) 12:01:52.27ID:gBysGF/t
dedup使ってるとかでもなしにそんなメモリ食うのか。
Btrfsがメモリ食わないからCoW自体は対してメモリ食わないものだと思ってた
0992login:Penguin
垢版 |
2020/06/04(木) 15:07:25.35ID:x4v3XzWR
CoWを無効にしたXFS使って比較しろよ
0993login:Penguin
垢版 |
2020/06/04(木) 17:36:35.28ID:7r9XEAZX
>>946

これはGood News?

>> Wondering if it can be reproduced on mainline with c3aab9a0bd91
>> ("mm/filemap.c: dont initiate writeback if mapping has no dirty pages")
>> reverted?
>
> For mainline kernels with that commit reverted, this oops actually
> doesn't occur.

https://marc.info/?l=linux-nilfs&;m=159101200114980&w=2
0994login:Penguin
垢版 |
2020/06/05(金) 14:07:47.91ID:jA3wZpDc
>>993 で引用された部分は
「ホントにc3aab9a0bd91なしだと起きないん？」「そだよ」
と言ってるだけだけど、
落ちるまでの流れはわかったっぽいしまだ不安定ながらパッチもできた、
というのが現状かな。
0995login:Penguin
垢版 |
2020/06/08(月) 15:13:54.40ID:PPU2wP+g
>>994
で、もう正式に入れてちょうだいってパッチも出たんだけど、
実質1行追加するだけだった。

こういうパッチ好き。
実際どうかは知らないけど、いかにも問題を追求し切ったって感じがして。
0997996
垢版 |
2020/06/13(土) 14:53:58.96ID:Qx8FdC0t
なぜか、NGに引っかかったので、関連スレの途中までしか書けていません。
あと、リンク切れの場合は、ご容赦ください。
10011001
垢版 |
Over 1000Thread
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 897日 15時間 6分 0秒
10021002
垢版 |
Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニューススポーツなんでも実況