ファイルシステム総合スレ その14
■ このスレッドは過去ログ倉庫に格納されています
ファイルシステム総合スレ その13
http://engawa.2ch.net/test/read.cgi/linux/1311812102/
●関連スレ
ジャーナリングファイルシステム
ttp://hibari.2ch.net/test/read.cgi/unix/979408065/
OpenSolaris/Illumos (OpenIndiana, etc.) 5
http://hibari.2ch.net/test/read.cgi/unix/1285876800/
過去スレ、関連リンクは >>2-10 あたりで。
0793login:Penguin
2012/06/09(土) 05:59:48.50ID:Jvnl8fc60794login:Penguin
2012/06/09(土) 08:28:54.36ID:qQp1Nawymv 寿限無、寿限無、五劫の擦り切れ、海砂利水魚の水行末 雲来末 風来末、
食う寝る処に住む処、やぶら小路の藪柑子、パイポパイポ パイポのシューリンガン、
シューリンガンのグーリンダイ、グーリンダイのポンポコピーのポンポコナーの、
長久命の長助.txt \
10ゲーム、10ゲーム、後藤の振り逃げ、ジャイアンツ球場、毎週末、フライ取る、
ピンチのところに角みつお、球児好児の右好児、大豊、大豊、大豊のチューインガム、
チューインガムはグリーンウェル、グルーンウェルはポンコツだけど、
チンポコだけは超級極に超すげぇ.txt
0795login:Penguin
2012/06/09(土) 15:26:25.68ID:CYJESA2dまじっすか。これでbtrfsも日の目を見るのですね胸熱
0796login:Penguin
2012/06/09(土) 23:39:08.42ID:kBHkLsAVBtrfsの開発が今以上に遅くなるだけだと思う…
0797login:Penguin
2012/06/10(日) 04:26:40.88ID:m9ltFuzM0798login:Penguin
2012/06/10(日) 10:21:15.46ID:CTEqf0MMMS？ヤメテクレ
0799login:Penguin
2012/06/10(日) 10:52:54.32ID:OFnzryCV0800login:Penguin
2012/06/10(日) 11:39:29.82ID:BOujf8XYハードリンクがないとか、UNIXでは使いにくいfsになりそうな仕様なのが残念
0801login:Penguin
2012/06/10(日) 14:39:05.49ID:hb5gztZS重複排除なんてReFSには入ってないぞちゃんとホワイトペーパー嫁
2012で新しく入る重複排除はNTFSだけだ
0802login:Penguin
2012/06/10(日) 14:47:43.05ID:hb5gztZShttp://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx
＞Q) How come ReFS does not have deduplication, second level caching between DRAM & storage, and writable snapshots?
＞ReFS does not itself offer deduplication.
0803login:Penguin
2012/06/10(日) 22:28:04.74ID:JwGLO5xXハードリンクは100歩譲って無くてもWindows Serverで困らんとしても、
スパースファイルを無くしたのは理解できないな。
0804login:Penguin
2012/06/10(日) 22:59:38.71ID:MefZB5FW0805login:Penguin
2012/06/11(月) 00:06:37.85ID:pnBHOzNwもうとっくに準拠する気ないだろ。
独自仕様だったり、すぐ技術を捨てるから嫌いなんだ、あの会社。
0806login:Penguin
2012/06/11(月) 00:11:05.32ID:s7RGctxDWindows環境だとハードリンク以上に使われてない
UNIX系の実装と違って暗黙の内に使われないし低リソースコストでもない
設計上の理由によりファイルサイズが大きいほど使い物にならない
だったらReFSでまともな設計と実装すればいいだろって気もするがどうせ使われてないしって判断されたんじゃないか
0807login:Penguin
2012/06/11(月) 04:37:09.02ID:qHJPw6rD互換レイアは乗せるんじゃ？
まPOSIX自体が古くさいからな
さっさとPlan9に移行したら良かったのに
0808login:Penguin
2012/06/11(月) 09:18:01.60ID:usJIEui+すでにデータがあるZFSのドライブを再度create poolしてしまった場合の復旧方法ってないのでしょうか？
0809login:Penguin
2012/06/11(月) 11:48:17.36ID:XqKJBt3tバックアップからデータを復旧。
0810login:Penguin
2012/06/12(火) 00:14:14.46ID:c8ME4i3cやっぱりそうなるのですね...。
バックアップはないのです。
0811login:Penguin
2012/06/12(火) 00:56:21.94ID:A80hLwHw0812login:Penguin
2012/06/12(火) 01:35:41.78ID:CNHA46Eb0813login:Penguin
2012/06/12(火) 06:29:32.30ID:1oUeLMaZバックアップは完璧
0814login:Penguin
2012/06/12(火) 12:02:02.28ID:A80hLwHw0815login:Penguin
2012/06/12(火) 16:19:18.95ID:S638pBsp0816login:Penguin
2012/06/12(火) 16:34:38.78ID:VjfjQ8Wn別のスレだったら「スナップショットはバックアップじゃねーよwwwww」みたいに爆釣りなはず。
0817login:Penguin
2012/06/12(火) 21:59:52.99ID:c8ME4i3c日デに頼んだのですが復旧できませんでした。
GIGAZINEの記事はステマですねｗ
0818login:Penguin
2012/06/12(火) 22:05:41.95ID:c8ME4i3c0819login:Penguin
2012/06/12(火) 22:24:27.24ID:2a400Qf1画像ファイルで数百万（1つ10kb程度）あります。
現在MYSQLとPHPでwebサイトに表示しています。
今のところ画像ファイル7万点なんですが、特にパフォーマンスに問題はありません。
しかし、最終的なファイル数はおそらく数百万ファイルになりそうで、
このままファイル数が増えていったらリスト表示もできなくなりそうです。
一つのフォルダに数百万のファイルをまとめるのと、
フォルダを10万ファイル程度に区切って、mhddfsなどで統合する方法は
どちらのほうがパフォーマンスは上なんでしょうか？
一つのフォルダに入れるファイル数は1万5千程度が良いとか、
数百万ファイルでもパフォーマンスは落ちないとか情報があって、
実際のところどうなのかな？と思って質問させてもらいました。
0820login:Penguin
2012/06/12(火) 22:24:49.10ID:w0tL+HNLあれ日本データテクノロジーだったんだ
0821login:Penguin
2012/06/12(火) 22:45:24.00ID:QzzsWMC81フォルダ1000ファイルくらいにまで分けろ。
0822login:Penguin
2012/06/12(火) 22:51:32.10ID:74O6EGVK経験が無く、ツールやノウハウが無かったから。
世の中の多くのサーバはWindowsで、残りのサーバのうちZFSなのは
さらに少ない。データテクノロジーもExt3の復旧は得意だけどね。
何とかなりましたとさ。
という記事だった。
0823819
2012/06/12(火) 23:31:24.31ID:2a400Qf1それは1000のファイルが入ったフォルダを1000個作ったほうが、
1つのフォルダに100万個のファイルを入れるより、パフォーマンスが上ということですか？
mhddfsやAufsという方法を使った場合も同じ結果でしょうか？
なにぶんファイル数が膨大で、ファイルをアップロードするだけでも大変なので、
経験者の方のアドバイスがあれば嬉しいんですか・・・
0824login:Penguin
2012/06/12(火) 23:43:15.90ID:MpEUHCJi上がるはず。Subversionのファイルもshardingをして
同じようにディレクトリ当たりのファイル数を減らすチューニングが入ったことがあった。
0825login:Penguin
2012/06/12(火) 23:54:37.84ID:c8ME4i3cでもNTFSやext3なら自分で復旧しますよねｗ
0826login:Penguin
2012/06/13(水) 00:16:06.10ID:im3XxTJbそういうのはFSでやんじゃなくてデータベースでやる仕事。
0827819
2012/06/13(水) 00:27:57.04ID:NicPlsMSなるほどやはり分けたほうが効率的なんですね。
ググッてみるとやはり数千単位なら動作に支障が無いと出ることが多いですね。
>>826
画像データをデータベースで管理するということでしょうか？？
そうすると、画像のバイナリデータを文字列化なんかにしてテーブルに格納して・・・
ということでしょうか？まったく考えもしなかったですｗ
0828login:Penguin
2012/06/13(水) 00:39:24.57ID:fuVjCYIgNoSQLでもバイナリデータ入れられるデータベースは多いけどね。
俺は逆に大量の画像とかそういうのこそファイルイシステムがやる仕事だと思ってるんだけど。
それはさておきext3ならdir_index付ければ普通はファイル数が多くてもそんなにパフォーマンスが落ちることはないはずだし
最近のファイルシステムならinode枯渇とかしてない限りはファイル多くても大抵は大丈夫なんじゃないかな
0829login:Penguin
2012/06/13(水) 00:58:23.46ID:3SaHO1QS0830login:Penguin
2012/06/13(水) 01:12:19.40ID:+Wj+1Zxy0831login:Penguin
2012/06/13(水) 01:55:53.41ID:NicPlsMSなるほど、勉強になります。
そもそもファイルシステムがこういった案件に弱いというのが疑問ですねｗ
>>830
BLOBという型にして呼び出すんですね。
こちらで質問しなければ、まったく思いもよりませんでした。
ちなみにこの方法だとファイル数（レコード数）が数百万というテーブルを作っても
パフォーマンスが極端に落ちるということは無いのでしょうか？
0832login:Penguin
2012/06/13(水) 02:33:07.72ID:GV9bfSgb言葉で説明するのは困難なことは
実際にやってみるのが一番いい
理屈で考えるのではなく、現実はどうなるかを体感するのは重要である。
0833login:Penguin
2012/06/13(水) 02:44:53.17ID:+Wj+1Zxyデータベースの場合、数百万件なんて普通レベルなんでインデックス
のキーが適切に選択されていて、メンテナンスしてれば極端な劣化は無い。
しかしデータの増加や追加削除の繰り返しによるパフォーマンス劣化は
BLOB に限った話ではなくデータベース共通の話。
テーブルの断片化解消やインデックスの再構築でググれ。
Hadoop の HDFS は名前こそ FS だがマウントも出来ない BLOB 型のデータベースの
表みたいなもので、そういうものが一部でもてはやされる事を考えると既存のファイル
システムで相当数のファイルを管理するのは構造的に無理があると考えるべきかな。
0834login:Penguin
2012/06/13(水) 06:42:31.78ID:Q0aB+GDr0835login:Penguin
2012/06/13(水) 08:53:01.83ID:uA/huhkAデータベースで持つと、DBのダンプバックアップで死ぬ。
いずれにしてもバックアップで死ぬことに変わりは無い。
0836login:Penguin
2012/06/13(水) 09:10:08.57ID:SNVs8i2Y0837login:Penguin
2012/06/13(水) 10:49:44.68ID:Vo7uLr110838login:Penguin
2012/06/13(水) 12:17:39.91ID:Q0aB+GDr0839login:Penguin
2012/06/13(水) 12:19:02.65ID:Q0aB+GDr0840login:Penguin
2012/06/13(水) 12:19:44.22ID:TEq9LBw00841login:Penguin
2012/06/13(水) 21:10:04.34ID:XRYJLg+tbtrfsの圧縮ファイルシステムって実用になった？
0842login:Penguin
2012/06/13(水) 21:16:27.24ID:fS2w2fWW0843login:Penguin
2012/06/13(水) 21:59:48.11ID:9t1XfE5U0844login:Penguin
2012/06/14(木) 18:27:36.77ID:qXP3mfTPOCFS2 のほうが手軽かな？と思ってんですが。
共有ディスクの用途は Maildir のあるホームディレクトリ。
0845login:Penguin
2012/06/14(木) 19:43:43.82ID:IoUaFPCMなんでmaildirの共有でクラスタファイルシステム?
iSCSIとかでSAN組んでいるの? でも、普通にNFS使えばいいやん
0846login:Penguin
2012/06/14(木) 21:06:50.50ID:g26savghlsyncがCPU使いまくるんだけど、やっぱこれ結構おもい？
0847login:Penguin
2012/06/14(木) 21:17:17.07ID:hSWjO2am0848login:Penguin
2012/06/14(木) 21:22:24.95ID:g26savgh0849login:Penguin
2012/06/14(木) 21:22:42.00ID:qXP3mfTP２サーバで共有ディスク(SAS)があるから
0850849
2012/06/14(木) 21:27:48.19ID:qXP3mfTPで２台+共有ディスクありきで Active/Active で構成したい。
0851login:Penguin
2012/06/15(金) 08:55:32.46ID:etFWwJqYあって、３年ぐらい使っているんですが、だんだん速度が
遅くなってきています。
データが爆発的に増えたかというと、むしろ導入時から減っていて、
ddでディスク書き込みの速度を比較すると、全く劣化はありません。
このような場合、ディスクを疑うべきか、OS(Redhat 5)の
設定を疑うべきか。スパっとわかる方法は何かないですか？
0852login:Penguin
2012/06/15(金) 09:52:26.16ID:IihlBhKxメタがキャッシュから溢れて遅くなっている
0853login:Penguin
2012/06/15(金) 11:29:51.62ID:etFWwJqYあまり細かなことがかけなくて申し訳ない。
/var/data/000
/var/data/001
/var/data/002
/var/data/003
というデータディレクトリに、それぞれ100個ぐらいの
サブディレクトリがあり、その中に約5000個ぐらいの
ファイルがあるというシステムです。/var/dataが
ext3で初期化されたストレージのマウントポイントです。
ファイルの数はたしかに多いのですが、分散して
格納されているので、メタキャッシュの問題は無いと
思うのですが。
何か調査のヒントがあれば助かるのですが。
0854login:Penguin
2012/06/15(金) 11:51:15.99ID:tGg2+kbq0855login:Penguin
2012/06/15(金) 11:55:19.21ID:OdpSy71Vtune2fs -l のDefault directory hashとFilesystem featuresの値をみせてー
0856login:Penguin
2012/06/15(金) 11:59:45.85ID:IihlBhKx0857login:Penguin
2012/06/15(金) 12:06:11.27ID:etFWwJqY早速調べてみました。
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Default directory hash: tea
何か判りますか？
0858sage
2012/06/15(金) 12:10:49.48ID:gAV/lq3N>>853
/bin/rm -r /の結果を見せて！
とか書いたらほんとにやりそう。
0859login:Penguin
2012/06/15(金) 12:13:02.19ID:cF2L7SVl0860login:Penguin
2012/06/15(金) 12:16:24.21ID:xmmMVJnwrm: it is dangerous to operate recursively on `/'
rm: use --no-preserve-root to override this failsafe
こうですか？
0861login:Penguin
2012/06/15(金) 16:01:02.04ID:MqQJgtCz今日それで冷や汗書いたよ。
rmは恐ろしく、強力なツールだと再認識
0862login:Penguin
2012/06/15(金) 16:01:57.09ID:MqQJgtCzこれがいいんじゃない？
0863login:Penguin
2012/06/15(金) 16:41:45.49ID:IihlBhKxああ、在日の方でしたね
0864login:Penguin
2012/06/15(金) 17:18:30.76ID:DOzDLpngデータはどういうふうに使ってるの？
読み出しのみ？書き込みあり？
それぞれのファイルの寿命はどの程度？
メールサーバって書いてあったけど、
単にpostfix動かしてますってメールハブとは違うんだよね？
0865login:Penguin
2012/06/15(金) 20:05:38.95ID:etFWwJqYあまりに具体的な話をすると問題になっちゃうので、
某社開発のメールシステムとだけ答えておきます。
前に書いたEXT3のファイルシステムにユーザ毎のメール
フォルダーが１ユーザ/１ディレクトリの単位で入ってます。
このディレクトリ内のメールデータをホニャララのライブラリーを
使って、別のアプリにホニャララして、各ユーザーのPCにメールが
ホニャララされます。
このデータ処理中に10MB/sec程度の書き込みが運用中には
常時発生していて、ユーザアクセスが多いとCPU負荷が上がり、
処理が止まってしまうという障害が起きてます。
ddで書き込み試験を行うと120〜130MB/secぐらい
(oflag=direct)で出ているので、書き込みには余裕が
あると思ってますが、某社からはHDDの速度が遅いのが
原因と言われて改善を求められてます。導入した
数年前とデータ量もあんまり変わっていないしね。困ったな・・
という状況です。
0866login:Penguin
2012/06/15(金) 20:08:17.35ID:OdpSy71V話を聞いていると別のとこに問題があるように感じるんだが……
0867login:Penguin
2012/06/15(金) 20:26:03.24ID:ZzxIPBRFiostat -xの値は？
0868login:Penguin
2012/06/15(金) 20:43:36.17ID:ZzxIPBRF・過去にメール爆弾をやらかしてディレクトリエントリが肥大化したまま
・うっかりln -s . hogeみたいなリンクを作ってしまって、ほにゃららが混乱している
でもあれこれイスパーするよりoprofileやftraceで特定するのが簡単で確実。
0869デムパゆんゆんネトウヨ特攻兵＠６月 鉄砲百合 【関電 64.1 %】
2012/06/16(土) 00:37:56.82ID:VAj81kZb＞使って、別のアプリにホニャララして、
ライブラリのバグで暴走中なんじゃねの
0870login:Penguin
2012/06/16(土) 01:50:40.08ID:k68BsoY7> ああ、在日の方でしたね
在日日本人ですか?それとも在日アメリカ人ですか?
「在日」としか書かない奴のB層の知能は知れてるよね。
0871login:Penguin
2012/06/16(土) 01:57:29.42ID:QtTxMqqDEnglish is OK?
0872login:Penguin
2012/06/16(土) 03:37:03.37ID:d/seGET+くだらねえ所にしか突っ込めないアホだwwwwwwwwww
0873login:Penguin
2012/06/16(土) 10:36:31.39ID:buYLXX0r簡単に調べられるからやるべき。
0874login:Penguin
2012/06/16(土) 23:48:42.49ID:3mlUjrH5>>463の記事を読んで、データ置き場をXFSにしたんだ。
これでデフラグする必要がほぼ無くなってハッピーさ。
0875login:Penguin
2012/06/17(日) 21:40:22.91ID:Mw2oNRGdぶっ壊れたときとか誤って削除してしまったときに簡単に直せる方が嬉しいね
0876login:Penguin
2012/06/18(月) 01:41:22.05ID:oZmhFfRK基本的にLFS系しかないな
0877login:Penguin
2012/06/19(火) 03:22:25.70ID:P5qrl8Zf面白いベンチマークデータ。
CentOS5より6の方がSSDの性能を生かせるみたいだな。ext4利用は必須。
http://hesonogoma.com/SSD/Silicon-Power_SSD-T10-128GB_Benchmark.html
0878login:Penguin
2012/06/19(火) 06:56:32.28ID:Fg6cF6bR0879login:Penguin
2012/06/19(火) 19:41:26.33ID:9qXPq/xlなんでext2がないんだ
0880login:Penguin
2012/06/19(火) 20:04:19.49ID:dXMZnUjp結局、画像ファイル名から数文字とったディレクトリを大量に作って対応することになりました。
.htaccessでリダイレクトする方法や、CDNでの対応や、
ここで教えてもらったデータベースでの管理など検討しましたが、
多少のphp書き換えで対応できるという手間の少なさから上記の方法になりました。
相談に乗っていただいた方、ありがとうございました。
0881login:Penguin
2012/06/19(火) 20:06:43.58ID:4H7kxi1uベンチマークの数値自体は5より6が優位なようにはみえないし、
discardオプションの有無を数値として検証してないし、
検証記事としてはひどい部類じゃね？
0882login:Penguin
2012/06/20(水) 01:25:34.68ID:KohzvN+Jbonnie++のグラフがあるな
block input、block output、randamの3つでオオヨソの性能は分かるよ
これ見るとやっぱりCent6のext4が性能いいんじゃね？
ちなみにこの記事書いた中の人はTRIMを有効にしようって言ってるけど
CentOS5と6の性能差の話にはふれてないよね
0883login:Penguin
2012/06/20(水) 02:46:33.10ID:bzl7Ow+30884login:Penguin
2012/06/20(水) 10:11:44.15ID:klr5J2UKまあ一般ユーザーが今のNTFSみたいに使えるようになるのは2018年頃になりそうだが
0885login:Penguin
2012/06/20(水) 10:56:45.32ID:tSSpL/mp早くLinuxで使えるようになってくれないかな
0886login:Penguin
2012/06/20(水) 11:03:11.61ID:8Nbpf+NV0887login:Penguin
2012/06/20(水) 11:07:19.57ID:DLIhrxAe個人的にはntfs-3g程度でも十分満足してるけど
やっぱり公開されるといろいろ使えない機能が使えるようになったり速度が向上したりするのかね。
0888878
2012/06/20(水) 11:42:11.50ID:3akCHBOa早速入れてみたが、あっさり動いてしまった。
Poolが壊れたり、動作が遅くなったり楽しいイベントを覚悟してたが、
拍子抜け。
0889login:Penguin
2012/06/20(水) 12:14:51.54ID:Q4WokbHX俺も。
強いて言えば、ファイルシステムが妙になった時にWindowsに繋ぎ直してcheckdiskをかけないといけないのが不便かな。
もともと暗号化、圧縮とか使ってないからかな。
0890login:Penguin
2012/06/21(木) 10:21:57.52ID:TvPdkXz8CrystalDiskMarkは簡単にディスクベンチをとれるいいソフトだと思うけどな
でもこれがディスク性能の全てではないことを理解して使うことが大事
linux用にはこれぐらいお手軽なディスクベンチはない・・・かな？
0891878
2012/06/21(木) 11:19:33.62ID:g23nZkEF0892login:Penguin
2012/06/21(木) 15:38:34.62ID:u8QHq9Zh0893login:Penguin
2012/06/21(木) 16:25:35.59ID:jSo3bVTw■ このスレッドは過去ログ倉庫に格納されています