ファイルシステム総合スレ その17

1 ：login:Penguin：2015/01/17(土) 22:41:58.83 ID:E5//dQrz.net

● 前スレ ファイルシステム総合スレ その16
http://hayabusa6.2ch.net/test/read.cgi/linux/1363315915/

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

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

FS関連スレ
http://kanae.2ch.net/test/read.cgi/os/1137387538/
過去スレ, 関連リンクは >>2-10 あたりで.

771 ：login:Penguin：2017/08/27(日) 22:44:45.28 ID:4l7e6/Be.net

>>766
ランダムライトならそうかもしれないけど何百GBも転送するならシーケンシャルライトに近い性能が気になるでしょ
そしてランダムライトならスループットじゃなくて各IOごとの遅延のほうが気になってくると思うんだが

772 ：login:Penguin：2017/08/27(日) 22:58:30.94 ID:ADXFMNn8.net

>>771
まっさらなファイルシステムならseqencial writeに近い状況もあるけれど、
既に使っているファイルシステムに対してrsyncでseqになることはまずない。
そしてディスク上で分散しているとしてもデータを流し込む段階では途中で切れるわけではないのでそれもない。
というか、その程度の問題はLinuxの場合十分なメモリを積んでいればバッファリングで解消してしまうので、
*GbEで互いに単独ノードなら* ディスクより遅いという場面はまずない。

というかやってみれば早い。ネットワーク速度よりもディスク速度が速ければ、受ける側のダーティキャッシュはほぼ空になる。
言い方を変えれば、転送中にsyncしても転送終了前にsyncが終わる

>>768
バッファについて学んだほうがいい

773 ：login:Penguin：2017/08/27(日) 23:35:25.23 ID:sof8RPx7.net

>>772
ほんそれ
async/syncくらいわかれよ

774 ：login:Penguin：2017/08/28(月) 00:12:48.85 ID:1A8yC8I3.net

サイズの小さいファイルが沢山ある場合はバッファリングで解消されないでしょ。
ジャーナル（とディレクトリエントリも？）は同期書込になるのでバッファ関係ないんじゃない？

そもそも書き込みの場合OSのバッファ関係ないんじゃ？
「HDD本体搭載/RAIDカード搭載のバッファで解消する」ならわかるんですが。

775 ：login:Penguin：2017/08/28(月) 00:20:14.21 ID:4P33EAyU.net

>>772
200GBくらいのコピーだからメモリに乗らんよ

776 ：login:Penguin：2017/08/28(月) 01:14:57.92 ID:4/AO/uEK.net

>>772
それはディスクより速い場面を想定してるだけに過ぎないのでは？VMイメージや動画のコピーをするときにネットワークがボトルネックになってる例なんていくらでもあると思うんだけど
実際10GB以上のファイルのネットワーク経由でのコピーでは、SSDにコピーしてもHDDにコピーしても100MB/sで頭打ちなんだけどなぁ

777 ：login:Penguin：2017/08/28(月) 03:21:46.14 ID:o2bE/9cE.net

>>774
それはWindows的な発想だなぁ。
まず主だったファイルシステムの挙動はだいたいドキュメントあるからそれを確認すると良いよ。
で、Linuxの場合新規書き込みであっても基本的にキャッシュする。
というか、書き込み時にバッファリングしないならなんのためのsyncだ。
試しにUSBディスクにddでdist imageでも書き込んで、dd終了直後にsyncしてごらんよ

>>775
全部乗らなくてもあまり関係ないね

>>776
それは経路が問題なんじゃないかな。

>>776
うちは家庭用ネットワーク機器を使った環境だけども、nc+bashでの転送ならちゃんと900Mbps近く出るし、
rsync+SSHでも400Mbpsくらい出ている。
データ転送総量は一番多かった時で40TBくらいだけども、rsyncだと途中からかなり速度が落ちる。
だいたい1TBくらいなら速度は落ちずにいける。
いずれにせよ、どれだけのデータを送ろうが、転送が間に合ってないなら受信側でsyncしたら途中で返ってくるよ。
別にafio+ncっていう方法だってあるんだよ

778 ：login:Penguin：2017/08/28(月) 03:54:52.16 ID:o2bE/9cE.net

SSHのが速い、という話は誰がしてたんだっけなぁと思ったら、これだね
ttps://twitter.com/n_soda/status/879551095311179776
うちはスレーブコンピュータの性能が低いので、800Mbpsなんて出ないけど。

779 ：login:Penguin：2017/08/28(月) 05:18:01.80 ID:rLCxAY1w.net

Windowsしか使ったことない人の知識なんてそんなもんだよ親切だね

780 ：login:Penguin：2017/08/28(月) 09:36:23.76 ID:1A8yC8I3.net

>>777
> それはWindows的な発想だなぁ。
仮にそうだとしたらWindowsではリレーショナルデータベース作れない(トランザクションログ
を実装できない)んですがね。 単なるレッテル貼りはやめましょう。

> で、Linuxの場合新規書き込みであっても基本的にキャッシュする。
後の読み込み向けであって書き込みはデバイス待ちのバッファ程度でしょ。

> というか、書き込み時にバッファリングしないならなんのためのsyncだ。
syncはOSのキャッシュに対して行っているのではなくHDDのキャッシュに対してでしょ。
HDDのキャッシュからディスクに書き込みが終わってない状態で電源が切れたら
ファイルシステムやデータベースで一貫性が破たんするわけで。

> それは経路が問題なんじゃないかな。
いや、約100MB/s(800MB/s)っていってるんだから制御系信号含めて帯域目いっぱい使ってるでしょ。
企業向けのディスクが精々１０本程度しか入っていないエントリモデルのサーバでも
再現できるクラスです。