ファイルシステム総合スレ その17 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
exFATだとLinuxのメタデータ落ちるから、LinuxとFreeBSD間だけだったらZFSがいいのかな？ zfsなんてバカスカカーネルメモリ食う上にmountしにくいもんイラネ
食わないように調整すればいいけどただでさえ激遅なのに(ry 専用のエンタープライズ向けストレージじゃなきゃ、
ファマイルシステムなんかもう何でもいいよ。
ext4でもXFSでも無難なのでいい。
個人的には、高機能、高性能、可用性を求めるなら専用ストレージ一択。
面倒な苦労せずに信頼性が高いから。 ポータブルだとパーミッションとか意味なくないか
NIS使ってるならNFSでいいし
バックアップならtarでいいし >>753
逆じゃね？ ファイルサーバ(NAS製品)だと、比較的評判の良い NetApp や Isilon は内部の
FS は非公開でそもそも選択権がない。 LinuxとFreeBSDでも平等に気持ちよく共有できるファイルシステムなんてない。
少なくともどちらがメインかというのは明確に決める必要がある。
GFSもObsolateだし。
exFATはFUSE実装ということもあってポータブルならマシな選択肢だと思う。
そうでないならネットワーク共有だな。
同一マシンデュアルブートだというのなら、仮想マシン経由でマウントしたほうがマシ。 ネットワーク共有遅いやん
5TB転送せにゃならんのにまだ1.1TBだわ…
しかもFreeBSDのrsync+iconvは糞だからシステムUTF8化しないと使い物にならんし >>757
まともな性能なら1GbE+SSHFSで800Mbps程度出るので、ハードディスクの限界なんか簡単に到達する rsyncなんかで馬鹿正直に1個ずつファイルをコピーしてたら遅いよ。
open, closeだけでも長いもん。
10年以上前の経験だけど、ディスクが十分に早いなら、コピーを多重化するとマシになる。
5個ぐらい並列でrsyncしても良いと思うよ。 ディレクトリが違えば遠いセクタに配置するかもしれんが、
rsyncって最初に必要ファイルサイズを確保してから転送するわけではないだろ そうだよ（笑）
上の階層から分けてコピーを始めるんだよ。
同じディレクトリをコピーしてどうすんだよww >>762
ああ、悪い。
話の前提としてはディスクがかなり並列化されてて、
あとファイルは元々断片化しまくってるような、
ファイルサーバーみたいなので話してた。
だからコピー後の断片化なんて考慮してない。
まあ、経験談ということで… >>758
ハードディスクの限界達してないじゃん
それはそうとメインのOSを決めてメインじゃない方はVMでマウントしてVMからはネットワークファイル共有ってのが一番速そうな気がした
VMからSATAなりUSBなりでの接続が遅かったらアウトだが >>765
ハードディスクのrandom writeは早くても50MB/s程度だから、400Mbpsでしかない。 1TBのHDDでもWindowsからファイルコピーするだけで950Mbpsは出るな >>766
ランダムライトならそうかもしれないけど何百GBも転送するならシーケンシャルライトに近い性能が気になるでしょ
そしてランダムライトならスループットじゃなくて各IOごとの遅延のほうが気になってくると思うんだが >>771
まっさらなファイルシステムならseqencial writeに近い状況もあるけれど、
既に使っているファイルシステムに対してrsyncでseqになることはまずない。
そしてディスク上で分散しているとしてもデータを流し込む段階では途中で切れるわけではないのでそれもない。
というか、その程度の問題はLinuxの場合十分なメモリを積んでいればバッファリングで解消してしまうので、
*GbEで互いに単独ノードなら* ディスクより遅いという場面はまずない。
というかやってみれば早い。ネットワーク速度よりもディスク速度が速ければ、受ける側のダーティキャッシュはほぼ空になる。
言い方を変えれば、転送中にsyncしても転送終了前にsyncが終わる
>>768
バッファについて学んだほうがいい >>772
ほんそれ
async/syncくらいわかれよ サイズの小さいファイルが沢山ある場合はバッファリングで解消されないでしょ。
ジャーナル（とディレクトリエントリも？）は同期書込になるのでバッファ関係ないんじゃない？
そもそも書き込みの場合OSのバッファ関係ないんじゃ？
「HDD本体搭載/RAIDカード搭載のバッファで解消する」ならわかるんですが。 >>772
200GBくらいのコピーだからメモリに乗らんよ >>772
それはディスクより速い場面を想定してるだけに過ぎないのでは？VMイメージや動画のコピーをするときにネットワークがボトルネックになってる例なんていくらでもあると思うんだけど
実際10GB以上のファイルのネットワーク経由でのコピーでは、SSDにコピーしてもHDDにコピーしても100MB/sで頭打ちなんだけどなぁ >>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っていう方法だってあるんだよ SSHのが速い、という話は誰がしてたんだっけなぁと思ったら、これだね
ttps://twitter.com/n_soda/status/879551095311179776
うちはスレーブコンピュータの性能が低いので、800Mbpsなんて出ないけど。 Windowsしか使ったことない人の知識なんてそんなもんだよ親切だね >>777
> それはWindows的な発想だなぁ。
仮にそうだとしたらWindowsではリレーショナルデータベース作れない(トランザクションログ
を実装できない)んですがね。 単なるレッテル貼りはやめましょう。
> で、Linuxの場合新規書き込みであっても基本的にキャッシュする。
後の読み込み向けであって書き込みはデバイス待ちのバッファ程度でしょ。
> というか、書き込み時にバッファリングしないならなんのためのsyncだ。
syncはOSのキャッシュに対して行っているのではなくHDDのキャッシュに対してでしょ。
HDDのキャッシュからディスクに書き込みが終わってない状態で電源が切れたら
ファイルシステムやデータベースで一貫性が破たんするわけで。
> それは経路が問題なんじゃないかな。
いや、約100MB/s(800MB/s)っていってるんだから制御系信号含めて帯域目いっぱい使ってるでしょ。
企業向けのディスクが精々１０本程度しか入っていないエントリモデルのサーバでも
再現できるクラスです。 >>778
smbはver2.0までだとレイテンシの悪さでどんどん速度が落ちます。
そこに書いてある内容はやや語弊がありますね。
かつては拠点内だと800Gb/sでるけど拠点間だと遅くなるからって理由でsambaの
導入を渋る/Windows Server 2008が良いって言う企業さんはいました。 今どきのデータベースってファイルシステムを使ってるの? データベースだけはOS通さずに物理ディスクに直接アクセスするとか、そういう話かしらね アプリが必要としているのは「今電源が切れたとして、後でそれが読み出せるか(メディアに
書き込んだか)、読み出せないか(キャッシュどまりで電源断で飛んでしまうのか)」であって
何か特殊なファイルシステムだったり特殊なデバイスアクセスが必要なわけではないです。 >>780
だいぶ古いけど
http://d.hatena.ne.jp/naoya/20070523/1179938637
writeでは基本的にブロックされない代わりに、
データが永続化されたかどうかは
(OSではなく) ソフトがfsyncなどで保証するというのがlinux (unix？) の流儀。
だから、例えばmysqlなら、fdatasyncだったりO_DIRECTでOSのバッファをバイパスして書き込んでる >>787
「基本的にブロックされない」んじゃなくて、デフォルトだと非同期書き込みでファイルディスクリプタが
オープンされるってだけでしょ。 プログラマが状況に応じて O_DIRECT つけたり、特定のデータの
区切りでfsync (syncにファイルディスクリプタ指定できるだけの物でsyncとは別物ではない) とか
かけるってだけじゃないですか。
# 「(OSではなく)ソフトがfsyncなどで保証」ってのが？ あなたの意図するOSが保証するがわかりません。 たぶん、DB は、自分でバッファを確保して、処理しているのだろう
データをバッファに読み込んで、そのデータが更新されていないのなら、
バッファから読み込む事で、データを再取得しない
例えば、500件を読み込んで、もしデータが更新されていれば、
更新されたレコードだけを、再読み込みするのかも
例えば、3件目と5件目だけを、再読み込みするとか 何が言いたいのかサッパリ分からんな
目新しいひらめきでも含まれていることを前提に読んでるからアホに見えるのかな >>790
読み込みはHDD→HDD本体付属のキャッシュメモリ(→RAIDコントローラのキャッシュメモリ)→メモリ→
CPUのL3キャッシュ→CPUのL2キャッシュ→CPUのL1キャッシュ→CPUのレジスタの順に読み込まれ、
更新(つまり書き込み)はその逆順になる。 (記憶階層と呼ばれるもの)
なので更新された内容は先にメモリに書き込まれ、その後HDDに書き込まれるから
「HDDから更新されたレコードだけ読み込む」なんてことはあり得ない。
# ３件目のデータがオリジナルの値が100円で、今120円に書き換えたのにディスクには
# 130円って書いてあった、なんてことは普通考えられないでしょう？
あり得るとしたら共有ディスクにデータを置くクラスタ構成のデータベースぐらい。 >>793
SSDをRAID10で組むのがDBの主流のこのご時世に説明必要？
記憶階層の説明においては理解を阻害する蛇足にしかならんよ。
>>794
DBをRAWで使わない理由かな？
スナップショット取れないから設計段階でハネられるからでしょ。 >>795
なるほどスナップショットですか
でもRDBMSがレプリケーションしてると1つ止めればいいだけだから問題なさそう ご時世ならインメモリだろ
SSDでRAID10でスナップショットとかどんだけコスパ悪いねん
なんでもかんでもDB化する必要ないんやで インメモリじゃ消えちゃう
用途ごとに適材適所しようよ 別に不揮発性じゃなくても定期的にHDDに排出すればいいだけだろ
突然電源落ちたらぶっ壊れるのは同じだしな
つか1TBのDBとか何に使ってんだよ 要するにインメモリが最適解というわけですね
わかります RDBMSはログを逐次書き込むから定期的とかじゃダメでしょ
チェックポイントから復旧するためのログ
それに書き込めなかったことがすぐにわからなかったら、マスターの切り替えもできないんじゃない >>800
1TBはまだ無理だが、HPのProLiantなら8GBのNVDIMM16枚載るそうな。
マザボ側に電池が必要との事なので8GBのDDR4のDIMM+停電時の退避先の8GBのNAND
メモリの実装だろうから、速度はメインメモリと同じ。
8GBで定価157,000なんで、普通のDIMMの３〜４倍程度の値段、
PCIeに装着するタイプのSSDが1.6TBで定価256万なんで、それと比較すると１２倍ぐらい高い。
ファイルシステム目的でみると高すぎるが、DBユーザには現実的な価格だと思う。 要するにUPS付きインメモリDBのコスパ最強っていいたいんだろ？
そういや昔、メモリ集めてSATAかIDEかにできる機器があったな
そろそろDDR3が余ってくる頃だしまた出して欲しいわ
うちはまだまだPCI付きIvyBridgeだらけだけどな >>807
UPSと比較した場合のメリットがわからない >>809
前提が間違っているんだよ。
インメモリDBもUPS付けてもマザボ故障したらDIMM上のトランザクションログすっとぶわけで、
トランザクション処理には使っちゃダメな製品だとおもう。 素直にBIの分析だけにしとけと。
そうなるとデータ更新しないわけだからそもそもUPS要らないよね。
極論を言えばUPS付きインメモリDBなんて存在価値の無い代物ってこと。
もちろん故障した時にトランザクションログ壊さないインメモリDBもあるけど、それってSSDで
組んだ普通のリレーショナルDBと何も違わないのよね。 マザボ故障してもSSDだとすっとばないってか？w
インメモリはトランザクション処理自体がお前が考えているのような動作はしない
個々のDBについて語っても無意味だが、起動は遅いし、レスポンスは桁が違うし、
HDDへの排出は別スレッドで適時行われるし、根本的にインメモリを前提にした体系だ ファイルシステムとDBの話で
インメモリDBの話はしてない >>811
> マザボ故障してもSSDだとすっとばないってか？w
マザボやRAIDコントローラがウソのデータを書き込む故障も無いわけではないが、レアなケースだわな。
マシンがコアも吐かずに突然リブートというパターンの発生比率と比べるとね。
要は実際に採用されてるってところだろ。
> インメモリはトランザクション処理自体がお前が考えているのような動作はしない
RDBMSと同じような動きをするなんちゃって製品をディスったのをそう捉えられてもねぇ...
> HDDへの排出は別スレッドで適時行われるし
普通のDBでもするでしょ。 ファイルシステムでさえそうしてるってのに。 >>812
UPSを使わずに済ますという観点では現状のOS/ミドルウェアの対応状況を鑑みるにNVDIMMにメリットは何もないでしょ。
Intel のビジネス的な都合で出してきた、NVMeに対するコンペ商品だから。
OMNI-Path 同様他社が手を出しにくいインターフェイスで最速のデバイス出してきたってだけさ。 >>813
おまえはインメモリの圧倒的コスパに対して、
SSDの優位性を一切論理的に説明できない駄レスしかできない無能なんだからすっこんでれば？ >>815
すまないが、俺はSSD優位とは一言も言ってないぞ。
それどころかインメモリは性能最強だと思ってる。 ただ、コスパは最強という意見はいただけないね。
SSDでもメモリバカ積して逆正規化かけまくったりインデックス貼りまくったり、アイソレーションレベル
に手心加えれば、従来型のRDBMSで充分「立ち上げが遅い」が「レスポンスが速い」物ができるんだよ。
インメモリＤＢのその製品が優れていて速いわけじゃない。 君が製品カタログに書かれたメーカに
とって都合のいい売り文句のトリックを見破れてないだけだ。 お前は何を目的にレスしてんだ？
だから駄レスって言われんだろ
製品カタログとか言ってる時点で盆暗だと自覚しろ
コスパ以前に盆暗のお前でもコストくらいは調べられるだろ
そんなに駄レスしたけりゃ必要な金額でも書いてみろよ 小さなファイルのバックアップ用に
USBメモリを使用しているんだけれど
windowsとLinuxの混在は不味いっすかね ウインなにがしとかいうインターネットを危険に陥れる脆弱性だらけのバグバグOSもどきが
いくら乗っ取られていようとLinuxには影響ないから大丈夫じゃね ごめ説明が下手だった
USBメモリのFAT32フォーマットに
Linuxフォーマットext4で保存したファイルを
混在させてそれを消去させた場合に再びFAT32に戻るものなのかが謎で
そこのセクタだけ壊れそうな雰囲気があってねw >>820
あまりにも返信がないからツッコミをいれておこう。
ファイルシステムというのはファイルを管理しているのであってファイルに付随しているわけではないので、
別にEXT4ファイルシステム上に保存されていたファイルをFATファイルシステム上にコピーしたからといって、
FATファイルシステムのそこだけがExtファイルシステムになるわけではない。 横レスだけどAndroid（でなくてもいいけど）のfatマウントしてファイルコピーすると属性が変更できませんとか出て怖いよなｗ >>826
そりゃファイルシステムが持っているファイルの属性情報が違うからねぇ… archive、system、hidden、readonlyだったっけか そうね。しかもそれって重要ですらないような属性だし…
隠しは重要だけど気休めだしね。 ZFSって何に使ってんの？
iSCSIに切りだしたり？
sambaじゃメリット出ないよね速度とか 今使われてるのは、本家以外、みんなOpenZFSだと思うけど。 >>833
VSSとsnasnapshot連携できる Redhatが重複排除のファイルシステムを
開発してた会社買収したらしい。
ZFSに頼る理由がひとつ減るな。 >APFS形式ドライブは、macOS High Sierra以降のmacOSでしかマウントすることが出来なくなります。
／(^o^)＼ﾅﾝﾃｺｯﾀｲ 誰かボスケテ
apt-getでアップデートアップグレードしたらzfsが無反応になって
バージョンが違うって事で一度アンインスコして再度インスコしたらzfsは動くがプールが無くなった
どうすればいいの？ poolをcreateしちまったがやはり何もでてこない…これもう前のデータ消えた？ >>844
poolをcreateしたら流石にダメなのでは 諦めてバックアップから復元しろって・・・バックアップとってなさそう そっか…だいぶ古いバックアップしかない。
諦めるか… zpool importするべきだったね
createしたら上書きされるからわからん createしなければzpool import -Dで助かったかもしれないのに そうか、createじゃなくてimport -Dだったのか…
手痛い勉強になりました。 ■ このスレッドは過去ログ倉庫に格納されています
