08/10/11 03:46:56 /DmF+eXK
>>928
面倒な事は何もやらないけど、ものすげー安い or 速いSSD
＋
そういう面倒を引き受けてくれるファイルシステム
つうのがいいんじゃないかと思うんだが、世の中そういう方向に行ってくれなくてのう。
931:login:Penguin
08/10/11 05:03:38 HTsFZd/e
今のファイルシステムも信頼できないのに、どんどんと新しい信頼できそうにない
ファイルシステムをもってくるのはやめてほしい＞Linux。
（客に提案するサーバのうち NFS serverは全部Linux以外だぜHAHAHA!!）
SSDはさっさとECC的なチェック位して、まともにリードエラー出すようにしてくれないと
個人でも心配でメインには使用できない。
ここまで故障しやすいシステムなんてこれまで考慮されてないんだから
ハードウェア側でさっさと対処して、OS標準ファイルシステムがデバイス依存に
ならないようにしてほしいわ。
932:login:Penguin
08/10/11 07:59:47 yGwU5XzZ
>>931
>SSDはさっさとECC的なチェック位して、まともにリードエラー出すようにしてくれないと
もうやってる。
なんでSSDに対して対策が必要なのかを根本的に理解してないタイプか。
933:login:Penguin
08/10/11 08:56:37 ppTdVB+e
直接sambaとかNFSサーバ見せないでプロキシ経由で
アクセスするようにってできないですかね？
直接ファイル鯖いじられたくない困った
934:login:Penguin
08/10/11 09:09:28 QSGYszLu
>>933
よくわからんが、Apache で WebDAV
935:login:Penguin
08/10/11 09:16:02 ppTdVB+e
>>934
sambaとかって
鯖ー鯖(蔵）ー蔵方式で
マウントできますかね？
WebDAVとか遅いからだめなんですよ
936:login:Penguin
08/10/11 09:24:39 WkhcPGyl
>>935
質問の仕方もおかしいし、スレ違いって事もわからないようじゃ君には無理。
937:login:Penguin
08/10/11 11:49:16 /eNXCR9B
>>931
LinuxのFSが信頼性よりパフォーマンスなのは同意するが
NFSサーバがLinuxじゃないのはNFSが互換実装なのを嫌った方がでかいだろう。
SSDでも突っ込み入っているけど、調べる癖は付けといたた方がいいよ。
客とやらを不幸にする前にね。
938:login:Penguin
08/10/11 12:39:21 F5yk1I08
>>931
おまえがタームだけしか知らずにモノを言うシッタカなのは理解してあげたので、
とりあえず
URLﾘﾝｸ(homepage3.nifty.com)
でも読んで出直せ。
939:login:Penguin
08/10/11 14:10:29 g3joq6C9
SSDがどんどんHDD的に使えるようになってるのでFS開発者としては
新設計なしで静観予定らしいけど、
SSD,HDD -> 従来FSでおけ
生フラッシュ -> MTD, UBIでおけ
USBメモリとか -> 選択肢が無い・・・
というわけで、大容量USBメモリとかSD/CFが使いにくいまま。
小容量ならinitramfsでメモリ展開して終わりなんだけど、
大容量フラッシュメモリデバイスをうまく使う方法が無いのが
ちょっと微妙。tmpfsを被せて使うくらいしかできない。
940:login:Penguin
08/10/11 14:14:16 ZEc5lvl1
NTFSでハードリンクを使ったら、削除がすごく遅くて使えない
というか、１つの実体ファイルに対してのハードリンクの数に
比例して速度が落ちていっているようです。
pdumpfsで10万ファイルくらいあるフォルダをバックアップして
３ヶ月くらい放置してあったんだけど、
（実体が約10万ファイルで、×90日＝約900万個のハードリンク）
pdumpfs-cleanがいつまで経っても終わらないので調べてみたら
上の状態で１日分削除するのに１時間以上かかっていました。
ハードリンク数が減ってくればスピードが上がるとはいえ、これでは
クリーンアップが終わる前に、次のバックアップ時間になってしまいます。
ext3とかXFSでもこんなに遅い…なんてことはないですよね？
バックアップ専用にLinuxサーバーを作ろうとか考えてるけど。
941:login:Penguin
08/10/11 14:35:59 3CVcp8Gk
>>940
バックアップ先にネイティブではないFSを選択するなんてどうかしている。
942:login:Penguin
08/10/11 16:31:14 ZEc5lvl1
>>941
Windows上でNTFSを使っているからファイルシステムはネイティブですよ。
LinuxのNTFS実装ではなくて、Windowsから直に使っても劇遅なのです。
pdumpfsはWindows用の実装もあって、Windows用はNTFSのハードリンクを使う。
元々pdumpfs自体はLinux上で使うように作られていたので、
Windows移植版は亜流扱いかなと思って、本来の環境(Linux+ext3/XFS)での
バックアップ運用を考えているんだけど、こっちでも同じようにパフォーマンスが
落ちるなら新しくサーバーを作る意味がないのです。
ext3ならハードリンクの削除はi-nodeの削除と参照カウントを変更するだけだと
思うのでパフォーマンスは落ちない気はするのですが、実際はどうなのかなと。
943:login:Penguin
08/10/11 17:05:54 F5yk1I08
>>939
SDなんて規格でSDだとFAT、SDHCだとFAT32を使うことを決められているんだし、
CFやUSBメモリもFSの規格化こそされていないものの、既存のFAT32から変更する
ことなんて相互運用性を考えるとありえないし、FSレベルではできることは
FAT32でwrite buffer回りをフラッシュ向けのパラメータに調整するとか、
かなり限られるだろうからなぁ。
運用面では、いったんHDDなりtmpfsなりに書き出してから、カードを抜く前に
一気に書き出すようにするとか、fsだけでやるよりは、いろいろやれるだろうけど。
944:login:Penguin
08/10/11 21:38:02 g3joq6C9
>>942
そう考えるとVistaのReadyBoostはうまいよな。
HDDよりはるかに高速なリード系キャッシュとしてのみ使って、
ライトはキャッシュしないでHDDにダイレクトに戻すわけだから。
OS側でHDD+Flashのハイブリッドデバイスにしてるようなもん。
Linuxでもaufsとかでうまくラップしたら同じ構成にできるかな？
945:login:Penguin
08/10/11 22:33:13 BChDsKTE
>>944
今ならRAMを大量に積んで、開いたRAMを積極的にキャッシュに使うほうが
有意義だと思うが、RAMよりはるかに低速なFlashを使う意味はあるのか？
946:login:Penguin
08/10/11 22:35:35 3CVcp8Gk
VistaのReadyBoost は思ったほど効果が出ないので廃れてきている。
メモリいっぱい積んでキャッシュした方が速い。
947:login:Penguin
08/10/11 22:39:15 /eNXCR9B
>>945
アイドル時の消費電力
948:login:Penguin
08/10/11 22:51:43 g3joq6C9
>>945
VMwareが使うテンポラリ領域に今はtmpfs割り当ててるけど
メモリ圧迫がきつい。なので、RAMより遅いけどHDDよりはランダム
リードが速いフラッシュに持っていきたい。
でも、いまだとリードキャッシュにのみ使うというような使い分けが
できないのでUSBフラッシュの激遅なランダムライトが思い切り足を
引っ張ってしまう。なので泣く泣くtmpfs使ってる。
949:login:Penguin
08/10/11 23:30:52 BChDsKTE
もちろん環境によって違うが、VMwareならメモリ8GBもあれば
ほとんどオンキャッシュじゃないか？
950:login:Penguin
08/10/12 15:34:42 cHEoGiGP
>>939
USBメモリもＯＳから見たらＡＴＡだ
>>943
おかげで、ＦＡＴ前提で消去動作をするデバイスがいて困る
951:login:Penguin
08/10/12 16:17:22 caxeqjv+
>>929
普通のブロックデバイスでJFFS2を使う方法は、ある
952:login:Penguin
08/10/12 23:38:54 cHEoGiGP
>>951
方法はあるがJFFS2のメリットがまるで生かせないのでオススメはしない。
そもそも、ブロックデバイス経由となるとそれなりに大きなフラッシュが大半だが、
JFFS2は大容量にあまりうまくスケールしない。
953:login:Penguin
08/10/13 03:50:43 /1X8bqTg
>>950
SCSIじゃないの？
954:login:Penguin
08/10/13 05:54:18 Yen7BMcS
>>950
USB mass storage classの立場が…
955:login:Penguin
08/10/13 10:31:00 KYd3m3EJ
>>942
WindowsのNTFS上のファイルをNTFS以外のところに
バックアップするのを>>941は言ってるんじゃないの？
956:login:Penguin
08/10/13 11:56:43 gw7EyGVh
ディスクイメージを丸ごと保存するしか無いことに気付くのさ
957:login:Penguin
08/10/13 16:17:01 0i0p6LYA
結局 dd とか Acronis TrueImage に頼らざるを得ないよな
958:login:Penguin
08/10/19 09:56:52 Y5v4Sc4N
Kernel Log: Ext4 completes development phase as interim step to btrfs
URLﾘﾝｸ(www.heise-online.co.uk)
959:login:Penguin
08/10/19 13:51:01 UH6RFsrQ
btrfsってベターエフエスじゃなくてバターエフエスだったのね
960:login:Penguin
08/10/20 16:30:26 kMVayZDo
NTFS並みにぶっ壊れないNTFS以外のFSないー？？？
961:login:Penguin
08/10/20 16:37:15 iP5zKBzc
>>960
おい、しっかりしろ！
壊れてるのはファイルシステムじゃなくてオマエの頭だ！
962:login:Penguin
08/10/22 08:49:29 I6jwpH/K
NTFS並みに「ぶっ壊れない」NTFS以外のFSないー？？？
じゃなく
「NTFS並みにぶっ壊れ」ないNTFS以外のFSないー？？？
じゃね
963:login:Penguin
08/10/22 10:59:57 NBHzzMxf
みなさまお勧めのFSはなんですか？(2008/10現在)
964:login:Penguin
08/10/22 14:12:28 C4w3eGpm
>>963
ヴぁたーえすえふ
965:login:Penguin
08/10/22 14:12:49 jdRhwaU9
JFS
もっとも中庸
966:login:Penguin
08/10/22 14:42:09 C4w3eGpm
JFSって実用に耐えるような品質じゃなかったような
967:login:Penguin
08/10/22 14:53:47 gVMTbwAJ
NTFS壊れないだろ。あれだけ利用者がいることを考えたら驚異の堅牢さ。
968:login:Penguin
08/10/22 14:55:10 q1aPF8u5
>>967
その点は認めるが、その分安全性に振ってあるせいか遅いんだよね。
969:533
08/10/22 20:05:03 pEgnaN2Y
>>966
個人レベルじゃ分からんね
まだファイルシステムとして問題になったことはないね。
970:login:Penguin
08/10/22 23:25:49 Df2ywAsR
ZFS(`･ω･)
971:login:Penguin
08/10/22 23:27:19 C4w3eGpm
>>969
壊れるわ落っこちるわで
個人レベルで使い物にならなかったから言ったんだが
972:login:Penguin
08/10/22 23:54:29 jdRhwaU9
JFSじゃなくて個人の能力の問題ぽいな
973:login:Penguin
08/10/22 23:58:54 1b7uzJ+6
能力者か
974:login:Penguin
08/10/23 01:03:22 AE+LtDQB
JFSの評価は試した時期によって真っ二つに分かれるよ。
オレはダメダメな頃に試して、開発チームの品質意識の低さに愛想が尽きたクチ。あんなものをv1.0とかリリース版とか呼ばないでくれ・・・
まあそろそろ許してやるかと思わんでもないけど、最悪レベルの悪印象１回で５年は忌避するね。
975:login:Penguin
08/10/23 01:19:26 NIVvYMeo
俺は一昨年あたりに試して駄目だったがな
どこかで「JFSは性能は悪いが安定してる」みたいなのを読んで騙された
三台くらいのマシンで使ってたが愛想が尽きたよ
Squidのキャッシュにしたらカーネルが頻繁にこけるし
数十GBのファイルシステムに使ったら1月も経たないうちに壊れやがった
全面的にxfsに切り替えてからはノートラブル
976:login:Penguin
08/10/23 01:43:33 rce9rSrQ
さすがに嘘っぽいなw
977:login:Penguin
08/10/23 01:53:17 h1GjsnzS
普通にufs(ffs)でいいと思うんだが。
だめっすか?
ちなみに、NTFSはVista SP1/W2K8 からNTFS Transactionが
入ったのがｽｹﾞｰよ。UNIXのFSには同じ機能はないよねえ。
978:login:Penguin
08/10/23 04:20:41 AeDLf20b
ufsとかほとんど使われてないだろ。
transactionは確かにあれば便利なような気はする。
でも実装するとなるとそうとうにvfsの大改造が必要になりそう…。
979:login:Penguin
08/10/23 06:49:03 AE+LtDQB
reiser4に入る予定だったのに・・・
980:login:Penguin
08/10/23 11:58:13 psJByFA2
>>975
ほおー。
以前も書いたかもしれないけど、俺はフェイルオーバークラスタ
の共有ディスクにして、httpdのドキュメント＆ログ兼postgresの
DB置き場にしていたけど、特に問題は起きなかったけどなぁ。
共有ディスクなんで、オンラインでのマウント・アンマウントなんか
も発生したけど、ファイルシステムの異常は発生しなかったよ。
981:login:Penguin
08/10/23 14:22:40 NIVvYMeo
>>980
それってappendと、既に割り当て済みの領域への書き込みしか発生しないだろ
ファイルシステムのテストになってないぞ
982:login:Penguin
08/10/23 20:49:02 xBWodj0l
>>970
ZFSってFUSEで実装してる分のオーバーヘッドってどんなものなんでしょうか？
983:login:Penguin
08/10/23 20:50:42 psJByFA2
>>981
別にファイルシステムのテストを企図して使ってたわけじゃないが、
頻繁にWebコンテンツの追加・削除は発生してたし、ファイルの
アップロードも存在したし、とあるシステム向けのデータファイルが
日ごとに追加されてたんで、それなりに負荷はあったと思うよ。
984:login:Penguin
08/10/23 21:25:23 IxMIJ6A4
とはいえ、やっぱりある程度特殊な環境かと。
webコンテンツの更新やらファイルのアップデートなんて、いくら頻繁でも
たかが知れている。
共有は共有でも開発環境のファイルサーバで、しょっちゅう
makeが動くとかなら話は全然別だけど。
985:login:Penguin
08/10/23 23:31:32 sA6CnTJk
ウチは、今年前半にメールサーバ、Webサーバのデータ領域として導入。
533にあるとおり、PPC Ubuntuで。
メールは、IMAP管理で基本的にスパムも削除しないで単純増加がほとんどかな？
あと、ファイル管理のスワップファイルをおいている。スワップはあまり使われてない。
とりあえずjfsだからってことで困ったことはない感じかな？
986:login:Penguin
08/10/24 00:50:46 BMCuftSP
データベース以外の用途なら、やっぱZFSがいいよなぁ。