X
トップページ⇒Linux
1002コメント310KB
ファイルシステム総合スレ その18
■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin
垢版 |
2017/12/28(木) 23:50:51.14ID:/phfY+r1
● 前スレ
ファイルシステム総合スレ その17
http://mao.5ch.net/test/read.cgi/linux/1421502118/

● 関連スレ
ジャーナリングファイルシステム
http://mevius.5ch.net/test/read.cgi/unix/979408065/

OpenSolaris/Illumos (OpenIndiana, etc.) 6
http://mevius.5ch.net/test/read.cgi/unix/1337411922/

FS関連スレ
http://medaka.5ch.net/test/read.cgi/os/1137387538/
過去スレ, 関連リンクは >>2-10 あたりで.
0323login:Penguin
垢版 |
2019/01/10(木) 21:27:48.95ID:nBvfLuxC
ファイルシステムが物理層の構造に依存するとか非現実的だろう
0324login:Penguin
垢版 |
2019/01/10(木) 21:58:54.96ID:l/4uAxA6
物理というかブロック層はbarrier/fua/flushに従うだけやろ？データとしての一貫性は上位のソフトウェアにしか分からんから>>322は当たり前の事を言ってるぞ
0325login:Penguin
垢版 |
2019/01/10(木) 22:14:30.50ID:H0AhwQF+
そういえばWindowsはファイルシステムの下位にフィルターが入るとかでWSLがやたらIO遅いとかネタになってたな
0326login:Penguin
垢版 |
2019/01/10(木) 23:36:19.35ID:AqGvqMIJ
WSLが遅いのはNTFSの上でfuseみたいなの動かしてるからじゃないか
0327login:Penguin
垢版 |
2019/01/11(金) 00:02:58.95ID:ftLr49mX
>>324
データの保証ってチェックサムレベルだったら勘違いしてるぞ
停電とかで一部のHDDにだけ書き込みが実行されて他に書き込まれなかった時、
単純に分散するだけじゃハードの恒久的な障害かそうじゃないかがわからなくなる
そのフラグなりジャーナリングなりまでをもファイルシステムがやれって事でしょ？

zfsみたいなチェックサムとは訳が違う
0328login:Penguin
垢版 |
2019/01/11(金) 00:55:44.89ID:g8TOMcSo
>>327
raid5/6のwrite hole問題の話か
あれはストレージノードの冗長構成とっていて頻繁なディスク同期のできない企業向けシステムが気にする問題やろ？停電や強制電源オフを頻繁にする人なら気にしたほうがいいが
0329login:Penguin
垢版 |
2019/01/11(金) 00:59:47.13ID:UZr/7ZNA
それに限らずハード起因の不整合は起こり得る
0330login:Penguin
垢版 |
2019/01/11(金) 01:06:21.03ID:ftLr49mX
win10の記憶域プールはファイルシステムより下で
ハード起因なのか停電とかなのかを判別してる

その機能の有効無効のフラグがIsPowerProtected
0333login:Penguin
垢版 |
2019/01/12(土) 16:09:53.17ID:L0kxz95a
bcachefsが今年中に使えるようになるんじゃないかね
結構期待してる
0334login:Penguin
垢版 |
2019/01/12(土) 16:46:59.06ID:2OwY199Y
今年使えるようになったばかりのfsなんて怖くて使えない
0335login:Penguin
垢版 |
2019/01/12(土) 17:43:51.46ID:7QnqZR8r
>>334
人柱様に水を差すんじゃねえだ。
0336login:Penguin
垢版 |
2019/01/12(土) 18:12:49.01ID:p6KdOxro
Linuxのメインラインに取り込まれるのが今年になるだろうってだけで何年も前から使えるけどな
0338login:Penguin
垢版 |
2019/01/12(土) 20:50:02.41ID:L0kxz95a
少し上のレスくらい見ようぜ
0339login:Penguin
垢版 |
2019/01/12(土) 20:57:27.94ID:jEoumrTa
何言ってんだこのバカ
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
企業に支えられていないファイルシステムってどれのことだ？
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況