1 :
名人 :
04/11/27 03:54:53 ID:8Lik61Wh
2 :
名人 :04/11/27 03:56:25 ID:8Lik61Wh
3 :
login:Penguin :04/11/27 05:30:22 ID:BoNdqPq1
6
んで結局教祖様の話は合ってるの?間違ってるの?昔話なの?
このスレにモートンたんが後臨して大丈夫だと言ったら漏前は信じるのか?
結論だけ書かれても信じない。 でも根拠となるソース張ってくれたら読んでみる。
究極のファイルシステムと至高のファイルシステムの対決スレ
教祖様は根拠となるソースなんか張ったっけか?
結局ただのFUDか。 SCOとやってることは同じだな。
13 :
login:Penguin :04/11/28 20:44:48 ID:QSWmc7rf
結局、前スレで少し話題になっていた、SCSIケーブル抜いても Postgreの書き込みが成功してしまうRedhatのバグはどうなったん だっけ?まだ放置プレイ状態なの?
>>13 そんなに気になるならRedhatに質問してみたらどうだ?
そこまで気にするなら普通 Oracle で raw device 使ってると思うけど
linux の raw device はその為にあるんだし
15 :
13 :04/11/29 00:46:31 ID:63X2cRJt
>>14 oracleはraw device使っているの?(知らないので質問)
ということは自前でファイルシステムをもってるわけだ。
本当のところは、システムコールをトレースしてみれば
わかるんだろうけど。
前スレでは、ドライバがあやしいっていってたからraw device
だったとしても影響うけるよな。
そんなに重要なデータなら、2重化しておきなさいってこった。
整合性の取れてないデータを複製してもな(w
>>17 君の頭の中では、2重化ってハードディスクのミラーリングしか思い浮かばないの?
VFATの仕様を読めるサイトありませんか? 知りたいのは、ロングファイルネームからショートファイルネームを 生成するアルゴリズムです。それだけわかればセクタ単位でVFATを 読み書きするのに必要な情報が揃います。
>>15 まともなDBならたいていは raw モードを持っていると思われ。
>>19 ふつーに kernel 読めばいいんじゃない?
で、結局Linuxで一番信頼のおけるファイルシステムって何なの?
何をもって一番かということは一概に言えないから普通は自分で用途を考えて選択するものだが 他人に聞かないとわからないような素人さんには ext3 を勧めておく
俺は一生XFSについていく。 その次って言われたらJFSかな。 やっぱり会社が作っているFSのほうがいい。
このスレ、一瞬「ブロックデバイス総合スレ」になるかとオモタ(w
>>24 NTFSとかVFATはどうなのよ?とか、会社無くなったらどうすんの?とか聞いてみよう。
洩れもXFSは好きなんだが、その次はreiserfs/ext3かな。
jfsは初期に悪い印象持ってしまったのでな。
tmpfs
initramfs
29 :
名人 :04/11/30 02:54:04 ID:rGSC9TyP
俺もXFS XFS > reiser4 > reiserfs > ext3 > ext2 JFSはいいかなと思ったけど、XFSのがいい。
大規模なサーバ、特に大きなファイルを保存するところにはXFS 小さなファイルが沢山保存されるようなところ、速度重視の場所にはraiserfs /bootや/rootなどにはext3 という感じで考えて使い分けてまつ。あまり意味無いかもだけど、 1TB超えるとext3やext2はとても使えないし、その辺ではXFSは安心できる。 (raiserfsも不安)。/bootにext2,ext3以外を使うのもなんとなく心配。 raiser4は興味津々
XFSのターゲットとしている分野はストレージを導入することが多いから、 各社ストレージの管理ツールとの相性とか考えると、VxFS/VxVMセットで使うのが現実的なんだがな。
でも、VxFS & VxVMはVeritasの結構高額な商品だからねぇ。あと、Solarisなどでの 動作実績はすごいけど、Linuxだとちょっと不安だったりする。おそらく杞憂だろうけど。 あと、大容量相手でもufs2 + dirhashは安定性とそこそこの性能で結構素性が いいなぁとか思うんだけどどうよ。Linuxでは完全放置されてるけど…。
>>30 /boot にext3要らないのでは?ext2で良いかと。
自分はカーネルにXFSを組み込んじゃって (モジュールじゃなく)
/ は XFSにしてます。
スタンドアロンのものじゃないけど、誰かGFS使ってる人いたら、
設定や管理の難易度や安定性や速度の感触を聞かせてほしいなぁ。
>>32 完全放置されてるってのはLinuxのUFSドライバのこと?
それともext3のhtree系の話のこと?
>>26 >jfsは初期に悪い印象持ってしまったのでな。
って何か具体的な不具合があったの?
>>35 bugかどうか知らないけど、データ飛ばされただけ。
>>34 Linuxのufsドライバのほう。今年ようやっとufs2がread onlyでサポートされたけど、
それ以外はほんと捨ておかれている状態。以前からufsなんて読めりゃそれでいいや、
使う気はないという感じだったけど、それがずっと継続中。
ちなみに俺は/usrとか/bootをroでマウントしないと我慢できない派。
40 :
login:Penguin :04/11/30 18:13:31 ID:CtDt1ZMn
漏れは swap と / のみのマンドクサイ派
41 :
39 :04/11/30 20:47:49 ID:efEdTJby
>>40 俺はこの前までそうだったけど、
本格的な鯖依頼されたときにかなり考えた結果、システム部分はroにした。
とは言えども、用途的にFreeBSDにしたけどねw
42 :
login:Penguin :04/12/03 09:30:53 ID:cPtMSMKE
>>41 それでいろいろと不具合でたりしない?
まぁ noatime で構わないわけだし、問題ないんだろうなぁ、とはおもうけど、
その「システム部分」の切り分けが面倒だったりしない?
仕事だったら面倒とか言ってられないか。
>>34 > それともext3のhtree系の話のこと?
丁度それについて知りたかったのですがこれってまだ取り込まれてないのですか?
なんか随分前にこのパッチのことは読んだのですが現在の状況がよく分からない。
>>42 /usrや/bootだったらほとんど問題ないでそ。/をroにすると面倒だけど。
/homeや/varをrwにし、/tmpを/var/tmpへのsymlinkにしておいて一安心かと
思ったら、/etcがroになっているととんでもないことになったりするし。
>>43 htreeパッチ、orlov allocaterパッチとも2.6系には既にとりこまれているけど、
2.4系には入っていない。
2.4.21の頃まではTsoがhtreeパッチが作ってたけど、今は誰もやってない。
当時のパッチを単に2.4.28にあてるようにいじくったものだったら提供できると思うが、
2.6系でどのように修正+発展しているかわからないので、あまり意味ないだろう。
2.4.23の頃に使ってVM絡みっぽいエラーがボツボツでたので俺は今は使っていない。
たいして速くなった気もしないし(reiserfsのほうが速いのはかわらず)
swsuspパッチとかみあってなかったのかもしれんが…。
>>45 ああ、やっぱり2.4系では採用されなかったのですか? それは残念。
> たいして速くなった気もしないし(reiserfsのほうが速いのはかわらず)
たしか1ディレクトリに大量のファイルがある(>数万)場合のスピードの
向上が劇的であると理解しているのですが。 2.6でテストしてみようと思います。
もまいら、各ファイルシステムの特徴を一覧にまとめてくれ と荒れそうなことを書いてみるテスト
>>48 ext2.......使いものにならない
ext3.......使いものにならない
reiserfs...使える
xfs........使える
jfs........使いものにならない
nfs........使える
>>52 ext3 って使いものにならない?
うん、たしかに大量のファイルをおいてコンパイルしてるとき、
reiserfs の上でやった方が早いね。
それ以外の FS は使ったことないからなぁ。
xfs はバックエンドのファイルサーバで使っているけど、
どうせネットワーク後しだからあんまりわかんない。効果が。
なんで ext2/3 って reiserfs よりおそいんだろう。
そりゃ、reiserの方が後発で、ext2/3の弱点を分かってて作ったんだから、
reiserfs って地雷だった時期があるから、今でも恐いなぁ。
コンパイルなんてtmpfs上でやればいいじゃん
LinuxのNFSの実装はあんまりいいとは思えんが…
>>58 どのversionの話?
それによって大幅に変ると思うが
v3モナー
62 :
名人 :04/12/13 08:33:24 ID:avVmPVEh
smbfs < cifs < ncpfs NFSはLinux同士なら悪くないと思う。
ん? そのわりには、linux-nfsのMLに日本人の投稿が 「全然」ないが?
MLの投稿と何が関係あるんだろう?
ext2fs 枯れてて、速い。ジャーナリング無しなので、マシンが突然落ちたときにはいやな目にあうかも。 ext3fs 現在のlinux用fsの主流。それだけで使う価値ありまくり。 reiserfs クソ jfs 内部ユニコード格納なので、デフォルトのロカールが変わっても、ファイルリネームの手間がない。アクセス速度は結構遅い。 xfs 大容量ファイルを使用する人向きらしいが、体感不能。 fat 軽い。多くの環境で使用できるので便利。cfブートだと結構linuxでも使われているかも。 ntfs linuxでは書き込みが不完全なのでどうでもいい。 tmpfs 最強。どんなfsもこれには勝てない。
vxfs 同バージョンであればSolaris←→Linuxでディスクのやりとりができる。 よって、マイグレーションにも使えるし、Linuxをバックアップサーバにしたりもできる。 いろんなメーカーのストレージでの実績もあり。
tmpfsのいいトコも書いてくれ
>>65 ext3fsの使う価値ありまくりって…
reiserfsは互換性問題で懲りてる人は確かにいるな。結構速いけど。
>>67 速い。これに尽きる。
洩れはbuild時に多用している。
tmpfs上でカーネルコンパイルが余裕で出来るぐらいにメモリー積んでみてー
70 :
名人 :04/12/14 07:49:33 ID:2CTSu3na
reiserfsは糞じゃないけどなぁ。小さいし速い。 jfsの方が糞。 xfsは大容量ファイル使わなくても速いよ。でかいけど。 fatはvfatだろう。 ntfsはデュアルブートでも無い限り要らない。 tmpfsは速い。 ext2/3もsecurity label, POSIX ACLとか追加されてるけど、 そろそろ他の選んでもいいと思う。 xfs + ext2/3 それなりのサーバ reiserfs + ext2/ext3 小さいサーバ/WS
65じゃないがreiserfsは経験上、電源ぶち切りで3度ほどトんだ。 最悪だったのは、すべて壊れて/がすっからかんになってた。 マジで( ゚Д゚)ポカーン 漏れの中では糞認定。
>>69 1.5から2GBくらい普通に積めるだろ。
:/usr/src/linux-2.6.9 $make O=/tmp/2.6.9 ってやればいいじゃん。100MBもいらない。
/{bin,lib} /usr/{bin,lib} くらいまでメモリ上に置いておきたい今日この頃。
>>75 ext3はext2から派生してるけど、コードがかなり書き直されてて
ext2にジャーナリング加えただけよりは良いと思うが。
Linuxのvfsはどう思う?
>>77 コードレベルではext3のコードは全面的に書き直されていていいのですが、
根本がext2というのは変わらんので…。
vfsについては、詳解Linuxカーネル第2版や2.6系のlinux/fs/buffer.c等のvfsな
コードを見ると、以前のバージョンに比べて格段に良くなっている感じはするけど。
おいおい、本当に書き直されてんのか? 詳解Linuxカーネルなんぞでvfsを語ってるあたりニオイますが。
ソースくらい読めよ その程度でvfsを語ろうとしてるのか?
>>80 自分で読んでいそうな78に比べて、お前はただの口だけしったかだな。
このスレにソース読んでfilesystemの話をする香具師が後臨したためしはありませんが何か?
ドキュメントを読みかじった香具師ばかり。
VFSとext2のどのあたりが不味いのか、ソースコードを含めて語れる人キボンヌ。 どっかで聞いたような風評は、この際どうでもいい。
87 :
名人 :04/12/15 06:20:00 ID:WrV5e22H
>>71 漏れは、2.4, 2.5, 2.6混在時には何回か吹っ飛ばした。
あと、ジャーナル領域が壊れるとマウント出来なくなったりして悲惨。
復旧もext2/3の方が慣れてて楽だね。
最初はジャーナリング勘違いして、ファイルが復旧されないから糞だと思ってた。
reiserfsの場合、ファイルシステムの整合性しか見てないのにね。
2.4, 2.5, 2.6混在ってのはカーネルのバージョン? reiserfsのバージョンは3.6で統一されててもそうなるの? ブルブル… ところで、badblocksを避けてmkfsできるものは ext2/ext3 - できる reiserfs - できる jfs - できない xfs - できない という理解でいいのかな。(一応ググりましたが) ファイルシステム復旧の際に新しくbadblocksが見つかった場合に どう処理するかものかはよくわかってないが。
>>88 Bad Blockにddで書き込んでみたら?
代替セクタに切り替わるかもしれん。
badblockをファームウェアが修復してくれるHDDって いくらぐらいするもんなの?
>>88 かなり前のHDDを使っていなければ bad block relocation はもう不要な機能といっていい
>>90 5000円以上はするんじゃないかな。中古だともっと安いかも。
ちょっと不親切な説明だな 5年以上前から一般に出荷されるHDD(IDEやSCSI共)はドライブ自体にbad blockを 予備のblock(extra block)に自動的にremapする機構が入ってる つまり外から見ればbad blockが無い状態に保たれている (内部的なbad blockの数はS.M.A.R.T.でmonitorできる) OSからbad blockが見えるということはドライブのextra blockを使い果した状態で 確率的にbad blockが限度を超えたというより、ドライブ自体に何らかな問題があって 積極的にbad blockを作っている状態、つまりHDDが「死にかけ」の状態である可能性が 非常に高い HDDがハード的に死にかけの状態で使用を続けると、OSやfilesystemに関係無くドライブ データは加速度的に破壊されてしまう だから今のHDDでbad blockが見付かったら余計な操作をせずにRAIDであればHDDを交換 そうでなければ即刻umountして、dump等で残せるdataをbackupしてHDDを交換したほうがいい 昔はそういった機構が無いのでfilesystem自体がbad blockを弾かないといけなかったが 今はむしろそういう操作はしないほうがいいというのはその為
>>93 >OSからbad blockが見えるということはドライブのextra blockを使い果した状態で
そうとも限らない。エラーセクタにはふた通りあって、ひとつは書き込みエラーに
なるもの。これは物理的に壊れているもので、ドライブが自動的に代替処理を行う。
もうひとつは読み出しエラーになるもので、書き込み中の電源断などで中途半端に
書き込まれた状態になったもの。これはドライブが自動的に判断するわけにいか
ない(何せデータが読めない)ので、本格的にエラーになる。coreを吐いたりpanic
したりすることすらある。でも、読めないセクタにデータを書き込んでやるだけで
何事もなかったように直る。
というようなことはドライブメーカが配っているtechnical specificationとかその類の
ものに書いてございます。楽しいので御一読あれ。
>>93 , 94
勉強になります。
XFSのMLでも
「badblockを避けてmkfsするオプションはないか?」
という質問が
「badblockが出たHDDはどんどん壊れていくから
そういう無理な使い方はせずに買い換えるべきだ」
という回答で一蹴されていました。
S.M.A.R.T.については
http://smartmontools.sourceforge.net/ あたりを参考に勉強してみようと思います。
俺の経験だと「○○まわりが云々」って言う奴の知ったか率85%ぐらい
>>93 漏れは3年前ぐらいに買ったノート付属のHDDは使用半年ぐらいでbad blockが出た(--;。
買ってからほぼ毎日使い続けてるが、今でも問題なく使えてる。
実はラッキーボーイだったのか。
>>74 遅レスだがそういうinitrdを作ってはどうか
超初心者スレからやってきた者ですが、一つ気になることがあるので 質問させていただけないでしょうか。 私は最近Linuxを勉強し始めたのですが、NTFS(Windows2000)よりも ext3(RedHatLinux)のほうがファイルの読み書きが早くなったみたいで、 その理由がずっと気になっているのです。 どなたか詳しい方の御意見を聞かせてくれませんか。
>>100 残念ですが、詳しい人は、このスレには、いないです。
ファイルの読み書きにはそれぞれ何を使う話なんだろう?
103 :
100 :04/12/19 01:34:05 ID:8O1ekwSr
私は5kbのテキストファイルを5000個ほど作って削除するプログラムを 作ってみたのですが、どうもRedHatLinuxで実行すると、Windows2000よりも 4倍ほど速かったのです。
とりあえずLinuxは非同期書きこみのためディスクアクセスをさぼっているとか
105 :
100 :04/12/19 01:51:41 ID:8O1ekwSr
>>104 レスありがとうございます。私は「非同期書き込み」という言葉さえも
知らなかった超初心者なので、大変勉強になりました。
ext3のmountオプション async と sync で比べて見てくれ。
Windows2000のNTFSはデフォルトでは UNIXで言うところのどういうmountになってるんですかね? USB/IEEE1394 HDDをひっこぬいた時の 「遅延書き込みを損失しました」 みたいなメッセージからするとasync相当なんでしょうか
> USB/IEEE1394 HDDをひっこぬいた時の XP だと、遅延書き込みしないようにできるけど、2k はどうなの?
> 「遅延書き込みを損失しました」 こんなメッセージ出すんだ。 linux なんかだと umount せずにこんなことしたら フリーズしそうだけどね。
よそでやってくれないかな
111 :
名人 :04/12/19 07:40:54 ID:EVa/7se6
>>109 しないよ。
NTFSってファイルの削除は間違いなく遅い。
ジャーナリングのせいかもしれないが、xfsの方が圧倒的に速い。
ext3は使わないから知らない。
ファイルシステムの性能を測るベンチならあるけど、 信頼性を測るものってのはないの?
>>112 >>7 から読みなおせ
━━━━━ 終 ━━━━━ 了 ━━━━━━
>>106 ext2のsyncはアホみたいに遅くないか?
真面目にメンテされてないんじゃないかと思うのだが。
(どこかにext2 syncをそれなりの速さにすると言うWeb Pageがあったような気が)
ext3は改善されているのかな?
>>114 教祖様が紹介してたやつな。
ISPかなんかの依頼仕事で2.2.16ぐらいまでやってたけど
勿論それ以降のカーネルにはそのパッチはあたらない。
syncは真面目にメンテされてないだろうね。
ext2のsyncは遅いのにsyncならない意味ないヤツじゃなかったっけ?
また人の受け売りですか。
ext2なんて誰も使ってないんだし、受け売りでも腐っててもいいじゃん。
120 :
login:Penguin :04/12/19 19:16:48 ID:8Y+ZrQby
( ゚Д゚) ポカーン
121 :
login:Penguin :04/12/19 21:02:56 ID:nzVnVeqj
xfsの方が速いとか使い門になるって言っている奴ほんとかよ。 どっかでlinuxのファイルシステムなかでおせーって記事読んだことあっぜ。 ベンチマークとかしてんの?イメージでは話してねえ
xfsがイイと言った名無しの2chネラーがいたらしい。 xfsは遅いと書かれた謎の記事が存在したらしい。 嘘を嘘と見抜けないと2chを使うのは難しいらしい。
わかったから教祖様の言うとおりFreeBSD使って 相談はUNIX板でやってくれ
\ ∩─ー、 \/ ● 、_ `ヽ / \( ● ● |つ | X_入__ノ ミ そんな餌では釣られないクマよ 、 (_/ ノ /⌒l ニヤニヤ /\___ノ゙_/ / 〈 __ノ
125 :
名人 :04/12/20 07:11:25 ID:hc+CVuZ3
>>121 fsによって得手不得手があるからなんとも。
xfsはファイルの削除が遅いとされてるけど、気にならないし。
少なくとも使い物にならないということはないと思うけど。
xfsよりreiserfsの方が速いと思うけどね。
>>111 asyncという言葉を調べてくるように
>>114 ext3もsyncは遅いし、ジャーナルもdata=journalなんてすると、とんでもない
ことになる。デフォルトオプションでの運用しか考えられていない印象。
あと、data=writebackでext3使っているヤシも稀ににるようだけど、
ジャーナルの意味がほとんどなくなるんで、よく考えたほうがいい。
偉そうな人キター
128 :
login:Penguin :04/12/20 16:16:23 ID:5UdRzMj2
ext3 で盛り上がっているところ申し訳ないが、 udf は書き込み途中でブッチしたら危険? やはり書き込みの途中でファイルシステムが「破壊」されている 瞬間があるのかな? DVD-RAM 書き込み中にフリーズした場合なんかどうなるんだろうと思って。 映像用の DVD-RAM, +RW, -RW ビデオレコーダーなんか、家電だから、 パソコンよりももっと頻繁にブッチされることもあるんじゃないかなぁ。
129 :
login:Penguin :04/12/20 17:00:31 ID:5UdRzMj2
130 :
login:Penguin :04/12/21 23:54:02 ID:aXlAc1hr
/や/bootも含めてすべてXFSにしちゃってgrubで起動出来ている人いますか? grubのページ見るとせめてinitrdを読み込むためにも/bootだけはext2かext3 じゃなきゃいけないように思えたんですが。 でもふつー/bootは障害時の復旧しやすさを考えてextにしとくものですかね?
>>130 全部xfsにして使ってるよ。
grubなら jfs でも reiserfsでも大丈夫。パッチ充てればreiser4も可能
復旧も別手段で起動した時xfsが使える状態なら変わらない
132 :
login:Penguin :04/12/22 00:56:33 ID:EL67IdFL
>131 おー!出来るんですか。 週末に環境の引越しをするので試してみます。 ちなみに復旧はKNOPPIXなどでXFSを読めるようなのでこれもやってみる つもりです。
>>130 まあ、xfsならいいのかな?
reiserはオプションをつけておかないと大変なことになる可能性がある。
>>130 xfs+grubだと起動できない環境があったりなかったり。
まったく検証してはいないのでアテにならん情報だが、ちょっと前にインストールした
環境ではサックリ入ったんだが、先日インストールした端末は起動しなかったなあ。
Debianのインストーラでも警告が出るね。
調べる時間もなかったので、/ はext3で/tmpはext2、残りはxfsで逃げた。
そりゃ、Debianのインストーラといっても、数あるわけで。正式版のwoodyの インストーラだとliloしか使わんから問題外だし、sidのβ版インストーラだと その日付によって挙動が違う。
いや、だからsidのインストーラだと標準でgrubを使うわけだが / をxfsにすると
liloをインストールする流れになる。手動でgrubを入れようとすると、わざわざ
警告画面が出てくるってこと。
もちろんunstableだし、buildによって挙動が違うだろうが。
>>130 は試してみるって話だが、問題が出る可能性もあるよって話なだけ。
XFSのパーティションの先頭にgrubが入れちゃだめだからな お兄さんとのお約束だ
そういえばxfsのpartitionにgrubのstage1を入れると壊れるって話があったような 私は幸いMBRに入れることができる状態しか経験してないからそういったことには 遭遇してないがMBRに入れられない場合もあるしなあ
139 :
login:Penguin :04/12/22 09:30:02 ID:zEZ8wPjW
ブート用のパーティションにまで xfs を使わなくってもいいと思うんだがなぁ。
>>139 /boot に関してはそうだな。
カーネルを更新するとき以外マウントする必要の無い
パーティションをXFS(やreiserfs)にするのは無駄。
141 :
login:Penguin :04/12/22 10:56:42 ID:dmPGaRKi
面倒だから1パーティションでやりたい。 (swapはファイル)
kitty-guy みたいな広い空間がない限り、 1 パーテーションって何かあった時に余計に面倒。
xfs使う香具師は/bootを分けとけ、でFAか。
いや、grubはMBRに突っ込めじゃないか。
一般論は不要。
君は何を求めるのか。
147 :
login:Penguin :04/12/22 17:55:17 ID:zEZ8wPjW
UDF の堅牢性についてちょっと調べてみたけど、
>>129 より詳しいページが見付からなかった。
もし UDF の堅牢性についてのいいドキュメントがあったら紹介してください。
>>129 DVDレコを数年、PCでもDVD-RAMドライブつないでいろいろやってきた経験上は
いきなり電源遮断されたときの耐性はかなりあって、メディアの物理的損傷
以外でファイル損傷したことはないんだけど、HDDほどには頻繁に書き込み
アクセスしていないからなぁ。
>>144 ウチのはgrubをMBRにつっこんだらgrub動かない。残念。
150 :
129 :04/12/23 12:30:54 ID:ktejHevI
ブルーレイ関係の資料を読んでみた。 UDF (Revision 2.5) has been developed considering the needs for next generation larger capacity media. To accommodate the needs of large capacity media, UDF 2.5 has added the Metadata File and Metadata Mirror File features. The Metadata File allows clustering the file system metadata (file management information, such as file entries and directories) and improves performance for accessing multiple directories. This feature enables faster start up and scanning of the disc, including better support for many utilities such as the check disc utility. The Metadata Mirror File, which is optional, is used to increase the robustness for archived data on the disc since the same metadata is recorded in the Metadata File and the Metadata Mirror File.
151 :
129 :04/12/23 12:34:41 ID:ktejHevI
OSTA の資料を見付けた。 2.2.13 Metadata Partition The files and policies defined in this section facilitate rapid location of all metadata in the volume, promote clustering of ICBs / directory information, and optionally facilitate duplication of all metadata. This will, in most cases, greatly speed file system repair operations by eliminating the need to perform an exhaustive media scan, or directory traversal, solely for the purpose of locating ICBs. The clustering of metadata will also significantly improve performance of metadata intensive implementation operations. When the metadata duplication option is chosen, file system robustness to media damage is increased, at some cost to performance. When a Type 2 Metadata Partition map is recorded, the Metadata File, Metadata Mirror File and Metadata Bitmap File shall also be recorded and maintained.
152 :
129 :04/12/23 12:37:58 ID:ktejHevI
>>151 のは OSTA の UDF Document Change Notice DCN-5086 の PDF からの抜粋なんだけど、
本体資料(これも PDF でみることができる) の
2.2.13 Metadata Partition のところを読めば詳細がわかるようだ。
まぁ大体のことはわかったので、詳細は暇な時に読むとにするか。
結局 Metadata Partition と Metadata Mirror File がキーワードだったんだな。
これらのキーワードで検索してみると関連文献が結構出てくる。
ファイルシステムの拡大+縮小ができるのって extとreiserfsだけでしょうか? XFSは拡大はできるけど縮小ができない・・・
今はな
Kernel 2.6.9だけどbefsって書き込みはできないの? なんとか書き込む方法あればきぼん OpenBeFS for Linuxなんてないのかな?
64bit kernel で fs はどうなの?というチラシの裏 CPU: Athlon64 3500+ chipset: nForce3 Ultra memory: DDR400(dual channel 1G) OS: linux 2.6.9-ac16 (gcc-3.3.5 x86-64) SATA: Sil3512(sata-sil libata) HDD: HITACHI Deskstar HD722525VLSA80 (250G) bonnie++(1.03) ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Size K/sec % K/sec % K/sec % K/sec % K/sec % /sec % xfs 2G 49129 80 52141 *8 20293 3 36957 59 58771 6 189.1 0 jfs 2G 43784 70 53593 *8 21718 3 37595 59 58548 5 179.5 0 reiserfs 2G 41325 68 59055 14 22192 4 33266 54 47920 6 166.3 0 ext3.orderd 2G 25945 45 33059 *9 14837 3 36093 57 36531 3 154.7 0 ------Sequential Create------ --------Random Create-------- -Create-- --Read-- -Delete-- -Create-- --Read--- -Delete-- files K/sec % K/sec % K/sec % K/sec % K/sec % /sec % xfs 16 *4502 19 ***** ** *3614 13 *4091 20 ***** ** *1966 *8 jfs 16 11198 14 ***** ** *8280 *9 *6370 26 ***** ** *6726 17 reiserfs 16 ***** ** ***** ** 29445 94 31978 93 ***** ** 26643 96 ext3.orderd 16 *2826 95 ***** ** ***** ** *2555 86 ***** ** 11204 94
分散ファイルシステムのスレはないか? できれば、クロスプラットフォームがよい。 できれば、Windowsからも利用できるのがええ。
>>158 SAN入れる。ファイルシステムじゃないけど。
Windowsから使えると言ったら、NFSかCIFSじゃない?
DAV。遅いしApahce + mod_dav + mod_davfs環境のDAVなフォルダを Winでドライブマップするとトラブル頻発するけど。
ん?
163 :
login:Penguin :04/12/27 00:05:52 ID:UYWn4P41
130す。報告が遅くなってすみません。 /以下/bootも含めてすべてxfsにしてgrubで起動出来ました。 やったことはxfsをkernelに組み込みにしてinitrdを展開、linuxrcを編集して マウントオプションをxfsにする。んでfstab書き換えて再起動。 無事に起動出来ました。 でもなんかGrubのメニュー画面が出るまでにひっかかりがある感じです。 (一瞬考え込んでる感じ。) 一度/bootだけでもext2か3にしてみようかな。。
ちょっと気になったんだけど、NFSで1GBのファイルを扱っているときに、 ファイルの中身を1byteでも書き換えたら1GB分全部送信しないといけないのですか? CIFSではそういう仕様みたいですが。
161は貧乏人
でもあまり使われてない
普通に使ってると、それほど速く感じない。 なにより、あえてJFSを選ぶ動機がないんだよね。 ext2/3は外すとして、手軽さでreiserfs。 機能の多さでXFS。専用だけどdump/restoreもある。 JFSはSELinux使えないしねー。 内部unicodeって嬉しいのかな。日本語だとマッピングの問題もあるし。
そうか、jfs は内部コードが Unicode なのか。 ext2/3 や reiserfs では内部コードってのは決まってないよね?
結局、Reiser4が最強でFA?
いちおうNFSの話も出てきたんで。 2.6系ってNFSが改良されたとのことだったけど、少なくとも2.6.8までは マルチプラットホーム環境(クライアントにSolaris 8やFreeBSD) でNFS server にすると1週間で2回もkernel panic起しやがった…。2.4系のときは落ちたこと なかったのに。 2.6.10でNFSのfixがたくさんあったんで、とりあえずkernelを入れかえてみたけど、 これで安定運用できるかなぁ。とりあえず3日は落ちてないけど。
>>172 tcp/udp, 2/3を明記して話しなさい。
実装のレベルが全然違います。
パフォーマンスより安定性を取るならv2に戻すこと推奨。
NFSv4はー?
>>175 v2だとfile lockがなぁ…。mail spoolだし。
mail spool形式はMaildir++だから本来はあんまりクリティカルに考える必要は ないはずなんだけど、qmail周りやcourier周りでは問題なかったのに、 qmailadminからのユーザ作成やezmlmでのML管理まわりでトラブル起きたんで…
ああ、けどlock廻りって、仕様としては、NLM 4になっても、 ・offset_tに64bit使える、 ・NULL procedureが出来た だけしか違わないけどね。実装に問題があるのかな。 NFS v2: NLM v1, v3 NFS v3: NLM v4
>>179 その辺はクライアント側の問題もあるしね。でも、lock周りでトラブルが
起きるぐらいならともかく、NFS serverがkernel panic起すのは問題外なんで、
v2での運用も考えてみようかな…。って、それならkernelを2.4に戻してv3使う
ほうがいいか。
にしても、2.4の時は全く問題なかったのに、なんで2.6でkernel panicが頻発
したんだろ? 2.6.10で治っていればいいんだけど…。ちなみに、いまのところ
2.6.10で3日と6時間は連続稼働しております。せめてあと4日間持ってくれ…
lock関係結構書き変ってます。fs/nfs/file.c 後はaio, nfs4関連。 v2で駄目なら2.4に戻すの推奨。
結局、素直にkernel 2.4でv3という昔の環境に戻しました。年始じゃ なければ2.6.10の耐久試験をするのもよかったのですが、あと3日間は kernel panic起こされると対処のしようがないので…
パッチで修正される個所↓のような返り値見てなさっぷりにワロス diff -Nru linux-2.4.29-pre3-bk2/fs/ext3/fsync.c linux-2.4.29-pre3-bk2_fix/fs/ext3/fsync.c --- linux-2.4.29-pre3-bk2/fs/ext3/fsync.c 2002-11-29 08:53:15.000000000 +0900 +++ linux-2.4.29-pre3-bk2_fix/fs/ext3/fsync.c 2005-01-04 19:58:32.000000000 +0900 @@ -69,7 +69,7 @@ if (test_opt(inode->i_sb, DATA_FLAGS) == EXT3_MOUNT_WRITEBACK_DATA) ret |= fsync_inode_data_buffers(inode); - ext3_force_commit(inode->i_sb); + ret |= ext3_force_commit(inode->i_sb); return ret; }
たしかにSolarisを参考にしたところでなおらんわな(w
ちなみに、2.6のfs/ext3/fsync.cのext3_sync_file()を見ると int ext3_sync_file(struct file * file, struct dentry *dentry, int datasync) { struct inode *inode = dentry->d_inode; int ret = 0; J_ASSERT(ext3_journal_current_handle() == 0); if (ext3_should_journal_data(inode)) { ret = ext3_force_commit(inode->i_sb); goto out; } if (inode->i_state & (I_DIRTY_SYNC|I_DIRTY_DATASYNC)) { struct writeback_control wbc = { .sync_mode = WB_SYNC_ALL, .nr_to_write = 0, /* sys_fsync did this */ }; ret = sync_inode(inode, &wbc); } out: return ret; } ってな感じで大きく書きかわっている模様。2.6のext3は一から作り直した という話が実感できるなぁ。
あのう、件のパッチですが、 2.4.x系へのパッチはfs/ext3またはfs/jbd以下なのに対して 2.6.x系へのパッチはfs直下なんですが…これはどう考えたら…
>>188 fileの置き場所が変わったという話ではなくて?
>>189 2.6.10-bk6へのパッチでは
fs/buffer.cのfile_fsync ()
fs/fs-writeback.cのwrite_inode_now ()
fs/inode.cのgeneric_forget_inode ()
fs/jbd/commit.cのjournal_commit_transaction()
が書き変わり、include/linux/fs.hでwrite_inode_now()がvoidからintに
変更されているわけだけど、これって他のfsにも波及するんじゃないかって
ことでそ。
191 :
login:Penguin :05/01/11 12:41:34 ID:APWyOerl
Filesystem 1k-blocks Used Available Use% Mounted on /dev/md0 2068476 610616 1352788 31% / /dev/hda2 21958 3404 17420 16% /boot /dev/md1 3102836 288668 2656552 10% /var /dev/md2 13624648 13166756 0 100% /home 使用率が100%になってしまいました。 原因は、root のメールボックスが一杯になっていたためで、dele コマンドでメールを全部削除して、 システムを再起動してみたんですが、上記に変化はありません。 du で調べると、root のメールボックスのフォルダ以下のサイズは減っているんですが・・・ ファイルの更新ができなくて困っています。 どうすれば良いのか教えて下さい。
釣りですか?
193 :
login:Penguin :05/01/11 16:23:54 ID:APWyOerl
ちがいます。 本気で困っています。
>>193 rootのメールボックスとやらは、/root以下にあるのではないかな?
/homeが100%になってるのに、/root以下を削除しても、意味ないのではないかな?
195 :
login:Penguin :05/01/11 16:37:59 ID:APWyOerl
>>194 root 管理者のことです。
よくわからないんですけど、システムで何かあるとメールが送られてくる奴です。
/home の下にあるメールボックスです。
今も調べていますが、何も改善されません・・・
普通は、rootのメールボックスは、/root以下にあるものなんだけどね。 移動したの? ただ単に、ファイルがいっぱいなんじゃないの? 普通に不要なファイルを消せばいいと思いますよ。 /dev/md2 13624648 13166756 0 100% /home 見る限りは、きっちり100%ってわけじゃないと思うよ。
197 :
login:Penguin :05/01/11 17:16:45 ID:APWyOerl
>>196 FTPでファイルをアップロードすると
452 Error writing file: No space left on device.
と出続けてしまいます。
小さいファイルなんですけど。
iノードの数は? df -iしてみて。
199 :
login:Penguin :05/01/11 17:23:00 ID:APWyOerl
Filesystem Inodes IUsed IFree IUse% Mounted on /dev/md0 262752 46064 216688 18% / /dev/hda2 5688 26 5662 0% /boot /dev/md1 394400 4082 390318 1% /var /dev/md2 1733312 390146 1343166 23% /home これでいいですか? ちなみに、その後も、少しファイルを削除しました。
エラーメッセージが出ると同時にsyslogにも何か記録されてるかも知れないから、 /var/log/messagesとかチェックすると何か分かるかも。
>>191 これのいったいどこがfsスレの話題なんだ? しかもageてるし。まったくバカの
やることときたら…
/dev/md2って、ソフトウェアRAIDですか? rootへのメールになんて書いてあったんだろう。
203 :
191 :05/01/11 18:56:01 ID:APWyOerl
>>200 ログからは何も得られませんでした。
>>201 じゃあ、ファイルシステムってどういう意味?
>>202 違います。
du すると、途中でとまってしまいます。
大きなファイルが見当たらないのですが、どうしてなんでしょうか・・・
>>202 RAIDはファイルシステムじゃないですから!
>>191 もうちょっと勉強したらどうだ?
もしファイルシステムの定義が知りたければ、カーネルソースの Documentation/filesystems/ 以下のファイルを読むべきだろう。
206 :
名人 :05/01/12 00:39:19 ID:6jYBAkfv
du -s かけてほっとけ
/homeのパーティションをnewfsしたら0%になる。
>>203 RAIDじゃないとしたら、何?
ソフトウェアRAIDのデバイスは、通常/dev/md?で表されます。
とLPI認定試験で出てたけど。
210 :
191 :05/01/12 11:42:01 ID:6jYBAkfv
知らないなら、黙っててもらいたいのですが。
( ゚д゚)ポカーン
釣り堀はここでつか?
>>210 そちらさまこそ知らないなら黙ってて下さいな^^
すれ違いな上、板違い。知能障害に付いての相談なら人生相談板にGo。
206と210のIDが同じに見えるのは漏れだけ?
自殺自炎乙
216 :
名人 :05/01/13 18:11:01 ID:vkUopJFs
おれは携帯からiMonaで書いたぞ。 初期設定のサーバ使ってる。
よかったね
220 :
login:Penguin :05/01/18 18:08:32 ID:/zkhOD9T
userspaceのfsかぁ
filesystemじゃあなくて、block deviceをuser spaceに持ってくる 方法ってあったっけ?
raw device 問題はcachingの方。
>>225 この結果からすると、ext3は突出した性能はないけれど不可も少ない、
ということですかね。
ま、ジャーナリングの性能だの信頼性だのは個々の環境で判断すべきで、
他人のテストの結果なんて役に立たないのだけど。
>>225 漏れは去年の今頃の2.4カーネルでJFSに嵌まってた。
穴は塞がってなかったのかな。
今は全部XFSにしたのでどうでもいいけど。
JFS人気無いね
期待だけはしてるよ reiser4は心元ないし xfsはイヤンだから
>>226 でも人によってジャーナリングの信頼性が揺らぐようじゃ
ファイルシステムとしてどうかと思うぞ?
2.4.18の頃だったか、JFSのパーティションを自動 タイプ認識でマウントしたら、reiserfs だと認識されてしまって、巻戻しが始まって エライ目にあったな。 おれが操作したんじゃないし、おれのデータでも なかったから、まぁ他人事だったんだが。
ええ〜そんなことがあるのか。 こわ、ちゃんとファイルシステムを指定しようっと。
>>230 昔から根拠を示せないアンチXFSが生息。
235 :
login:Penguin :05/01/23 14:32:18 ID:VwEAlVbB
俺がXFSを使わなかったのは、カーネルの再コンパイルが面倒くさかったから。 今使ってないのは、惰性。 ほとんどの奴はそうじゃない?
>>235 XFS使ってるが、kernelにマージされる前は一生懸命手パッチあててkernel作ってたな。
今ではそんなことないけどね。
>>235 漏れはPBRに入れたブートローダを壊されるらしいので使ってない。
まあTB級のHDD使ってる訳でもないし、GB級のファイルを扱う訳でもないし。
それにエラーセクタの回避できないから。
このマシンの寿命がくるまでにReiser4あたりが安定してくれりゃ万々歳、ってとこ。
>PBRに入れたブートローダを壊される その考えは逆だよ
>>238 ん?まさかPBRにブートローダ入れるとXFSの方が壊れるとか?
PBRw
>>237 その情報元がソフトウェアRAIDパーティションのPBRと間違えてるんじゃ、
>>241 http://oss.sgi.com/projects/xfs/faq.html >Q: Does LILO work with XFS?
>This depends on where you install LILO.
>Yes, for MBR (Master Boot Record) installations.
>No, for root partition installations because the XFS superblock is written at block zero, where LILO would be installed. This is to maintain compatibility with the IRIX on-disk format, and will not be changed.
XFSはPBRも使ってるからインストールしちゃ駄目よ
IRIXとの互換性を維持したいから仕様が変更される事はないよ(超意訳)
って事じゃないの?。
LILO捨ててGRUB使えばいいって話じゃないの?
キミは実に莫迦だな
>>243 >>157 で既出だがXFSの欠陥のようだ。
XFSの partition には boot loader を入れてはいけない。
>> 234 TBのパーティションを作ってるので、XFS使ってます。 他のFlieSystemはあまり実績が無い。(reiserfs, jfs) マウントに時間がかかるExt2, Ext3 は論外。 って以前書いたんだけど、スルーされたのか。
>>242 ,245
XFSにそんな特徴があったとは知らなかった。
俺にとって、RAIDとはソフトウェアRAIDなんで、
XFSには極めて大きな欠陥があるのも同然だ。
>>242 ソースの変更は絶対に簡単な筈だから、PBR使用しないように変更すれば
いいのに、
248 :
login:Penguin :05/01/25 22:11:50 ID:ynS0n8C4
Persistent Superblock はパーティションの一番後ろだぞ
249 :
login:Penguin :05/01/25 22:18:18 ID:lnsaimvP
>>248 >>246 は非常に誤解を招く書き込みだった。
一応、俺もソフトウェアRAID(ミラー)の
パーティションからbootしてます。
でも、ソフトウェアRAIDパーティションでPBRの破壊を何度か
経験してるんで...
SATA導入記念に/をReiser4にしてみた。 WARNING: Keys are inconsistent. Fsck? 二日目で起動中にエラー、ログイン出来ず。orz 2.6.11-rc1-mm1 debian reiser4progs 1.0.3-2
なんで2.6.11-rc1-mm1なんか使ってるの?
Fuck? に見えた 欝だ死のう
スレ違いだが、
>>253 BE付いてるけど、クライアント何使ってるの?
今のところ、XFS以外の選択肢がない。
JFSはぶっ壊れた事あるし怖い。
自分がたまたま壊れたからもう使いたくない、 ってのは心情的によく分かるけど、実際分からんよな。 その壊れたfsがbrokenなのか、今まで一度も壊れたことが無いfsが安全なのかは。
>>256 まあね。
JFSは前にも出てるけど、
拡張アトリビュートに対応してないからSELinuxがつかえない。
ext2,ext3,Reiserfs,XFS,tmpfsは対応してる。
XFSがカーネルツリーに入る前はReiserfsだったけど、何回か壊れた。
ついでにJFSはgrubでも何回かはまった(stage2がロード出来ない)から、避けてる。
別に悪いとは思わないけど、あえて選ぼうとは思わない。
なぜ、基本的にカーネルを置くだけの /bootを XFSやJFSやReiserFSにして、対応しているだの 問題があるだの議論をするのか良く分からん。 カーネル(やgrub)をアップデートする時以外には マウントする必要がなく(従って壊れることもない)、 容量も極めて小さい(のが通例の)ファイルシステムを ジャーナリングしなければならないのか。
>>258 /bootを別パーティションにせず、/とswapしかパーティション分けないような人に
とっては重要。
jounalする必要は無いがext2である必要も無い。
ここはもうminixfsだな
ブートローダーの置き場所ならばファイルシステムである必要すらない。 拡張(not論理)領域の先頭だっていい。 まぁ素直にMBRに入れるのが無難さね。
MBRにgrub onlyは危険。 複数のOS入れてても、stage1_5(or 2)が置かれてるパーティションが壊れただけで全部起動できなくなる。 念のためパーティションの先頭にも入れとくべし。
>>263 grub(に限らずブートブロックで完結しないブートローダー)を使うならstage1をどこに入れようと
> stage1_5(or 2)が置かれてるパーティションが壊れただけで全部起動できなくなる。
だと思うけど…。
いざというときの保険ならブートローダー入りフロッピー(orCD)じゃないかな。
>>263-264 俺の場合、
MBRは必ずMBMを入れる。(簡単に入れ直しが出来る)
grubはraid1の両/に入れている。
その上、双方のgrub.confにはhdd1,hdd2両エントリー記述してある。(hdd0を取り外した時のために)
でも、grubインストール用CD(兼memtest、MBR補修、MBMインストール)も用意してるんで
本当は、PBRがいくら壊れても全然平気
>>257 何回か壊れたとあるけど、どのような状況で何回か壊れたのか
教えてもらえますか?
>>265 パーティションを壊したりできるようなもんをMBRには入れるのはチョット…。
>>267 どゆこと?MBMがパーティションを壊すとでも、
俺はMBM6年くらい使ってるよ。
パーティションテーブルを自由に弄れる区画エディタをすぐに呼び出せるMBMを〜 ってことじゃない? そういうことをするような人がブートローダーの画面を触れるようなPCはどれ使っても同じだと思うけどね
>>269 パスワードを設定できたりすれば、また違うと思うけど。
悪意がなくても知識もない人も触るようなPCなら。
>>266 2.4/2.5(2.6直前)で使ってた時、2.5で死んだり(Oops)すると、
2.4で自動復旧出来なかったりした。
一番つらかったのは、
壊れたのを直そうとしたら、bitmapがおかしいって事で
bitmapを作り直させたら、途中で死んでbitmapが完全に死亡。
無理矢理復旧したら(やり方はもう忘れた)ファイルは無事だけど、
名前がわからない状態になった。
しかもディレクトリ構造も殆ど残ってないから、ファイルを救い出すのに苦労した。
まあ、これはext2/3でも同じか。
マウント時に必ずジャーナル見るんで、
ジャーナル領域にbad blockが出来ると終わりな事かな。
カーネルいじってジャーナル無視させたけど。
XFSはまだbad block出来た事がないのでわからん。
今はカーネルツリーに入ってから時間経ってるし、普通に使ってれば平気じゃない?
最近設定するマシンはXFSだけど、Reiserfs使ってるマシンも問題ないし。
>>272 マウント時に必ずジャーナル見るんで
nointegrityオプション使ってもだめ?
274 :
273 :05/01/30 19:28:06 ID:CmxE5Kfe
ごめんJFSと勘違いしてた。
一応xfsにもnorecoveryってあるよ
>>184 みたいに、戻り値をチェックする/しないってのは、
結局動作させてみて、問題が発生するかどうかを見るしかないの?
全ての戻り値をチェックしてたら、処理の手間が増えるだけで、
いいことはないわけじゃん。
>>276 コミットという処理がどういう処理なのかお勉強して出直すこと
278 :
login:Penguin :05/01/31 06:40:29 ID:7QRpdfY9
>>276 チェックしないほうが怖いと思う。
まぁいちいち戻り値をチェックするのを書くのは面倒ってなら、
アプリケーションレベルのコーディングでは例外処理を使うんだろうけどね。
カーネルレベルでそんなの使いたくないし。
279 :
login:Penguin :05/02/01 06:11:37 ID:xSuJvqnb
NFSv4とCIFSってどっちがいいの?
CIFSは仕様が公開されてない。
またまたご冗談を
276=281=しったか包茎
漏れ=ニート方形
286 :
login:Penguin :05/02/01 11:59:52 ID:u/QRSk2C
>>287 これは各社集まってリバースエンジニアリングしてつくった仕様じゃないの?
それともInformationalになる予定のRFCに結局全部載って、同じものなの?
Microsoftは昔から一部だけ公開して「うちはオープン」って言うのが得意だけど、
CIFSがそうでなくなったなら好ましいことです。
Griswold & GoodmanってMicrosoftの人がco-authorだね。
291 :
login:Penguin :05/02/02 04:36:23 ID:Y+X8mfbe
なんだってー(AA略
タコな質問ですが、ディストリごとにお奨めってあると思うけど 代表的な物は素で選択可能なのかな? ここしばらく新規で入れてなかったのでext3以降の情報がさっぱりなのです…。
294 :
login:Penguin :05/02/05 11:12:14 ID:Z8jTBRe6
Debian 厨の俺が宣伝する。 Debian はいろいろ選べる。 Debian 厨の俺が宣伝した。
295 :
login:Penguin :05/02/05 11:14:32 ID:ofAzD/Js
Reiser4使いたくて仕方ないんだが、 わかりやすい説明がみつからなくてなんか面独裁
297 :
login:Penguin :05/02/05 17:51:25 ID:ofAzD/Js
>>296 設定方法がわからなくて使えません!
ひろしです。。。
>>293 おっすおっす色々試してみます。おっすおっす
300 :
login:Penguin :05/02/06 03:01:36 ID:Yim9h9+T
301 :
login:Penguin :05/02/07 12:12:52 ID:cIn9jMyq
303 :
チラシの裏 :05/02/20 23:30:49 ID:UjG6lura
linuxじゃないがExt2fsdに入ってるumount.exe umount c: が出来ちゃってびっくりだよおい
CD-ROM File System CDFSを使ってまっさらのPCでCD−Rを起動させたいんだけど・・・ このシステムファイルってどこにあるの?
>>304 ブート可能CDを作りたいんですがどうすればいいですか?
ってこと?
CDFSってマウントするとセッションごとのISOイメージがポコッと置いてあるように見えるんじゃなかったっけ? それとまっさらのPCで起動っていうのがわからん
mkisofs
310 :
login:Penguin :05/02/25 13:16:11 ID:fL6qrGqR
すんまそん、厨房的な質問ですんません。 ATAPI-HDDの一部のボリュームを切りなおそうと思っているのですが、 同じデバイスの一部のパーティションをマウントしている状態で、同じ デバイスの別の領域に fdisk でボリュームを削除したり追加したりっ てできるものでしょうか? 現在、/dev/hdb を増設ディスクとして使っています。 hdb1 :誰かが使用中 hdb2 :誰かが使用中 hdb3 :バックアップ保存用なので、深夜バッチ処理しか利用しない。昼のうちに容量修正したい。 てな感じですが、どなたかアドバイスお願いします。
>>310 できません。fdiskで変更は出来るけど、カーネルにはリブート後に反映されます。
そういう事ををやりたければあらかじめディスクをLVMで管理しておかなければならない。
>>310 >>311 の念押しだけど、
深夜バッチの前にリブートとフォーマットが出来ればOKということだよ
>>311 さん、312 さん
了解です。サンクスです。助かりました!
利用者にメイルして、今夜サービスを止めて fdisk してリブート、フォーマット、再マウントします。
>>314 補足サンクスです。ディスクのスライスはいまできるけれど、反映にはリブートが必要ということですね。
先に必要ないボリュームを削除して領域設定しておきます。ありがとうございます。
MIB! MIB! MIB! MIB!
小人が管理してるの?
Turbolinux 10 Desktopで650M程のファイルをUSBの外付けHDに書き込んで いる途中でマシンが不安定になってリセットかかりました・・・_| ̄|○ 外付けHDはFAT32でフォーマットしてありましたがファイルシステムの一部が 壊れたのかLinuxでもWindowsで見ても沢山ゴミファイルができていて しかもゴミファイルを削除すらできない状態です。 削除しようとしても「そんなファイルねぇぞゴルァ!」と怒られます。 どうしようもなくバックアップ後再フォーマットしましたがこんな場合は どう復旧してます?fsck?
>>319 FAT32ならwindowsでchkdsk/scandiskじゃない?
>>320 もう何年かWindowsでディスクチェックしてなかった(する必要がなかった)から
すっかり忘れてた・・・
漏れって馬鹿・・・_| ̄|○
バックアップメディアとしてDVD-RAMを使いたいのですが無駄領域が少ないファイルシステムを教えて下さい。 条件 100KB程のファイルを50〜60個まとめて1つのディレクトリの中に入れています。 そんなディレクトリが大量にあって、合計4G程です。 このディレクトリ構造のままバックアップする。 月に2回位の頻度で1ディレクトリの中味を更新する可能性があります。 パーミッションは不用です。
アチャー、正直に「エロ画像のバックアップ」と言えば回答があったかもしれないのに。
うpしてくれたら回答するのに。
エロ画像ってバックアップしたら 二度と見ないような気がする。
>>325 そうそう。HDDと運命を共にするデータってのもあっていい。
327 :
login:Penguin :05/03/06 17:40:30 ID:3BV4HdMy
1995年のタイムスタンプのエロ画像今でもあるよ。 Mosaicでplayboyのサイトから落としてきたやつ。 昔はこんなのオカズにしていたのかと思うと感慨深い。 今では炉利画像でないと駄目なんだよな……
漏れのオカズ置き場ファイルシステムは ext2→ext3→XFSだな。 やっぱり動画が多くなるとXFSは有利。 さーて関西援交で抜くか。
FAT32だろ。
まあFDDなら。
FDはFAT12
332 :
login:Penguin :05/03/09 03:59:04 ID:kZyLlzVN
ところでおまいらreiserfs4は使ってますか。明日外付けのファイヤワイヤ ハードディスクの250GB を買いに行くんだがこれをreiserfs4で使ってみる つもりだ。age
勇者だな。
貴重なエロ画像が……
勇者たちに質問です。 このたびLinuxでファイル倉庫を作ろうと思ってます。 いままでファイルシステムに無頓着だったんですが、ext3よりもreiserfsとかXFSというファイルシステム の方が良さそうに思いました。HDDを4台でソフトウェアレイド5にしようと思ってます。 動画とか溜めるのにやはりファイルシステムは速度等考慮して、ext3以外のものを選択した方が、 後々違いが出てくる(有利になる)ものでしょうか? 一回倉庫を作ってしまうと、あとで変更するのが難しそうなので勇者たちにアドバイスをいただけたらと 思っています。m(_ _)m
Reiser4使ってるよ。もう7ヶ月くらい。 1.5TB RAIDアレイからLVM2でいろいろ切り出して運用してる。問題があったのは ボリュームサイズ拡張してもファイルシステムのリサイズがうまくできなかったこと くらいかな。でもLVMなんで空きをかき集めてそこにファイルシステム作ってデータ 移してから元の領域を解放して、みたいにして対処してる。 Reiser4の速度を知ってしまうと他のにはもう戻る気になれない。statの応答速度が モロに効いてくるプログラムがぶん回ってるんで。
inodeサイズを2KBまで大きくしたXFS ほんのりお勧め
そんなにファイルシステムで違うものですか。参考になりました。 いろいろと調べていると、Reiserfsが情報が多いようなので、ファイルシステムはそれで 作ってみようと思います。ありがとうございました。 ちなみにReiser4は、カーネル2.6以上のディストリしか対応してないですよね? SUSEのFTP版があるようなので、そちらで試してみたいと思います。どうもです。
>>338 XFSももう少し調べてみます。どうもです。
341 :
337 :05/03/09 22:33:01 ID:SLjEunOr
>> 336=ID:w5/mqsWn すまん。漏れは337の内容は332,333へのレスのつもりで書いた。 一つのディレクトリあたり数千個のファイルが転がってるような環境でReiser4は 圧倒的な優位性を発揮してくれている。これが数十個程度のファイルしかなくて、 ファイル一個あたりのサイズが数ギガなんて環境でも同様にReiser4が優位かどうかは ベンチ取ったわけでもないので何とも言えない。 Hans Reiserがそんなタコな仕事をするとも思えないけど実際に使用・評価して 目的にあったものを選ぶのはユーザの責任なんで、そこんとこよろしく。
342 :
337 :05/03/09 22:36:03 ID:SLjEunOr
参考までに。Gentoo Linuxでmmなカーネルソースね。Reiser4で運用してるの。
丁寧にどうも。勘違いしました。 仕事で使うわけでもないので、何かあった時は、少し涙を流せばいいだけです。 消えて困るものは、バックアップは取っておきます。 おっしゃってることもわかってますので、違うファイルシステムも試してみたいという興味の上で、 実験をかねてやってみたいと思います。
おれが yamada-fs 作ったら使う?
名前が reiserfs よりかっこいい。
Hans ReiserはちょっとDQNなのがなあ。
×ちょっと ○かなり もっとも、Theoだのdjbだの上には上がいるけどね…
349 :
login:Penguin :05/03/10 13:02:48 ID:TkVSk90+
rms はどうよ
誰か知ってたら教えて下さい。 hostAとhostBの両方に/pubという同一名のディレクトリを作り、それをお互いにNFS等で マウントさせて、片方のhostに書き込まれたファイルは、もう片方のhostにも書き込まれる ようにする事は可能なのでしょうか? ちなみに、NFSで試してみたところ、同一名のディレクトリにお互いにマウントさせる事が 出来ず、どちらか一方のみしかマウント出来ませんでした。 出来れば、フリーのソフトでそういった事が出来ると良いのですが・・・。 よろしくお願いします。
LesserFS
>>350 基本的な考え違いを起こしてるような気がします。
例えばsambaだとお互いからマウントできます。
しかし、たとえそのような状態でも
一度の書き込みで”両マシンそれぞれに直接接続されている物理ディスク”に同時に
書き込むことは出来ませんよ
そちらがやりたいことはネットワークを介したミラーリングであるような気がしますが、
両方でマウントしあってもそのようなことは実現できません。
>>352 補足です
NFSでもお互いからマウントできますよ
但しNFSはsambaと比べると多少制限がきついです。
例えばhostAの/usr/と/usr/localがexportされているとします。
これをhostB側でそれぞれ/usrと/usr/localにマウントすることはできません。(例が良くないですが)
(実装によって制限つきで可能な場合もありますが、一応これは出来ないとされていることです。)
でもとにかく一つのマウントポイントで読み書きできるのは一つのファイルシステムだけですから(当たり前
ですが)、マウントし合うことによって同時に二つのディスク(場所を隔てていてもいなくても)に書き込む
ことはできません。
もし実現できればディザスタリカバリに最適な手法ということになりますが
ネットワークを介したミラーリングってのは今のところ難しいです。
普通はLVMを導入して稼働中のバックアップを定期的にとることでそれに準じた効果を得ます。
hostBのバックアップを常にhostAにとっておきたいというのであればhostBをNFS-ROOT式にすれば良いと思います。
あるいはバックアップしたいpathだけをNFSにしてもいいと思います。
350はDBのレプリケーションみたいなことをやりたいわけか?
355 :
login:Penguin :05/03/10 20:34:26 ID:bTgb51pQ
fdiskのソースコードってどっかにあります?
>>349 rmsの場合思想が過激だけど、DQNかというとちょっと違う気がする。
んまぁ、似たようなもんだといえばそうだけど。
rpm -qf `which fdisk`
359 :
355 :05/03/10 21:31:13 ID:bTgb51pQ
ありがと
今は2.4系のカーネルでreiserfs使ってる。十分早いし満足してるけど reiserfs4の噂を聞くと早くそっちに移行したい。2.6の-mm をmakeして みたけどエラーがかなり出た。漏れのはvine2.1が元になってるシステム なんでアップグレードしなくちゃいかんものが多過ぎ。2.4系で使えるように なんねえかなあ。
両方からは無理だよな
クロスマウントすると管理面倒になるからやらない。最近の若いもんは普通にやるもんかね。
>>350 自身からは一切レスがないようだな
だから
>>350 がどれくらいわかって書いたのかが全然わからん
クロスマウントすると、シャットダウンとか面倒だね。 /pubをAで作ってエクスポートして、 Bがそれをマウントするのじゃだめなの? いまいちわからんな。 もしくは、AかBに適当にディレクトリ作って、 両方が/pubにマウント。
大きいファイルはxfsがいいとかよいとか
不用意にfsckして破損したファイルシステムを ls -all ./ したら、ディレクトリなのに ?--------- ? ? ? ? ? .thunderbird になってるディレクトリ以下(にあるInboxだけでも可)を救出する方法ってありますか?
アイドル時にHDDをスピンダウンさせてくれるファイルシステム探してます。 今JFS使ってるのですが、経験とソース斜め読みした感じですと、 ある程度(結構少ない)dirtyなデータが貯まると必ずHDDに書きに行くようで、 ntpdやらの書き込みだけでも結構な頻度でHDDが起きてしまいます。 ext3やらXFSやらはどうですか?
dirtyなデータをできるだけ早くストレージに書き出そうとするのは まともなファイルシステムなら当たり前だと思うが。 頻繁に生じる書き込みをram diskに移す方が本質的な解決だと思う。
咥えて言えばHDDのスピンアップ/ダウンはHDDの健康にいいの?悪いの?
ってのはHARD系の板でよく議論になっとるね。宗教論争だが。
まあ
>>369 がやりたいってのなら、止める理由はない。
>>369 noflushd がありますよ。
バッファが満杯になるまでアクセスを控えます。
ディスクをスピンダウンさせる働きもあり。
他に bdflush でも調整可能ですよ。
書き込み間隔をとても長くすることで
近い効果を発揮します。
( むしろ信頼性の観点から標準より短めに
するのが推奨されているけど。)
以上の様な方法でギリギリまで HDD を起こさずに
済みますが、停電したときのダメージが大きいので注意。
( もし UPS があるんなら余り心配ないけど。 )
早く reiser4 が標準カーネルに取り込まれないかな・・・。 MM パッチは自分の所では動作しないので、 reiser4 パッチを当ててる。 / を reiser4 にするには結構な手間がかかるので インストーラが reiser4 に対応して欲しい所。
漏れの所は、こんな感じ。 AGE=60000 DIRTY_RATIO=40 DIRTY_BACKGROUND_RATIO=5 echo 5 > /proc/sys/vm/laptop_mode echo $AGE > /proc/sys/fs/xfs/age_buffer_centisecs echo $AGE > /proc/sys/fs/xfs/xfssyncd_centisecs echo 3000 > /proc/sys/fs/xfs/xfsbufd_centisecs echo $AGE > /proc/sys/vm/dirty_writeback_centisecs echo $AGE > /proc/sys/vm/dirty_expire_centisecs echo $DIRTY_RATIO > /proc/sys/vm/dirty_ratio echo $DIRTY_BACKGROUND_RATIO > /proc/sys/vm/dirty_background_ratio
ノートパソコンだと回転止まって欲しいときあるね。
>>373 今日/をreiser4にして入れたけど、
/boot切っちゃった。
grubが対応してれば、/一発でも行けるかな。
>>376 ftp://ftp.namesys.com/pub/reiser4progs/grub/LATEST_PATCH
人柱報告よろしくー。
378 :
376 :2005/03/25(金) 16:55:16 ID:tpH3AC8j
>>377 最新patchじゃないけど試してみた。
kernelが2.6.10+reiser4-for-2.6.10-2、
grubがgrub-0.95-reiser4-20041021+手修正、
パーティションはswapと/(reiser4)のみ。
インストールして、grub入れるまではうまくいったけど、
起動時にstage2に行くところで探せない模様でresetがループする。
http://www.namesys.com/install_v4.html この問題かな。
自分もGentooだけどreiser4早いねえ。 早く本流に入らないかなあ。
380 :
login:Penguin :2005/03/31(木) 08:43:13 ID:2Fl3pWqz
今 reiser3 使ってるんだけど、ext2 -> ext3 みたいな感じで アップグレードできるの?reiser4に。 まぁダンプ→リストアすればいいんだが、面倒だ
>>380 reiserってダンプ/リストアできるの?
単にアーカイバを使う以外に方法がなかったような気がする。
そんなファイルシステムは嫌だ。
俺用メモ
http://www.jp.redhat.com/magazine/NO1/ XFSには、XATTRに関して1つ大きな問題があります。XATTRがiノードに収まらない場合は、1つのデータブロックごとに1つのiノードという形でデータブロックに格納されるのです。
mkfs.xfs のデフォルトの設定は、ブロックサイズが4096バイト、iノードのサイズが256バイトになっています(SELinuxのXATTRを格納するには、iノードが30バイトほど小さすぎます)。
つまり、デフォルトのXFSファイルシステムでは、SELinux のXATTRが1つのiノードにつき4096バイトを占めることになり、多くの場合これはディスク空間のかなりの部分に相当してしまいます!
XFSファイルシステムの作成時に“-i size=512”というオプションを使用すると、iノードのサイズが512バイトになり、SELinuxのXATTRがiノードに収まるようになります(スペースと性能の面で大きなメリットが得られます)。
また、512バイトのiノードにすると、明らかにその他の操作も少し性能が向上します。
XFSを使用する場合、もし将来SELinuxを使う予定があるなら、512バイトのiノードを使ってすべてのファイルシステムを作成しておくと良いでしょう。
2.6.12-rc1-mm4 - New resierfs4 code drop
Ext2Fsd 0.24 is released!
XFSにそんな罠があったのか。容量は余りまくってるから良いけど、 パフォーマンスが落ちるのはやだな。
387 :
login:Penguin :2005/04/14(木) 14:41:33 ID:cevmRAGN
「ファイルシステム」って日本語だとどう言うの?
算帳系
>>386 心配しなくてもSELinuxは面倒くさくて切って使うことが多いよ
FUSE使って2chfsとかできるのかな? base64で書き込み。あ、削除ができねーか。
追記型ならできるかも。 でも書き込みは1000回まで。
ReiserFSについて質問です。 400GBのSATAディスク7つRAIDコントローラボードに接続して1つのドライブ(2.18TB)をつくり、 シングルパーティションでReiserFS (3.6)のファイルシステムを作りました。 そのまま使っている分には問題なかったのですが、ある日rebootしたら2Tのディスク容量が 200GB弱になっており、FSもぶっ壊れてました。reiserfsckしたらとりあえず データ(<200GB)は救済できたのですが、容量の1割しか使えないんでは困ります。 これって仕様なんでしょうか? システムは最近インストールしたばかりのGentooです。 よろしくお願いします。
394 :
login:Penguin :2005/04/28(木) 16:22:45 ID:BMKzQJCS
age他方がいいのでしょうか・・
アーキテクチャが何だかわからないが ix86のような32bit Linuxは2Tまでしか扱えないと思ったが。
sfdisk -V すると驚愕の結果に! なったりして
** おおっと、便座の中 **
5.1TBのreiserfsのボリュームがあるよぉ。 リブート恐いよぉ。
すでに、どこかぐちゃぐちゃかもな。
400万個のぬるぽに満ち溢れて
人柱だという自覚が足りん 実運用に入る前にちゃんと検証すれ
403 :
login:Penguin :2005/05/07(土) 00:18:05 ID:RGubdeds
ReiserFSを試してみようと思い、調べていたのですが、
>>71 を見てちょっと
困りました(>_<)
ext3よりも、障害耐性は弱いのでしょうか?
電源ぶち切れなんて年に1度あるかないかぐらいの確率だと思うのですが、
やっぱり気になります。
どうなのでしょうか?
404 :
login:Penguin :2005/05/07(土) 00:20:46 ID:RGubdeds
ちなみにOSはCentOS3(kernel-2.4)です。
>>403 漏れは
>>71 のようなことになったことはない。
ハードウェア的に問題があったか、さもなくばよほど運が悪かったのだろう。
仮にそのような事態を想定するとしても、それはファイルシステムに対してではなく、
重要なファイルを定期的にバックアップする心がけに注意を払うべきではないのか。
いくらジャーナリングファイルシステムだからといっても、
それは単にファイルシステムとしての整合性が保たれるってだけのことで、
アプリが書き込んだつもりの情報が失われることから守られるわけではないのだから。
# 書き込む直前にメモリにキャッシュされていた内容は反映されないから
運が悪いとファイルシステムの整合性が失われるジャーナルファルシステムなんて ありえないんだが。
運悪く隕石が当たって整合性が失われるとか 運悪く宇宙人にいたずらされて整合性が失われるとか
運が悪いと=バグに遭遇すると バグの無い実装などありえないでしょ。
そしたらバグで fs が壊れる実装なんて使えねーって結論になるよ。
>>403 試してみようと思ってるなら、実際にやってみりゃいいやん。
ext3で電源ぶち切れたら運悪くジャーナルファイルがぶっ壊れて マウントできなくなったことはある。 ext2でマウントしてみたらできたけど。
412 :
login:Penguin :2005/05/07(土) 23:46:28 ID:RGubdeds
>>405-411 ありがとうございます。
>>71 のような事例はそうそう無いということですね。
知り合いにReiserFSを使っている人が一人もいないので、参考になりました。助かります。
とりあえず試してみようと思います。
reiserfsってパーティションのdumpって取れないの?
アンビリーバボー
reiserfsのdumpツールがないのは痛いね。 しかたがないんでpartimageで代用してる。 partimageはマウント中のパーティションはバックアップできないんで KNOPPIXからpartimageでイメージ作ってる。 スナップショットを使えばオンラインでバックアップできるかもしれないけど やってみたことないんでわかんない。
reiserfsは、dumpの必要性がないファイルシステム(・`ω´・)
reiserfsのFAQが正しいとするとext2でもdumpは必要なさそうだけど 実際のとこどうなんだろ?
dump自体がレガシー。 HDDが数GBしかなかったころのバックアップ手法。
>>420 数十〜数百GBのHDDのバックアップ手法キボンヌ
>>422 RAID1は予防策であって、復旧には使えんだろ、バーカ
旧態依然だといわれても他にdumpより良い方法がないからなぁ。なんかいいのある?/procとか問題なくrestoreできるなら正直なんでもいいんだけど。
LVM
>>425 /procの中身を取らないという意味ならtar -l (--one-file-system)は?
tarかよ
IQ56 orz
cp -ax っつう手もあるな。dumpと比べてメリットがあるのかどうか知らんが。
てゆーか、dumpが無いって事は壊れないって事だ。
dumpfsは?
基本はスナップショットとれるfsをつかって、スナップショットをとったあと
時間をかけてお好きな方法でって感じで、特にこれといった決め手はないような。
>>433 バックアップにRAIDとかほざく馬鹿は放置しとけ。
>>422 はnbdって言ってるから、
ネットワーク越しにRAID1組んで
片方死んでももう片方から復旧させるという手法なのかな?
瞬間的には逐次的なバックアップと見なせなくもないけど、
操作間違って消したらおしまいだしな。
sync終わったら切り離すって手法じゃね?
>>431 ファイルシステムがいかに優れていて壊れなくても、人間というものはアフォで
すぐ壊すからバックアップは必要なの。
Red Hat Enterprise Linux 4のファイルシステム(ext3)上で ディレクトリをtarで固めると、順番めちゃくちゃに格納されちゃう。 Red Hat Enterprise Linux 3のファイルシステム(ext3)だと大丈夫。 何か変わった?
>>439 例えば、weekという名前のディレクトリ以下に、一定の並びでファイルが
入っていると仮定します。
$ ls -f week
. .. Sunday Monday Tuesday Wednesday Thursday Friday Saturday
H-Treeがオフの状態のext3上で
$ tar cpf week.tar weeek
を実行すると、その並びでtarファイルが作られます。
もし、H-Treeがオンの状態のext3上で同様に作りたければ、
week/Sunday
week/Monday
week/Tuesday
week/Wednesday
week/Thursday
week/Friday
week/Saturday
のように、あらかじめファイル並びを記述した「week.order」を用意しておき、
$ mv week week~
$ mkdir week
$ touch -r week~ week
$ tar cpf week.tar week
$ rmdir week
$ mv week~ week
$ tar rpf week.tar -Tweek.order
の順番で実行すればOKです。
442 :
439 :2005/05/12(木) 11:40:23 ID:o3RQajAb
>>440 >>441 いろいろ教えてくださりありがとうございます。
なるほど、H-Treeが原因のようですね。
H-Treeがオンの時、tarファイルに格納する対象としてディレクトリを
指定すると、その配下のファイルがまとめて固められてしまうので、
このような手順を踏んでいるのですね。参考にさせていただきます。
取引先に納品したtarファイルのリストが従来と違うと文句を言われて
いたので、大変助かりました。
ただ、この方法だとディレクトリの深さが1段までなら大丈夫ですが、
さらにツリーが深くなると、再帰的な処理が必要になると思われます。
ちょっと考えてみます。何か良い案があればよろしくお願いします。
tar で順番変わると何がマズいんだろ。
ただ気持ち悪いだけだろ。
ファイル展開時に関連するファイルがディスク上に並んで置かれないため、 状況によってはシーク性能に影響するということが考えられるね。
ひょっとして、cpioとか使ったことないのか?
find | sort | cpio -H tar
>>446 tarにおけるアーカイブ順と、ディスク上の物理的な書き込み位置
が関係あるの?
DQNをとりまく世界ではあらゆることが起きうるから tarにおけるアーカイブ順の如何で世界が滅亡しても不思議じゃない。
cpioだったら、たとえば、 find hogehoge | sort | cpio -H ustar -vo | gzip -9 > hogehoge.tar.gz みたいなことをやって、中間ファイルなしに ファイル名順にそろえられるとかじゃない?
sortしちゃったら、Sunday→Monday→…の順じゃなくなるからダメでしょう? 確かH-Treeがオンの状態でも、従来モードにフォールバックできるようになっ ていて、ファイルシステム上には格納順が残っているはずだから、その情報を 参照すれば良いんじゃないかな。readdir()の時はそっちを使え、みたいな。
>>453 VFSが挟まってるのにどうしろというんじゃい。
455 :
login:Penguin :2005/05/12(木) 21:20:49 ID:mj9qIsKe
>確かH-Treeがオンの状態でも、従来モードにフォールバックできるようになっ >ていて、ファイルシステム上には格納順が残っているはずだから、その情報を 詳しく
>>451 どうせ滅亡するのはDQNの脳内世界なのだから
かってに滅亡させておけ
>>453 sedなりperlなりでfilterすればいいだけでは?
月の名前だったらsortだけでもできるけど。
H-Treeオンの状態だと、H-Treeオフの状態と比べて、意図したファイル並び という情報が欠落するわけだな。これは、POSIXでは規定されていないから 直ちに欠陥とは言えないが、この性質を利用したアプリケーションは困る。
>>H-Treeオンの状態だと、H-Treeオフの状態と比べて、意図したファイル並びという情報が欠落するわけだな。 「意図したファイル並び」とはどう定義するんですか? 1秒未満の作成/変更時間を反映した順番とかですか?
>>458 > この性質を利用したアプリケーションは困る。
具体例プリーズ。
fdcloneはいったんテンポラリにファイルを移動 -> 並び替えたい順番に 移動しなおす、という動作でファイルの並びを操作しようとするな。
それは暇そうな操作でつね。
DOS使ってた方が幸せなんじゃないか?
DOSのFDがそういう操作してたからfdcloneは わざわざそれにあわせてあげてるんじゃないの? もともとDOS使ってたほうが幸せな人向けのものな希ガス
何で話がそういう方向になるのかなぁ。
じゃあ戻しを試みると、 fdcloneとかのアプリは、fsによって挙動が変わる可能性があるってこと?
DOSからの人でファイルの内部並び順ウンヌン言う人いるけど、 本来保証されていないもの。 ファイル並び順の情報を保存したければ、別の方法で保存するのが筋。 検索の高速化のために内部で並び替えちゃう fs は多いよ。
それじゃ、readdir()の実装はどう説明すれば良い? dir_indexが有効だと"."や".."を含めて並びが乱れるよ。
>>469 ディレクトリリストを見るときls -flを使わない人ですか?
先頭が"."と".."と想定しているプログラムが支障をきたします。
そんなプログラム死ねよ
>dir_indexが有効だと"."や".."を含めて並びが乱れるよ。 >先頭が"."と".."と想定しているプログラムが支障をきたします。 結局dir_index(tune2fsでのH-Treeのスイッチね)は有効にするなということでFA?
なんか馬鹿が腐れた自作プログラムの擁護するのに大変そうだね… でも、馬鹿がいくら擁護したところで、自分の馬鹿さ加減をより晒すだけだよ。 あと、暖かくなってきて恥垢臭がきつくなってきたんで、いい加減 包茎手術したら? 馬鹿は治せないけど包茎なら治せるんだし。
>>470 そういう想定をするプログラムが悪いだけでは。
そもそも先頭が"." ".."になることを仕様として保証しているファイルシステムなんて
そんなにないんじゃないか?
Error counter log: Errors Corrected by Total Correction Gigabytes Total EEC rereads/ errors algorithm processed uncorrected fast | delayed rewrites corrected invocations [10^9 bytes] errors read: 0 0 0 0 0 116.318 0 write: 0 0 0 121 121 162.833 0 verify: 0 0 0 1 1 109.298 0 Non-medium error count: 0 Error Events logging not supported smart-ctrl にてこんな感じのエラー吐いたんだけど、これってどう診断すればいいんだろう。 寿命と見るべき?
>>474 自分がくらった例としてpmakeでこういうコードがあった。
(インデントは変えちゃってる)
/*
* Skip the first two entries -- these will *always* be .
* and ..
*/
(void)readdir(d);
(void)readdir(d);
これコメントの意図通り動いてなくて悩んだYO。
ルートディレクトリならどうなるんだろ
>>479 お前素人?ルートディレクトリでも..はあるだろうが
>>477 ハードディスクは日常的に細かいエラーを起こし、
そのエラー回数を集計したものを表示しているに
過ぎず、問題があって表示しているわけでは無いから
心配するのはまだ。
数値的には、エラーはほとんど無いし、
「uncorrected error」が発生していないし、
心配はいらないと思うよ。
・121 回は無事に書き込みエラーが修正
・116Gバイト読み込み
・163Gバイト書き込み
・109Gバイト検査
Ext3でナノ秒タイムスタンプ対応ってどうなってる?
見た事のない smartctl の出力だと思ったら、SCSI なのね。 びんぼーのぼくは、ATA でつよ。
>>480 スマソ、MS-DOSのFSと混同してた
ちなみにDOSのルートには . .. 共無かった。
>>482 ext3のinodeにはdefaultではnanosecondなc/m/atimeを格納する余地がないので、
big inodeにしないといけなかったような気がする。
linux-2.6.11.10ではfs/ext3/inode.cでは
void ext3_read_inode(struct inode * inode)
{
...
inode->i_atime.tv_nsec = inode->i_ctime.tv_nsec = inode->i_mtime.tv_nsec = 0;
となっていてkernel側では知覚はできるけどfilesystemからは読み取らないようになってるね。
486 :
477 :2005/05/20(金) 01:17:52 ID:yJ30u50y
>>481 わかりやすい説明ありがとん。smartctl の導入ページはあっても、
情報の分析ページが無くてこまっていました。本当に3Qでふ。
>>483 6年前の PC で未だに Socket 7 だったり。
CPU が遅いからディスクで稼ごうとして FULL SCSI で組んだら
偉く高くついてしまった…orz
そういえばreiserfs4って頓挫したの?
した
>>487 reiser4ならあるけど、頓挫したのか?
頓挫だって? 全てのpartitionがreiser4なオレのマシンはどうしたらいいんだ!!
492 :
login:Penguin :2005/05/24(火) 21:28:52 ID:CcC3rd0B
Linux って smart に関するチェックツールは標準でついていますか? SUSEとかRedHatあたりを想定して質問しています.
smartctl 標準で付いてるかはしらね
>>492 FC3の場合、smartctlはkernel-utilsに入ってる。
標準と言ってもいいと思う。
FC-develの場合、smartmontoolsに入っている。
こちらは標準かはパッケージからは不明。
インストーラのスクリプトを読んでくれ。
>>492 SUSEだと、まんまsmartmontoolsというパッケージに入ってるな。
Novell SUSE LINX Enterprise Server 9 評価版 にlustreが入ってたので試してみました。 フルインストールでもlustreは選択されてないので、 検索→lustreで出てきたパッケージを入れてインスコ で、time ddで性能計ってみた ローカル性能、1spindle ext2とext2上に作成したスピンドルに対してのI/O read(time dd if=/fs of=/dev/null) size___ext2_____lustre __4KB__778M/s___200M/s 128KB__776M/s___580M/s __4MB__777M/s___730M/s 128MB__777M/s___735M/s write(time dd if=/dev/zero of=/fs) size___ext2_____lustre __4KB___42M/s____38M/s 128KB___42M/s____78M/s __4MB___42M/s___122M/s 128MB___41M/s___121M/s lustre。。ext2上に作成しているのにもかかわらず ext2の3倍。。。syncしてるのか?? あきらかにHD性能超えてて怖いのだが。。
Linuxのファイルシステムってなんでまともにsyncしないものが多いんだろ?
ファイルシステムってハードディスクの物理的な破損を引き起こす事が可能なの?
寿命を縮めるぐらいならできそうだけど、 焼け死ぬかねぇ。
>>498 この人は
>Linux関連のサーバを作って飯を食うようになってかれこれ6年経ちますが、
>いまだに全貌が把握できていません
とか言ってWindowsサーバを使っているということは、
windowsの全貌を把握しているということなのか。
それはものすごくとんでもなくすごいことのように思われるのだが。。。
6年も使ってるのに把握できないなんてよっぽど...
503 :
477 :2005/05/29(日) 12:32:20 ID:EBOrcVsP
>>501 こんなやつが、Linux 鯖で飯を食ってる当たりが エセエンジニアの
臭いがプンプン。だいたい fs と hd の物理的破損が関係あるわけない。
何の根拠もなく、こんなのことを平気で書くエンジニアがいるなんて
自分の無能をさらしているようなもんだろ。そういうやつがいるから
漏れに尻ぬぐいが回ってきて困るわけだが…。
誤 >Linux関連のサーバを作って飯を食うようになってかれこれ6年経ちますが、 正 >Linux関連のサーバールームを作って飯を食うようになってかれこれ6年経ちますが、
sambaが激遅なのは、認める。
自爆スイッチを押しちゃったんだよ、いろんな意味で。
>>498 ファイルシステムごとに特性があるので、
用途に合わせてファイルシステムを選ぶ
べきだと思いますよ。
ファイル数が多い用途ならxfsかな。
私は1500万ファイル作成の実績がある。
6年も何をやってたのでしょうかね。。
>>496 lustreってどういうモノ?
>>497 いつの話をしている?
- どうせマシンが落ちたらおしまいだから、と割り切っていた。
- Linusが遅いのが嫌いだから、速度稼ぐため。
というのが昔の認識だったが。
>>508 今の話。いまだにext3ですらまともにsyncしとらんのじゃないかという話すら
あるわけで。
http://www.lustre.org/ lustreは並列ファイルシステム、pvfsなども並列ファイルシステム
1台以上のPCでファイルシステムを構築する。
PC512台で1台当たり100GのHDを2個づつ持ってたら
100G×2個×512台=
100TBの大容量ファイルシステムを組める
まぁ1台構成でもいいけど。
Lustreは1.2.4が無料公開
1.4系は有料です。
SuSEに入ってるのは1.2.1でした。
>509 まともにsyncしなければならない状況って どこまでを対象(保証)するかというわけで、 lkmlで教祖様も、H.Reiserに「まぁ、頑張れや」 ってコメントを食らってたなぁ。
教祖様って何してる人なの?
要するに、どこまで保証するの?って話しになるときりがないから、 最初からsyncをしないって選択はありじゃない? ぶっちゃけunmountの時だけsyncすればいい気がする。
流石513だ そんなところに憧れるぜ
>>507 関係ないところでつっこんでわるいが、
細かい大量のファイルの処理なら ReiserFS、
大きなファイルの処理なら XFS が良いかと。
>>498 こ・・これは・・・。
こういう考えの人もいるから、
オープンソースとクローズソース論争が余計ねじれるのかな。
>>515 今ならそうかもしれない
昔ならありえない時期もあった
そもそも「仕事で使うならReiserFSは選択肢に入れない」っていう人もこのスレには多いはず
なお
>>570 は細かいとは一言も言っていない
>>517 日本国内の場合、仕事でLinux OSを使うこということは
ほとんどRed Hat Enterprise Linuxを使うということになるので、
技術的には使えてもサポートされていないReiserFSは
選択肢からは外れるね。SuSEを使うならOKだけど。
>>518 は「仕事でLinux OSを使う」イコール「ホストのお守り」という
思いこみの激しい香具師。
相変わらず要らない子なJFS
>>523 確かにねぇ...
HT-Treeでオールマイティーの ext3
小さいファイルなら reiserfs
大きいファイルなら XFS
ext3の代りにつかってみようか。でもユーザが少ないと
バグ出しも十分でないし。
うひひ H-Treeだわさ。
reiser4も、そこはかとなく要らない子風味?
>>526 前使ってたけど、人柱は足りてない気はする。
特性とかがreiserfsと近いならそのうち置き換わるんじゃね?
小さいなら reiserfs って アクセスが速いってこと? それとも容量を食わないってこと?
>>528 一応両方。
ファイル最後尾の小さな断片をまとめることで容量を節約する機構がある。
(Reiser ほどじゃないけど XFS にも節約機構有り。)
速度に関しては、ファイルの作成・削除が非常に高速なので、
結果小さいファイルを多く作るのが速い。
デフラグソフト PerfectDisk を使っていると分かるけど、
クライアント用途においては容量比で 90% 以上のファイルは一ヶ月以上
更新されない。ReiserFS はこれに着目してファイルを再配置する機構もある。
元々 Reiser 系は小さいファイルの扱いにフォーカスして設計されている。
Windows に比べて小さいファイルを作る傾向にある Linux の事情に
合わせた方針なわけだけど、結果、クライアント用途に抜群な FS となった。
JFSは使われてないねぇ。 SELinuxでつかえないから、FC/RedHat系で使われる事もないだろうし。 ReiserFSだと小さいファイルは、なんて言うか忘れたけど、 NTFSのMFTみたいに扱うから、それも高速化の一因だったはず。
いや、NTFSのMFTのようにinodeの直接収めるのはXFSの方だよ Reiserfsのpackingは違うっしょ
×inodeの ○inodeに
JFSでシステム組んでるんですけど、、、orz. でも、いまんとこクラッシュなくて(・∀・)イイ!!よ。 ext3ではひどい目にあったけど、、、
なんでこんなに大勢で弄ってるわりにはLinuxのファイルシステムって 評判悪いの?
評判悪い? そんなこときいたこともないよ
VxVMのおまけのVxFSでいいや。
OSF1のおまけのAFSでいいや。
本当かどうかはともかく、悪い評判をまいてるヤシはいるわな。ほれ、また奥山ネタだが。
ttp://slashdot.jp/journal.pl?op=display&uid=2487&id=300774 >Qu FuPing が LinusとFile System Maintainer に対し、障害時エラー出力の標準化を求めている。
>しかし、Linusは全く対応しようとしない。その態度には誠実さなどかけらも無い。
>
>背景を少し説明しよう。 Project DOUBT で、彼は 実に素晴らしいテスト を考え付いてくれた。
>対象はファイルシステム。調査内容はハードウェア障害をファイルシステムがいかに素早く
>アプリケーションに通達するか、だ。
>意図的にUPnP機能を持つデバイス上にファイルシステムを作ることで、
>デバイスドライバーまでは障害を確実に取得できるようにする。
>ファイルシステムにさまざまな形式のアクセスを行いながらUSBケーブルを引っこ抜き、
>ファイルシステムがどのタイミングで障害を報告するのかを調べると、
> * そもそもエラーとして障害を返さない。
> * エラー内容が明らかに間違っている(Storageは丸ごと存在しないのだ。
> Read Only File Systemって何事?読めるって言うのか?!)
> * 勝手にキャッシュが正しいことを仮定している
> (Cacheっていうのはオリジナルに対するデータのコピーで、
> 整合性がちゃんと制御されているものを言う。
> オリジナルへのアクセス能力を失ったら、整合性を制御できないのだ。
> デバイス障害を検出したら、速攻でキャッシュは破棄しなくてはいけない)
> * そして、ファイルシステム間でエラーがバラバラである
>
>はっきり言っていかなる用途であれ、このような信頼性の無さは許されるものではない。
>が、Linusは問題を指摘されても直そうとは考えないらしい。問題の存在自体をきっぱりと無視している。
>>539 Windowsなんかは、知識が足りないユーザーも使うから、
エラーはしっかり出すように気をつけてるんかね〜
OSごとに、ターゲットにしてる人に合わせた対応って感じなのかな。
WindowsでFAT32に4Gを超えるファイルを
途中で投稿しちまった コピーしようとしたときのエラーメッセージとか、しっかりしてないよWindowsも
WindowsのUSBデバイスの場合は、デバイスがひっこぬかれた瞬間に システム側のファイルシステムが強制アンマウントされた状態になるよね。 Unixで同じようにファイルシステム強制アンマウントってできるの? 普通はプロセスがさわってたらDevice busyとかなっちゃうけど、 あれの根本的解決ないのかな。 linux-2.4.30でUSB HDDひっこぬいて(device busyがない状態で) 存在しなくなったブロックデバイスをumountしようとすると reiserfsなんかはfs driver内でSEGV起きてたりした気がする。
昔 USB フロッピードライブを USB 端子にさしたとき、 ディスクが入ってないせいで kernel がとまったことがあった。
これ言っちゃおしまいかもしれないけど、 Linuxは昔も今もこれからも、そういうモノでないかなあ。 それが嫌ならBSDなりSolarisなりWindowsなりを使えばいいわけで。 それを知らずにLinusの信者になる方が悪いっていうか…
Linus「patch書けば?」
でも、気に入らないって言われて、書いたパッチはキックされちゃうんでしょw
>>539 Qu FupingがLKMLで相談したのがこのスレ
ttp://lkml.org/lkml/2005/5/16/9 教祖様が参戦したスレは
「USBはホットプラグデバイスなんだから再接続した時にスムーズに再マウントできないとダメだろ」
とかめちゃめちゃな流れになっててワロス
長文のわりに議論が下手糞だなあ
ところでFreeBSDのFireWireディスクは切断-再接続した時再マウントなしに使えるんじゃなかったっけ
そこで fork ですよ。
∩___∩ | | ノ\ ヽ | / ●゛ ● | | | ∪ ( _●_) ミ | 彡、 |∪| | --+∈ / ∩ノ ⊃ ヽ ( \ / _ノ | | .\ “ /__| | \ /___ /
そりゃ食えん
Linus「文句言う or 日記書く or 2chに書きこみする 暇があったら、*素晴らしい* patch 書け。以上、議論終了。」
あくまで、fsに関してのセンスが最悪なLinus的に素晴らしいパッチだけどな。
reiserはサイズの小さいファイルに適していると聞くけど、具体的にどれくらいのサイズまで適してるの?
>>553 素晴らしくないから拒否される。
本当に最悪と思うなら、
>>553 の言う最高にセンスのある fs に書き直してみせろよ。
reiserfsはpageサイズ以内であれば速いですね。 i386なら4Kbyte以内、x86_64とia64であれば16Kbyte以内 reiserfs_file_write や reiserfs_writepage ->reiserfs_write_full_page のソースを追っていけばわかるが、書き込み領域が 1ページの場合だけ、特殊な動作でwrite処理を実現している。 特殊な動作ってのは説明しづらいが。。 小さいファイルをページに詰める処理があって、seekの負担を 減らしたりして、ディスク効率良&速度を稼ぐ 複数ページのwriteは他のファイルシステム同様writeキューに 入れて非同期I/Oにつないで、pdflushのタイミングでwriteし 外見えの速度を稼ぐようにしている。 getmeta系はリスト構造が木構造で速い。。 としか、簡単に言えないな。。 reiserfsで1冊本書いても売れないだろうな。。。
>>558 詳解ファイルシステム とか出して
買うよ
>>558 洩れも買うぞ。
reiser4もよろ。
解説書の陳腐化速度予想 低速 高速 <---------------------------> UFS JFS XFS EXT2 EXT3 ReiserFS(測定不能)
工夫はいろいろされていると思うが、小細工がかえってパフォーマンスを悪化させることもあって、 実際にどのサイズでどの程度速いかは測らないとわからないかもしれず。
reiserfs4の内部構造の解説はどこかにwikiがあったよ
>>563 そのレスの中で一番ウケたのは
Andi> Didnt review more.
だなwwwwwwwww
ReiserFS のパッキングは確かに速度低下の原因になっているよ。
だから Reiser4 では改良の対象になっている。
ただ、他の工夫で速度をあげているけど。
>>532 にあるような、NTFS XFS の方法は
効果は極端に小さいファイルに限定される。
(NTFS の場合、約 700バイト以下)
ReiserFS の場合、中途半端に小さいファイルでも効果あり。
Reiser4 がなかなか登場しないからいっそのこと
ReiserFS (v3) で / を作る手を打つべきだろうか。
速度にこだわらないなら ext2 も意外に堅牢だと言うし迷うな。
>>566 Reiser4が登場しないってどゆこと?
reiserfs って 3 のときもひと悶着あったね。
570 :
login:Penguin :2005/06/08(水) 04:26:20 ID:IZ76wtzA
mmには入ってるんだっけ? > Reiser4
Reiserって今や出来の悪いレガシー扱いされてるからなぁ・・・
>>570 はいっとる>2.6.12-rc6-mm1
homeみてみたら、5M〜15Mあたりのファイルが多かったんだがReiser使うにはでかすぎるかな 普通にext3使っとくか…
そこでxfsですよ
Reiser4だね。
xfsって5〜15Mあたりの大きさに適してるんですか? 大きいサイズって言うから少なくとも100M超かと勝手に思ってた。 数Bytes〜4kBytes なら Reiserfs 5M〜 なら xfs って認識でOK?
xfsは細かいファイルだってかまわないで食っちまうファイルシステムなんだぜ
>>577 XFSってファイル消去がすげー遅かった記憶があるんだけど直ってる?
昔2.4カーネルにマージされる前に
# rm -rf /usr/src/linux
してえらく待たされた。
>>578 試してみたらHDD突然死した_| ̄|○
過労でつか?
そもそも「そこで○○ですよ」とか言ってる香具師に反応した時点で釣られてることに気付け。 昔のXFSにくらべたら今のXFSは 「サイズは小さいが大量のファイルの生成/消去くりかえし」 の速度がかなり改善されてるが、 ReiserFSがダンチに速い状況はかわらず。 しかしXFSがメタクソに遅かったのって2.4.0-testXXXとかその頃じゃねーの? 今の2.4.31とか別に死ぬほど遅いとは思わんがな。
らいざーって読むんだね レーザーって読んでた
Linux界隈の人間は用途ごとに別のFile Systemを使おうとする件について
適材適所
適材適所っていうほど違うわけでもない。 ってことで、信頼性はおしなべて低い(w
それがLinuxクオリティ
OS自体を楽しむためのOSだから、それでいいんじゃない?
全部ext3(ext2)なんて耐えられない。
適材適所なのは分かるが、具体的にどんなときに適してるかまとめてある資料ってない?
reiserが小さいファイル、xfsが大きいファイルに適してるってのは知ってるんだが、
>>576 が言うみたいな具体的なサイズまでは知らない。
どれくらいの大きさなら、ext3と同程度かそれ以上の性能が出せるのかが知りたいんだが。
速度しか見ようとしないから厨と言われるのだ
>>589 なんだかんだ言って、どのファイルシステムも
大きいファイルから小さいファイルまで考えて作ってある。
確かに、ファイルシステム自体の評価は余り見かけないね。
「 ext は断片化に強いからデフラグは不要 」 と
信じて疑わない人が大多数であるし。
結果は
>>529 の一番下の資料を見る限り Windows と同様、
断片化の影響を大きく受けている。
疑わないことで Windows に遅れを取ったことになる。
サーバーマシンではデフラグの効果が余り無いのも事実だけど。
ext2のデフラグツールって90年代前半には既にあっただろ Unixの「デフラグツールはありえない」っていう思い込みを 無批判にLinuxに適用していたアフォ評論家が多かっただけ
・fsckが早い ・使用環境のファイルサイズが大きいものが多い環境(1GB以上のファイル) ・そのファイルサイズが大きいファイルの削除が早い ・ランダムアクセスはほとんど発生しない ・MDデバイスやLVM上でもファイルシステムを構築できる ・ファイルシステムの拡張ができる(できれば縮小もできるとうれしいけど、その点は妥協) といった感じで現在SuSE Linux 8.2 (Kernel 2.4系)で XFSメインで使用しているのですが 最近(Kernel2.6環境)でも上記条件ではXFSにしておくのが無難ですかねぇ? ログ見るとReiserFSがかなりよくなってるようですが・・・
>>593 >>・fsckが早い
XFSのfsckのソースのmain()の中身って
return 0;
だけじゃなかったっけ? 今は違ってる?
int main(int argc, char **argv) { return 0; } 先生!変わってませんでした!
> int > main(int argc, char **argv) > { > return 0; > } Hello World よりも酷いね・・ 早くLinuxででもUFS2を不自由なく使えるようになって欲しい。 UFS2は素晴しい。
しかし、reiserfs や ntfs とメジャーなものばっかりですなぁ。話題は。 漏れとしてはそれよか、他のシステムで使われているファイルシステムが気になるのだが...hfsとかhpfsとか まぁそっち側の趣味を持っている奴がいるのかいないのかぐらい確かめさせてくれ
>>596 Linuxのことだから、一から再実装してext2と大してと変わらんシロモノになるぞ(w
filesystemについて理解していないのならわざわざバカなこと書いて 無能を晒さなくてもいいのに。
600=真性包茎
真性包茎 = UFS 仮性包茎 = UFS + Softupdate ズルムケ = XFS, Reiserfs
上の方がすぐれてるんだよな?
そもそもXFSのfsckに何をさせようというのだろう。
>>593 が言ってるfsckってjournal replayのことだろ…
>>605 要約すると
「ぼくは情報処理のべんきょうをしたことがありません」
「ぼくは悪くありません」
てことですね。
まあ、普通に考えてDBでやるだろうな
>>609 んだな。
ところで今のサーバのメモリが2Gくらいって感覚はどうなの。
何のサーバかにもよるけど、最近なら8G位普通じゃない?
>>610 鯖でなくてもデスクトップなら普通2Gくらい載せてるだろ。
4GoverだとM/BのスロットとOSが64bit対応してるのがmustだな。
>>605 のリンク先の言い訳を見てると首がもげるぐらい傾くな。
8ビット機の昔から、ゲームで大量に使わなきゃいけないデータは単純に結合した1つのファイル
にでもしておく手法が主流だったんじゃないか?
msec単位の処理時間を気にするなら、openよりseekの方が速いだろうに。
>>612 確かに。違う画像とって来るにもopen-read-closeよりseek-readの方が速い
>>611 デスクトップでは、まだ1Gでしょ。
熱心な人が2〜4Gにするくらいで。
ゲームする人は、結構2G多いかな。
VMWare でいっぱいつんでる
よし、物は試しだ。やってみようぜ。 安全のためUSB接続のHDDになると思うけどどのぐらい時間かかるんだろう・・・ガクガクブルブル
男は度胸 なんでもやってみるのさ
カネあったらVxFS試したいね
>> レスポンスタイム(16.6ミリ秒) ext2上に4Kのファイルを一つのディレクトリに30万個置いてみました。 ※(creat + write) 1ファイル当たり 8.90759 ms $ time for (x=0;x<300000;x++) do cp test.gif /test/$x; done real 44m32.277s user 2m15.260s sys 42m20.050s ※getmeta 1ファイル当たり 0.006 ms $ time ls /test | wc 300000 300000 1988897 real 0m1.822s user 0m1.720s sys 0m0.180s ※(open + read) 1ファイル当たり 1.14239 ms $ time for (x=0;x<300000;x++) do cat /test/$x > /dev/null ; done real 5m42.717s user 1m48.020s sys 3m19.930s open + read (/dev/nullへのwrite)で、1ファイル当たり1ミリ秒なんだが。。 ちなみにinode不足になるENOSPEのエラーが返ってくるまで 試しましたが、問題ありませんでした。(約160万個) iアプリがどうのこうの言ってたので、4年前かな?以下の構成で行いました OS : Red Hat Linux 7.3( kernel 2.4.18 ) CPU : Pentium3 600MHz Memory : 128M disk : Deskstar 75GXP DTLA-307030 30.0G I/Oサイズ : 4096 byte(※iアプリ用だからこのくらいで十分?) #改行多いと怒られたので、一部改行削除してます
>>620 ハヤスギスwwwww
あそこのblogのシャチョーのマシン、DMAがONになってなかったとかw
しょっぱい人も反応してたけど、そもそもが電波だからなぁ。
ext2でマウントされたブロックデバイスAから 同じくext2でマウントされたブロックデバイスBに ファイル(ディレクトリ)をコピーするときに ブロックデバイスAにあるファイルのiノードの情報を ブロックデバイスBにコピーする際に利用することって できますか?? こうしたらできるはず等ありましたら、教えてください。
iノードの情報ってのがなんなのかよくわからんけど、 ext2ならext2fs.hあたりを利用すればいいんじゃない?
test
OSDL奥山氏の議論にもつながるんだろうが、 ReiserとかExt3とか、ジャーナリングありのFSって、 本当に、「絶対に」整合性を維持できるのだろうか。 たしかに、FSのメタデータの整合性は維持できるかもしれないが、 ジャーナルファイルのメタデータは? そのデータが含まれるセクタを書き込んでいる最中に電源を落とされたら? 全自動電源オンオフマシーンとか作って、 ひたすら「コンセント引っこ抜きテスト」を100年間ぐらい続けたとする。 はたして、ファイルシステムの整合性は保たれるだろうか。
627 :
login:Penguin :2005/06/19(日) 14:17:08 ID:RuFTTgxb
そんなテストになんの意味があるんだかw(プゲラ
つながんねーよ
>ジャーナルファイルの いかにも奥山のサイトを今朝発見しましたって感じ(プゲラ
停電なら不整合は起こるに決まってるジャン。 確実なのはソフト的なアクシデントに対する耐性なんだから。
腐ってる vfs 上にのっかてる fs がまともなわけないじゃん.
おれは, Linux 客先にだすときはかならず xfs 使う.
# xfs が, もからある vfs 使い始めたら, 他の fs も考えてもいい.
>>630 > 確実なのはソフト的なアクシデントに対する耐性なんだから。
*BSD の softupdate は, 停電が発生しても, 更新(書き込み)中の
ファイルの更新部分が破棄されることはあっても, 更新前のファ
イルは生きてるよ.
disk が物理的に破壊されれば話はべつだが, 電源段で fs の整合
性が崩れることはない.
# background fsck が完了するまでゴミは残ってるけど.
>>631 echo # xfs が, もからある vfs 使い始めたら, 他の fs も考えてもいい. > \
sed 's/もから/もとから/'
# ちなみに, 教祖様とは何の関係もないっす.
>>631 それはxfsが元のvfsを認めたから他のfsも考慮するってことなのか、
そうなったら腐ったxfsを捨てるってことのどっちなのか?
xfsが提供してるvfsの上に現状のfsをのせるとかすりゃいいのかと思う。
>>632 >echo # xfs が, もからある vfs 使い始めたら, 他の fs も考えてもいい. > \
^^^^^
たしかに教祖様のレベルにすらいってねーな(プゲ
reiser4ってこのまま永久に外様扱いでカーネルツリーに取り込まれないの?
>>632 それは、sed というファイルにリダイレクトしてるだけのように見える
んだが、s/foo/bar/ の意味はあるのか?
zsh: bad pattern: #
メタデータジャーナルは、停電後の fsck が 短縮される以外の効果は無いと思っても良い。 ジャーナルの無いファイルシステムでも 注意深く実装すれば同等の耐久性が実現できる。 fsck が時間かかることを除けば。 確実に保護できるフルジャーナルは速度が遅すぎて 実用的じゃないので、 UPS を使うことが唯一の解である。きっと。
ext2, reiserfsは壊れた事あるけど、 xfsは今のところ壊れてないな。 もちろんデータは飛ぶけど。 ext3に行く前にreiserfsいったから、ext3はわからん。 でも自分が管理してない仕事マシンは全部ext3。 自分が管理してるマシンはext2/xfsだけど。
ttp://japan.linux.com/desktop/05/06/20/0123202.shtml で NetBSD の Christos Zoulas が
>NetBSDカーネルに感じる主な不満は、以下の点です。
> * ジャーナル・ファイル・システムまたは巨大なファイル・システムのサポートがない。
なんつっとるが、「巨大なファイルシステムサポート」ってのは
ファイルサイズがめちゃでかい時のアロケーションストラテジなのか
reiserとかxfsみたいなB-Tree系のファイル探索高速化なのか
どっちなんやろ
NetBSDにはufs2が移植されているのに。 あと、Solarisには大昔からufs loggingがあるから、OpenSolarisからその辺を 持ってこれないもんかな? ってライセンスの問題があるけど。 SolarisといえばZFSってあんまり噂を聞かないなぁ。
ZFSってリリース時には搭載されずアップデートリリースで実装予定とか聞いたけど結局どうなったん WinFSの方も雑誌のインタビューでじっくりと時間をかけてちゃんとしたものを送り出したいとか答えておきながら、 同じ記事内でWinFSはリリースに間に合わないので(略)なんて答えてるし
solarisのufsで思い出した。 linuxの各種ファイルシステムはCPU(バイトオーダ)に依存しないの?
>>640 「ファイル・システムの安定性:Linuxにははるかに多くのファイル・システムがあり、
力を入れているファイル・システムがディストリビューションごとに異なる(たいていは
技術的な利点ではなく政治的な理由でそうされる)。ほとんどのディストリビューションは
大きなファイル・システムをサポートし、ジャーナリングが実行される。
残念なことに、一部のファイル・システムは安心して利用できるものではないのだが、
一般のユーザが選択するときの判断材料となるような本当の意味での負荷テストが存在しない。」
って本当に同意。テストすること自体を忌諱しているし、テスト結果をみせつけられると
趣味で作っているOSだからと逃げるし。
>>643 有名なのは大丈夫。
まあそういう悲劇に巻き込まれるのはbigendianと相場が決まっているので、
i386使ってれば心配する必要もなかろう。
>>644 仕事でファイルシステムに対する要件が厳しければ、
IBMの保守付きでJFSを利用するとか手はあるんじゃない?
見方にもよるけどLinuxカーネル自体は趣味そのもの。仕方ない。
実際は業務で書いてるコードが大半だけど、そこがまたおもしろい。
64bitで動かないfsもあるぜよ。 JFSは動くようになったんだっけか?
Solaris10 4/05が6/14に出たが zfsは入ってなかったよ(´・ω・) 128bitファイルシステム。 KMGTPEZY。。。単位はなんだろ。。 詳解ファイルシステムの本書こうかな。 各ファイルシステムの諸元からsystem callの流れ。。 すぐ陳腐化しそうだから毎年出すとか必要だろうな。 大変かも。。。
/.-jp みたいなノリだね。
>>648 じゃあ洩れも買おう。
FSの基本とかアルゴリズムなど不変な部分は教科書的に書いて、
実践編をこまめに改訂できれば良書になりそう。
wiki に 1 日 1 ページ書いていけば? 報酬ならジャムおじさん方式で。
一応。 ネットワークバイトオーダーはビッグエンディアン。
656 :
654 :2005/06/22(水) 03:38:04 ID:q++h9cos
>>655 orz サンクス。 何言ってんだオレ。
>>620 すぐに試してみる心意気はすばらしいと思うんですが、
ファイルシステムよりforkが律速段階になっている気がする。
詳解ファイルシステム
>>653 wikiでコツコツ作っていきます。(=゚ω゚)ノ
本の出版はしたことがない素人なので、
wikiでも良いかなってことで
#wikiも本格的に触ったことないんで、勉強しながらですけど。。
zfsが秋ぐらいに出るかもしれないので、
そのぐらいまでに形になっていければいいかな?
とりあえず、今日少しだけ書いてみた。
ファイルシステム諸言とvfsについて
ファイルシステム諸言は書いてないけどia-64の場合ですので
ia-32のほうが利用者多いのでのちほど書きます。
ttp://www.wikihouse.com/linuxfs #内容は期待しないでください。。。。
文章考えるのが大変。。
参考文献→linux-2.6.12.tar.bz2
一から作ってるので、オリジナルだと思うけど、どこかに
似た文章があったら教えてください。書き直します。。
おいおい がんばっちゃってよ
体壊すなよ
諸言?諸元?
かなり期待。 もしミスや誤字その他で気になることがあっても 追い追いこのスレで話しながら直していけばよいでしょう。
>>662 諸言は誤字です。諸元です。。
直しました。ご指摘ありがとうございますm(__)m
vfsについて少し追加(各operations系[fs.h])しました。
#絵も一部欠けてたり。。直さなきゃ。。。
ところで、今作ってる「詳解ファイルシステム」って
こんな感じで作成し続けて良いのかな?
細かいところはかなり省いているんだが。。。
doxygen した方が早いような
同じ指摘ばかりで申し訳ないですが, 「1ディレクトリに10000ファイルを置くテスト」のように, 10000回touchをforkしていると, 時間の大半はforkに かかってしまい, ファイルシステムのテストにはならない気がします. たとえば, seq 1 10000 | xargs touch だと, 私の環境では, 35倍速くなりました. さらに, 専用の小さなプログラム書けば, もっと速くなって, ファイルシステム自体の速度を見るのに役立つと思います.
667 :
666 :2005/06/24(金) 08:24:18 ID:m8AQpDgt
参考までにforkが1回になるようにやってみました. Cで以下のようなプログラムだと, さらに2倍(元の70倍)でした. int main(int ac, char **av) { char name[10]; int fd,i; if (ac < 2) exit (1); i = atoi(*(av+1)); while (i--) { sprintf (name, "%d", i); fd = creat(name, 00644); close(fd); } } ./a.out 10000 perl だと, seq | xargs と同じくらい. perl -e 'for($i=0;$i<10000;$i++){open $fh, ">$i";close $fh}' xargs がお気楽という点で良いかもしれませんね.
各ファイルシステム間のファイルのコピーってどのように行われているのですか? パーミッションやファイルサイズ、アクセス時間などをどうやって移動させているかわかりません。 できればkernel2.6、ファイルシステムはext2で具体的に教えてほしいです。お願いします。 参考HP、参考書籍などありましたら、リンクをお願いします。
GNU fileutilsに含まれるcp(1)のソースを見よ
>>659 vfsの絵はreadからすぐにカーネルに入ってもいいような気がする。
Reiserタン... ガン( ゚д゚)ガレ
>>669 ありがとうございます。
解決しました。m(_ _)mペコリ
突然何を言うか
>>675 >>659 の内容についてだと思う。
Linux のカーネルを元に書いてるから、
Windows 関連について不正確な箇所がある。
そこらへんはゆっくり検証していくしかない。
FAT のファイル数制限の検証をしようとしてるけど
遅すぎてまだ終わっていない。
FATは仕様上ルート以外の制限ないんじゃない? もちろんあるかもしれない実装上の制限を調べたいんなら別だけど。
FATは同一ディレクトリに多数のファイルを置くと 新規作成/削除が目に見えて遅くなるね。 1つ作るのに秒単位で時間がかかる。 もし、ファイルシステム全体での制限を調べているのであれば 今からでも、ディレクトリを細かく分けてテストすることを勧めたい。
指摘をしていただける皆様方ありがとうございますm(_ _)m
どんどん反映して良いものに作り上げたいです。
#良いものが出来れば、ここのテンプレに載せてもらえるかな( ̄ー ̄)ニヤリ
>>666 「1ディレクトリに10000ファイルを置くテスト」
ご指摘ありがとうです。m(_ _)m
1fileをcreateする速度は今のところ
速い 遅い
reiserfs > jfs > ext2 > xfs > ext3 > vfat
と書いてます。
専用の測定プログラムを書けば、速度は速くなりますが
速いファイルシステム、遅いファイルシステムの順番は変わりますか?
目的はどのファイルシステムが速いのかを調べることです。
なので、測定プログラム(コマンド)は何でも良いかなと考えております。
1createで何milli secかかるか測定するものではありません。
環境や測定プログラムによってmilli secは変化しすぎるから。。
>> 674
>>676 の言うとおり、Linuxのカーネルを元に書いてます。
windows上ではsparse fileをサポートしているが、linuxではまだ
サポートしきれておりません。
linux2.6.12.1/fs/ntfs/inode.cの中で、ntfs_truncateで検索してみてると
* ntfs_truncate - called when the i_size of an ntfs inode is changed
* @vi:inode for which the i_size was changed
*
* We do not support i_size changes yet.
とあるし。
詳解ntfsに記述しておきます。。
>680 >専用の測定プログラムを書けば、速度は速くなりますが >速いファイルシステム、遅いファイルシステムの順番は変わりますか? forkなどで律速になったら有意な差が検出できない可能性はある。 またドライバの癖が出る可能性もありそう。
>>680 > 専用の測定プログラムを書けば、速度は速くなりますが
> 速いファイルシステム、遅いファイルシステムの順番は変わりますか?
>
> 目的はどのファイルシステムが速いのかを調べることです。
> なので、測定プログラム(コマンド)は何でも良いかなと考えております。
>
> 1createで何milli secかかるか測定するものではありません。
> 環境や測定プログラムによってmilli secは変化しすぎるから。。
何がしたいのかよく分かりませんな。
君は各ファイルシステムが採用しているデータ構造をサーベイして*ステップ数*で
評価しようとしているのではなかったのか。厳密なステップ数ではなくて計算量オーダーでも別に構わないが。
684 :
666 :2005/06/25(土) 16:08:01 ID:/kSYTAkX
>>680 元の測定だと99%以上の時間がファイルシステム以外で使われています.
順序を知るのが目的だとして, それら99%分の処理が常に同じ時間で
終えるものであれば, 元の測定方法でも問題ないと思います.
ただ, 現実にはforkの時間は結構幅があるような気がします.
後で実際に試してみます.
685 :
666 :2005/06/25(土) 16:14:38 ID:/kSYTAkX
> ただ, 現実にはforkの時間は結構幅があるような気がします. > 後で実際に試してみます. やってみました: (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.38s user 9.96s system 101% cpu 11.137 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.37s user 10.02s system 103% cpu 11.044 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.36s user 10.01s system 102% cpu 11.044 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.39s user 9.97s system 102% cpu 11.041 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.36s user 9.99s system 102% cpu 11.034 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.43s user 9.93s system 102% cpu 11.048 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.38s user 9.95s system 102% cpu 11.040 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.38s user 9.97s system 101% cpu 11.140 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.36s user 10.01s system 101% cpu 11.150 total (; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.37s user 10.01s system 103% cpu 11.035 total まあ, 無視できる誤差と言っても良いのかなあ… # とはいえ釈然としないものはありますが.
users-jp(・∀・)ニヤニヤ
>>686 >Windows では、長いファイル名、サブディレクトリ名、8.3 に短縮された
>エイリアス毎に、それぞれディレクトリ エントリを使用します。
だから結局その半分。
昔1フォルダに3万強以上でファイルが作れなくなったことがあって「仕様と違う」
と思ってたことがあったのだが、これで理由がわかった。
よーく考えろ。作れる数に制限ないとFATの容量(メタデータ)が決まらないだろう。
>>689 FAT の容量はパーティションの容量とクラスタサイズで決まったはず。
ファイル数等の制限とは直接は関係は無かったはず。
1つのクラスタに1つまでのファイルしか入らないので、
その意味でファイル数が制限されることはある。
メタデータは FAT とは別に存在して一応柔軟に生成できる。
但しオンラインデフラグでは移動や削除はできない。
my $cow = 1; while($cow < 65536*256){ my $we = ""; my $sd = $cow; while($sd > 0){ $we = "\\".($sd & 7).$we; $sd >>= 3; }; $we = "H:".$we; if(mkdir($we) == 0){ exit(); }; print($we."\t(".$cow.")\n"); #sleep(1); $cow++; }; こんなプログラム(Win用)で FAT32 上でフォルダ(ディレクトリ)を階層構造で作って見た。 DVD-RAM でテスト中、現在、8万以上のフォルダ生成に成功、速度低下も余りなし。
FAT16 と FAT32 の違いって、なぁに?
>>692 少し上に答えはあるぜ
>>686 ついでに途中経過、42万のフォルダを生成できた。
この調子だと容量を使い切るまで作れそうだ。
>>693 構造の違いについては記載されてないわけだが。
>>688 長いファイル名が長いと、1つのエントリでは納まらないのでさらに減ります。
/usr/src/linux/include/linux/msdos_fs.h にある構造体とかか。 msdos_dir_entry msdos_dir_slot Windows95 になったとき、それまでの MS-DOS ようのプログラムが、 msdos_dir_slot を適正に処理できなくて、うんこな状態だった話とか そんな昔話してもいい?
そういえば、FAT系って ・ルートディレクトリのエントリ数の制限(FAT32でルート移動可になって解消だっけ?) ・システム内ファイル数の制限(クラスタ数の制限だっけ?) があった気がするけど、 ファイル数の制限には、「サイズ0のファイル以外で」という条件があったはず。 つまり、サイズ0のファイル(ディレクトリエントリのみ)は 容量が許す限り、幾つでも作れたはず。
つーことは、EOF_FAT を書くから消費されないということでつかね。
メタデータを使わないファイルシステムって 代表的な奴は何になるのかな
マウントの概念がなかった時代に関しては、ルートディレクトリに たくさんファイルをおける必要はないもんなぁ。
階層ディレクトリの無い時代にも同じ制限があって、困っちゃったわけだが。
他のfsの歴史はちゃんと1.0公開とかあるのに 1997年6月23日 reiserfs のソースコードを web に置く ってのがワロタ
>>699 ファイルサイズもメタデータなので
メタを持にないFSで代表的なのは
まずはテープデバイスだろう。
漢直ユーザですか?
wikihouse重杉
wikihouse重杉
ということで7/7 wiki.livedoor が出来たのでミラー作成
ttp://wiki.livedoor.jp/linuxfs ソースをコピーしただけだから若干表が崩れてます。
#livedoorは手動ミラーなので更新遅いかも。。
vfsをとりあえず、完成させてから
ext2,nfs,reiserfsの説明を充実していきます。
vfs部分はgoogleで調べても載ってないものが多いから
ソース調べて書いてるけど、間違いあったら指摘
よろしくお願いしますm(_ _)m
いろいろ書きたい。。(*´Д`)
kernel2.6.13のこととか脱線気味もたまにはあるけど
気長に完成目指してがんばるっすよ
>>710 乙。
> kernel2.6.13のこととか脱線気味もたまにはあるけど
むしろそれが面白い。
雑誌だとコラムとかに面白いネタ転がってたりするし。
>>710 おまけのところ s/XIM/XIP/
ramdiskなんかに置いてある実行ファイルを
そのまま実行してしまうという技でつ。
フラグメント化した状態は示されても、 フラグメント化したディスクへのアクセスがどれくらいパフォーマンスを劣化させるかは示されていないのだが、 それでよいのか?
なんか /bin/bash あたりがフラグメントしてるのを見て鬱になったぼくがきましたよ。
/bin/sh -> /bin/bash な環境なら確実にキャッシュに入ってるだろうし、 そうでなければ逆にまったく問題ないであろう。
>>718 それ中身を良く読むと、
・ iozoneを複数個並列に動かすような、実環境でありえない方法で激しいフラグメント化を起こし
・ にも関わらず、CPU占有時間は変化せず(スループットは低下せず)
・ シングルスレッドのパフォーマンスの低下も1/2程度
となってて、結局のところ
「実環境でext3fsのフラグメント化の影響を心配する必要はありません」というデータに
見えるのは、私だけかな。
> うはっw俺Al Viroのpatchみてねーや リーナスあたり言ってそうだな
ext2で/から辿れなくなったファイルを救出しようと別領域から立ち上げて dd skip=1300447 ibs=4096 count=1 if=... でそのファイルがあるディレクトリらしき所を見付けました。 ところが、debugfs で cd <1300447> とやっても Ext2 inode is not a directory となります。 <>内に何をいれれば該当ディレクトリにcdできるのでしょうか e2fsck -n の結果は Block size=4096 (log=2) Fragment size=4096 (log=2) 1107584 inodes, 2212953 blocks 110647 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=2269118464 68 block groups 32768 blocks per group, 32768 fragments per group 16288 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 です。
XFSをハードウェアのRAID上(3ware 9500Sシリーズ)で使用しています。 というか運用を始める前にいろいろ実験してます。 Filesystem タイプ サイズ 使用 残り 使用% マウント位置 /dev/sda1 xfs 466G 359G 108G 77% /work1 ハードウェアRAID上でディスク拡張(OCE)を実施して /dev/sda 自身のサイズが増えているのですが /dev/sda1 のパーティションサイズを拡張させなければ xfs_growfs できないことに気がつきました。 で、partedでなんとかなんものかと思ったのですが partedはXFSのりサイズに対応していないようで・・・。 ここで知恵を拝借したいのですが ・XFSを使用することを貫き通す場合、パーティション拡張するにはどうすればいいか? (LVM上に乗っけることくらいしか思い浮かびませんでした) ・XFSにこだわらないとすれば、どのファイルシステムであれば パーティションサイズ拡張 → ファイルシステム拡張 ができるか 使い始める前にこのことに気がついてよかった・・・ 何か逃げ道知ってる方いましたらアドバイスお願いしますだ。
fdiskで削除、作り直し
LVMしかないだろ。
>>724 LVMの256GB制限って拡張されたのかな?
どこの話? PV?VG?LV?
>>726 VGの話なんだけど、ちょっと誤解してたわ。
前に作った時に、エクステントサイズを変更するのを知らんで
256GB以上のVG作ろうとして失敗したもんでそこが制限かと思ってた。
調べてみたらエクステントサイズを拡張すれば、ペタまでいけるんだな。
>>728 qtpertedだったら二週間くらい前にやった。
小さくしたらちょいと壊れた…
731 :
728 :2005/07/24(日) 19:09:27 ID:gZFpPnFD
>730 qtperted使えばreiaserfsのパーティション拡張いけますか? どんな感じのオペレーションしたか差し支えなければ。 KNOPPIXあたり使ったんでしょうか?
732 :
728 :2005/08/01(月) 02:15:47 ID:F13p05NA
libreiserfsインストしても reiserfsのパーティション拡張できなくて血迷った発言してしまいましたが マシンリブートしたら普通に partedでreiserfsのパーティション拡張できました。 ご迷惑おかけしますた。
733 :
728 :2005/08/01(月) 02:19:30 ID:F13p05NA
<チラシの裏> 結局いろいろ調べてみたけど データそのままでXFSのパーティション拡張する方法は見つけられませんでした。 xfs_growfsでファイルシステムの拡張は楽勝でできるのに・・・うぅ LVMは管理がややこしいのでちと避けたいの都合があるので とりあえずはパーティション拡張できるreiserfsで行くことにします。 </チラシの裏>
<チラシの裏>
6TBの外付けRAIDは1TBづつ論理ボリュームが 切られているから、LVMなしではありえない。 そろそろ16TBの壁が見えてきた...
</チラシの裏>
<トイレの壁>
当たり前のような質問かもしれないのですが /dev/hda (300GB)上に dev/hda1 (200GB)を作成してデータを格納した後 fdiskで/dev/hda1 をいったん削除。 すぐに /dev/hda1 を300GBで作成しなおした場合 ファイルシステムが200GBのままだと思うのですが 中のデーターって読めない状態になっちゃうんですよね?
</トイレの壁> 先に閉じ忘れちまったよ・・・ orz
パーティションの開始位置が変わってなくて、終了位置がファイルシステムの末端より後ろならその作業をいくら繰り返そうが読める Win9xのfdiskだと読めなくなるがね
windowsは初心者が多いから、 「fdiskで見えなくしたから大丈夫」 と思う人が多いんだろう。だから、部分的に削除する必要がある。 Linuxの場合、いざというときのために削除しない。みんな分かってるしね。
<チラシの裏> ReiserDriverのrfsdfsd.regがExt2fsdのをそのまま持ってきててわらた </チラシの裏>
シーケンシャル書き込みをしたときに 書き込みが分断されにくいファイルシステムってどれになるんでしょうか? Win機でキャプチャした動画をそのまま LinuxのSamba上に直接書き込みたいのですが。
mkfsした直後のファイルシステムならなんでも
tmpfsオススメ
tmpfs いいね
ramfsとは一味違うよな
ext2でいいんじゃね? 同時にいくつものファイルを扱ったり、小さい(ブロックサイズより)ファイルを大量に扱うのなら他を検討したほがよいと思うけど。 ストレージ容量やファイルサイズが馬鹿でかいときはxfs,jfsがいいって聞くけど、普通の動画ファイル鯖ぐらいならext2で十分かと。 まあジャーナリングぐらいつけておいたほうがよいかとは思うのでext3かな
<!-- UNIX USER 2004年9月号の51ページ に 「XFSは、小さなファイルをiノードに格納する機能を持っており、 当然ながら格納したファイルのパフォーマンスは向上する。……」 って書いてあるんだけど、これ嘘じゃん! だまされたーーー!! -->
メモリ256MBしかなくても2TBのtmpfs作れるんだから。
XFSはその機能あったと思うけど。 デフォルトだと、inodeが256byteしかないから使われないだろうけど。
mkfs.xfs(8)より抜粋 The XFS inode contains a fixed-size part and a variable-size part. The variable-size part, whose size is affected by this option, can contain: directory data, for small directories; attribute data, for small attribute sets; symbolic link data, for small symbolic links; the extent list for the file, for files with a small number of extents; and the root of a tree describing the location of extents for the file, for files with a large number of extents. ファイル自体をinodeに格納する機能は無いと思われ。
directory data, for small directories; symbolic link data, for small symbolic links;
工エェーーー!
Solaris10 3/05版 2005/02/01 ZFS無し Solaris10 4/05版 2005/06/14 ZFS無し Open Solaris 5/05版 2005/06/17 ZFS無し Open Solaris 6/05版 2005/07/20 ZFS無し Open Solaris 7/05版 2005/08/18 ZFS無し ソース落として見たけど、まだ入ってない。。 zfsまだかぁ〜ヽ(`Д´)ノ 詳解ファイルシステムの進捗遅くてゴメンナサイm(_ _;)m
zfsは2006にならなかったっけ?
ext2/3の話だが、 あるディレクトリにファイルをどんどん追加していくと、 ディレクトリサイズって、増えていくけど、逆に そのでかくなったディレクトリ内のファイルをどんどん消していくと、 ディレクトリサイズって小さくなる? Webで調べた感じでは、ポインタのみの移動で片付けられている。 これって、ディレクトリサイズは小さくならないことを意味してる?
syslogって、HDDやRAM Diskが一杯一杯になって書き込めなくなったら自動的に止まってくれるんですか?
2.6.13がでたけど、reiser4は今回も見送り。 やっぱりいらない子か...
まあファイルシステムがぶっこわれていた場合、 阿鼻叫喚の坩堝になりますからなあ。 慎重になってもらった方がうれすい。
Remember 2.4.5!
devfsがぁー! …、使ってなかった。
iozoneでの結果。 Writer:ext3<<XFS Re-Writer:exit3<XFS Reader:ext3=XFS Re-Reader:ext3>XFS だいたい、こんな感じ。 XFS(デフォルト)、XFS(inode size=512)、XFS(inode size=2048)は、ほとんど変わんない。
fs/ntfs/inode.c を気まぐれに読んでたら /* Bye, bye... */ ってのがあってなんかほろりときた
iozoneでの結果つづき。 Writer:ext3<reiserfs<XFS Re-Writer:exit3=reiserfs<XFS Reader:reiserfs<ext3=XFS Re-Reader:XFS<reiserfs<ext3
>>759 消したあとに作成するとtruncateされるそうな(BSD)
なぜでしょうね?
>>768 あれ?raiserが早いって話はどこいったんだorz
>>759 ,769,771
テストしたよ。
# uname -r
2.6.12-gentoo-r9
# df -Th .
Filesystem Type Size Used Avail Use% Mounted on
/dev/hda4 ext3 17G 15G 761M 96% /mnt/hoge
# mkdir test1 && cd test1
test1 # ls -ld .
drwxr-xr-x 2 root root 4096 Sep 6 17:21 .
test1 # touch {0..9999}
test1 # ls -ld .
drwxr-xr-x 2 root root 122880 Sep 6 17:21 .
test1 # rm *
test1 # ls -ld .
drwxr-xr-x 2 root root 122880 Sep 6 17:21 .
test1 # touch a.txt
test1 # ls -ld .
drwxr-xr-x 2 root root 122880 Sep 6 17:22 .
test1 # cd .. && mv test1 test2
# ls -dl test2/
drwxr-xr-x 2 root root 122880 Sep 6 17:22 test2/
#
ディレクトリを異なるファイルシステムに持っていくと、小さくなった。
ちなみに、reiserfs 上では、ファイルを削除した時点で、ディレクトリサイズは縮小された。
>>769 ファイルを消した時に同時にディレクトリもtruncateすると、
直後に作成されたファイルのためにまたディレクトリが伸びることになります。
そしてそれを消すとまたtruncateされる。
この繰り返してslashingが発生するので、
truncateされるのはファイルが増えた時だけなのです。
>>773 raiserfsは何で律儀にtruncateできるんだ?
あとUFS+softdependだとcreate/unlinkは非同期writeになるのでunlink時にtruncate出来ると思う。
ただcreate時までtruncateを遅らせるとCPU時間を節約できる利点はある。
>>774 slashingが起きても気にしないからでは。
UFSはCPU/diskの速さが今と100倍違う時代の設計ですから、
新しいfilesystemではでっかいcacheでなんでも吸収できてしまうと考えて
細かいことを気にしない設計であってもおかしくありませんよ。
冗談はさておき、
UFSはindirect blockが非常に高コストですからtruncate後に起きることに対して
神経質になる必要があります。対してreiserfsは小さなブロックをinodeに格納して
ブロックの手配を遅らせることができるのでslashingは起きません。
てな感じでしょうか。
スラッシングはthrashingじゃない?
> あと、おまけで、Cソースの整形スクリプトも置いてます。 タブでインデントしている馬鹿専用?
タブ正規化している部分を省略して
spaceのままのほうが良いかな?
他の部分はどう?
>>778 私はタブでインデントするので。。。
タブ派?space派?用に2つ用意しますか。
タブでインデントすることのデメリットが大して思い浮かばないのは俺だけですか?
タブ幅が違う環境だと、見え方が変になるとか…… でもスペースも手打ちだとやりにくい (手打ちするなよ、って話ですが)
エディターでいくらでも何とかなる時代にオールドタイプな話をしてんのね。
いちいちタブ幅を変えんの、めんどくさくないっすか? まあ↑の方のやつの反応はどう考えても過剰と思うけど。
俺はタブ派ではあるが、基本的にはどっちでもいい。 が、多人数でメンテしているソースがタブとスペースが混在しているのは、激しく萎える。
expandでもつかっとけ。
GNU indent つかっとけ
778=リチャード・ストールマン
SELinux有効にしてあるマシンで、mkfs.xfsでi-nodeのサイズを指定しなかったんだけど、 具体的のどの程度パフォーマンス落ちるんですかね。ディスクを無駄に食うのはあんまり気にならないんですが。 160GBのディスク中の100GBのfsで既に90GB使ってるから、別のディスク持ってこないと待避出来ない状態。 まあsquidのキャッシュだから捨てても良いんだが。 そもそも、約200人ぐらいのユーザしかいないのに90Gも要らないし。なに考えてたんだろう。 インデントは基本4spaceで、8の倍数ならtab派。 面倒なときは全部tab。
reiser4って2.6.14でもスルーされそうなふいんき? Hansタソに怨みでもあるのかな...
Remember 2.4.5!
792 :
login:Penguin :2005/09/26(月) 18:36:52 ID:/aJAuI9c
NetBSDのLFSを移植したわけではなさそうだな。
Win機でXFS読む方法(出来れば書きも)ってないでしょうか? VirtualPCでLinux入れるしかないのかな。
NILFSの不思議な旅
>>792 lkmlにアナウンスないよね。
彼らは自分達だけでメンテしていくつもりなのかね。
live-patchingの時みたいに。
>>796 live-patchingはlkmlに出てきたぞ。
実装がアホすぎて相手にされなかったが。
NILFSはどうすんのかね。
まずは教祖様の所で叩きまくっていただきたいなあと思いますな。
教祖様はLFS支持派じゃなかったっけ?
LFSってなんだよ。 Linux From Scratch?
Log-structured File Systemってことぐらい
>>792 の記事にも書いているというのに、
799の知能障害っぷりはすさまじいな…
>>797 live-patchingってなに?って聞こうと思ったが
>>800 の用に罵倒されるだろうからlkml検索した。
jump突っ込んでリスタートしないでpatchを突っ込む機能?
なのは分かったが、実装のアホさをかげんを語ってほしい。>知ってる人
i386 と x86_64 でしか動かないところとか?
live-patchingは実装以前に、なぜその機能が必要なのかを 議論して説明できなかったことが問題ではないかな。 だって顧客が(いままでのやり方を変えたくないから) 必要だって言うから、なんて理由ではねぇ。
それにわざわざkernelいじってsyscall追加しなくても既存の仕組みだけで実装 できちゃったしね。
>>797 えっ、教祖様がNILFS書いたんじゃないの?
tmpfsについての雑誌記事をよみ、 さっそくメモリ512MBなのに、 /tmpをtmpfsにしました。 かなり体感上高速化できたので、 調子こいて/usr/tmpと/var/tmpも/tmpのシンボリックリンクに貼り直し、 /usr/src/package/BUILDも/tmpのシンボリックリンクに貼り直しました。 さすがにここまでくると512じゃ足りません。 2GBまで増設しようと思います。
807 :
login:Penguin :2005/09/28(水) 13:08:09 ID:/TXRdfre
808 :
login:Penguin :2005/09/28(水) 14:49:02 ID:Jmeyj6gp
>>806 /usr/tmp や /var/tmp には、
再起動で消えちゃ困るファイルを置くから、
tmpfs にしてはいかんのでは?
そもそも /usr/tmp なんてもう使わんだろ。 ls -ld /usr/tmp してみ。
810 :
806 :2005/09/28(水) 16:42:30 ID:NXYGMIF5
それでは/usr/tmpと/var/tmpはtmpfsやめます。 /var/tmpもう一回掘って、/usr/tmpはそのリンクにします。 i-RAMですか……。もう1GBのメモリを注文してしまいまそた。
symlinkはダサい bind mount汁
>>811 bind mount がダサくないとする件について語ってもらおうか。
>>813 symlinkよりbind mountが後でできたらかじゃないかな?
古いものはダサいという。
新しいか否かだけで、優劣が決まるわけじゃないし、適材適所っつーのもあるし、
その辺を含めて
>>811 に語っていただきたい。
symlinkはsimple is the bestって感じで好きだけどなぁ。お手軽な実装で最大の効果。
bind mountなんて使ってわざわざfstab増やさなくても、symlinkでええやん
symlinkすんのとbind mountすんのとどっちがコスト低いんよ? 教えてエロイ人
819 :
login:Penguin :2005/10/01(土) 00:00:34 ID:T2yStrEv
>>818 その前にコストとは何か定義しろ。話はそれからだ。
動作スピードか?手順の容易さか?管理の複雑さか?かかる時間か?必要な経費か?
FS-p? nil
>>820 --
最大の問題は, まだクリーナ (GC) が未実装でディスクを使いきるとそこで
おしまいになってしまうことです. snapshot を維持した効率的 GC はなかなか
難しく, 公開には間に合いませんでした.
--
少なくともこれが解決するまでは、評価対象にもならん。
GCなしのLFSって何の冗談だよ…。評判の悪いNetBSDのLFSだってGCなしなら そりゃとんでもなく安定して動くぞ。
824 :
login:Penguin :2005/10/02(日) 05:37:34 ID:B9ZIguVy
write onceメディアで使えば無問題
げ、GC無しなのか。。。
9fs
たぶん、雨海さんはGCへの興味からLFSを実装し始めたのだから、 「効率的」のところで色々挑戦したいことがあるのでしょうね。
どうせそのち、みんなNILFSの事なんか忘れて、 GCも実装せずに済むのを待ってるんじゃまいか?
現状のファイルシステムのスタンダードって何? いまだに ext3?
http://www.nilfs.org/ の TODO List に並んでいる項目を眺めてみりゃ
まだアルファ品質レベルなのは明らか。
それなのにバージョン1.0.0としてこのタイミングでリリースしたのは
NTT内部でいろいろ政治的な問題があったんだろうね。
>>828 未踏のプロジェクトだったら間違いなくそれだよなw
disk fullになったら落ちるのか (((;゚Д゚))ガクガクブルブル
Known Bugs The system hangs on a disk full condition. . ィ .._ .......、._ _ /:/l! またまた、ご冗談を :~""''.>゙' "~ ,、、''‐'、| _ ゙、'、::::::ノ:::::::_,.-=. _〜:、 /_.}'':, ``、/:::::::::__....,._ `゙'Y' _.ェ-、....._ /_゙''i゙ノ、ノ ,.--l‐''"~..-_'.x-='"゙ー 、`'-、 ,:' ノ゙ノブ " .!-'",/ `'-‐'') /\ `/ でノ-〈 .-''~ >'゙:: ‐'"゙./ ヽ.,' ~ / //::::: ', / ,:'
NetBSDが苦労してたのが、サクっと出てきたのかと思ってスゲーってって思ったのに、 肝心要の部分は、出来てないんですね(´・ω・`)
GC抜きのLinux用LFSを一から作るより、NetBSDのLFSのGCに手を入れて安定化を 目指すほうが、技術的には1万倍ぐらい有用だと思う。ってことでNILFSの目的って NTT研でこんなことやってますよってアドバルーンを上げることだけなんだろうな…
>>833 /ノ 0ヽ
_|___|_
ヽ( # ゚Д゚)ノ ゲイツのファットの方がまだ気合いが入ってる!
| 个 |
ノ| ̄ ̄ヽ
∪⌒∪
>>837 なにかに間に合わせるためにとりあえず発表つー感じですな。
まあ発表した所で、時限爆弾を抱えているファイルシステムなんて物を、
評価以外で使う人はいないと思いまふが。
ここは白痴のスレか?それとも釣堀か?
自分は結構楽しみに待ってたりする。 気長にいこーよ。
つーか今は使い物になる前に公開するのが基本だろ?
いやmergeはちょっと…
>>843 GCなしのLFSは使い物になるかどうか以前の問題なんだけど。
一番重要なところが実装されていないどころか、仕様すらできていない。
上半期末だったのでチャレンジシートに書く成果のために急いていたのかねえ。 もっともあと半年待ったところでどうにかなるものでもなさそうだが。
>>847 この成果でチャレンジシート書いても良い評価はもらえんような気もするが。
849 :
login:Penguin :2005/10/06(木) 17:27:53 ID:/klPsKwC
>>752 :login:Penguin:2005/08/19(金) 01:12:20 ID:eyFrYcEH
>>メモリ256MBしかなくても2TBのtmpfs作れるんだから。
って有るんだけど どういう意味?誰か教えて。
>>849 実メモリ以上の大きさの仮想メモリが確保できます という話
結局swapするんだけど。 プロセス用のメモリを圧迫してしまわないかが心配なのだけど、パフォーマンスはどうなのかな?
馬鹿の心配、するが問題
ファイルシステムの容量以上の sparse file 作って 全部埋めようとしたらどうなる?
おまえの馬鹿さ加減が知れる
>>851 何もかもスワップします
スワップするとパフォーマンスは落ちます
研究用にLinuxに新しいファイルシステム作る研究っていくつもあるけど、 やりかけで発表して、そのうちLinuxカーネルのファイルシステムや バッファキャッシュに大工事が入って、内容を把握できていない第三者には メンテできない状態になってそのまま放棄っていうパターンが多い気がする。 Linuxで昔LFS実装してGC前にやめた人がいたよな…論文書いてジ・エンド だったような。
>>849 sudo mount -o size=2048g -t tmpfs /dev/shm /var/tmp
とかできるってことだろ。
>>851 1Gメモリのマシンでtmpfsで1G使い切ってもシステムは動くから問題なし。
tune2fsしてなかったext3で電源ぶち切れたら起動時にfsckにぶっ壊されてデータが全部消えてた アッタマきたから全部reiserfsに入れ替えたよ
>>858 気になる。ぶっ壊れたext3のfilesystem featuresはどんなでしたか?
こういうのは、大概アホの操作ミスなので参考にならない。 おまえふだんからrootユーザで使ってるような奴だろう?
>>860 バカだな。アホの失敗こそが参考になるんだよ。
Reiser4は前途多難だな
reiserfsって大きなパーティションのマウントにやたら時間かからない?
>>864 相変わらずGCが実装されていなくて、使い物にならない罠
LFSのGCはいくら彼等でも大変やろ
でも、GCのないLFSは完全に無意味でそ。一番重要な部分なんだから。
数年後に別のOSで別の実装が出てきた時に、 Related paperに名前が乗るだけでいいと おもってるんだよ。
最近のディストリビューションだとインストーラから作ったファイ ルシステムは最初から dir_index 有効になってない? とりあえず手元のFedoraCore3では既に有効だった.
Fedora使ってると世間の動きののろさに驚かされる
Fedoraの意味は失われていないと。
>>870 そんなんFedoraだけだよ〜。∴RHEL4でもそうなってるし。
"."と".."が真ん中らへんにあってめちゃうざいんで、速攻
# tune2fs -O ^dir_index /dev/hda1
してます(tarファイルを作るときなんかばばっちくなるから)。
意味不明
>>873 確かにそういう問題はありますな。理解できない人は、既存のtarファイルを
一旦展開して再度固める作業を、非dir_indexファイルシステムとdir_index
ファイルシステムで同様に行って、オリジナルのtarファイルと比較してみ。
それが問題だと言ってしまう脳に問題があるように思うがな
なんかさ、 FAT で育って FD とかでディレクトリエントリを 操作することのみに人生を捧げてきた香具師とか そんな感じの痛さだぬ。 そういう人がいてもいいけどファイルシステムを どうこう言うスレに来るのは場違いだな。
>>873 財布の中のお札が、製造番号順じゃないと気が済まない人もいると聞いたのですが、あなただったんですね。
DVD-RAMの書込速度がReiser4だとUDFとEXT3の倍、Reiserfs3の1.5倍速かった。
>>878 > 財布の中のお札が、製造番号
硬貨を製造年順に並べている香具師も居ますね。w
でもこれって、単にソートすればいいんじゃない?
readdir(2)に関わる基本コマンドって、
ls
tar
find
他にあったっけ?
それ以前に ls をわざわざ -f 付で使う香具師なんているのか?
>>882 オレは額面順にソートしてるな
大量の1万円札の中に混じってる1000札ってすごい見つけづらい
俺の財布には千円札しか入ってないから、ソートする必要がない。
俺の財布には千円札すら入ってないから、ソートする必要がない。
1枚だけならソートしなくても良い
>>879 | Christoph Hellwigは、ReiserFSの中でLinuxのI/Oの機構が再実装されている
| 理由を説明するか、再実装を止める必要があるだろうと宣言しました。
ニヤニヤ
>>888 そりゃあ、OS標準のI/Oが腐っているからだ罠…
xfsもI/O自前とかって話なかったっけ?
ごめん、debugreiserfs -p /dev/xxxn ね
>>892 >ロック無しでどうやって整合性とるんだよ。
リンク先の
>編注:RCUについては、「全貌を現したLinuxカーネル2.6[第1章]」も参照。
嫁
>>〜ロックが不要に?
ありえない。
おまえこそソース嫁
>>894
よくわかんないので誰か教えておくれ.
>>892 の記事は端から間違いなの?
それとも「ロック」という一般名称が問題で,
「RCU導入でread(),write()のためのspinlock()が不要に」
なら問題ないの?
つか、RCUを使ってる構造体ってのはどれなわけ?
lヽ ノ l l l l ヽ ヽ )'ーーノ( | | | 、 / l| l ハヽ |ー‐''"l / R | | |/| ハ / / ,/ /|ノ /l / l l l| l R ヽ l ・ i´ | ヽ、| |r|| | //--‐'" `'メ、_lノ| / ・ / | C l トー-トヽ| |ノ ''"´` rー-/// | C | | ・ |/ | l ||、 ''""" j ""''/ | |ヽl ・ | | U | | l | ヽ, ― / | | l U | | !! | / | | | ` ー-‐ ' ´|| ,ノ| | | !! | ノー‐---、,| / │l、l |レ' ,ノノ ノハ、_ノヽ / / ノ⌒ヾ、 ヽ ノハ, | ,/ ,イーf'´ /´ \ | ,/´ |ヽl | /-ト、| ┼―- 、_ヽメr' , -=l''"ハ | l ,/ | ヽ \ _,ノーf' ´ ノノ ヽ | | 、_ _ ‐''l `ー‐―''" ⌒'ー--‐'´`ヽ、_ _,ノ ノ  ̄ ̄ | /  ̄
おまいら、ソース嫁よw
RCU は、要は、 VRAM 裏画面で描画しつつ、 CRT に表示されるのは VRAM表画面、つーことか? で、表画面を完全に表示し終わったら 裏画面の内容を垂直回帰期間中に表画面に転送すると、そういう感じ?
RTFS
>>903 頭悪いのに無理して理解したつもりにならなくてもいいから
906 :
login:Penguin :2005/11/02(水) 03:30:39 ID:u4aR+emM
>>903 ROTFL
Is it a PC98 machine, isn't it?
Wow, I feel very nostalgic.
DragonflyBSD では lock 排除を messaging でやろうとしてて
wikipedia によれば
| The serializing token code is evolving into something quite similar to
| the "Read-copy-update" feature now available in Linux. Unlike
| Linux's current RCU implementation, DragonFly's is being implemented such
| that only processors competing for the same token are affected rather than
| all processors in the computer.
ttp://en.wikipedia.org/wiki/DragonflyBSD
reiser4でのbadblockの扱いについてご存じの方いませんか? reiserfs のときは、badblockを指定してファイルシステムを作成できたのに reiser4だとダメみたいなんですが、これって自動ってうまいことやってくれるってことなんでしょうか・・・・・? 最近、LANDISKがカッチョンカッチョン言い始めて怖いのです・・・・
910 :
login:Penguin :2005/11/02(水) 21:56:08 ID:OP6gpXTW
MS Officeを動作させる話題の"David"搭載、2年ぶりの待望のメジャーバージョンアップ
新製品「Turbolinux FUJI」発表
2005年11月25日より販売開始
ターボリナックス株式会社
同新製品は、2003年10月にリリースされ、リナックスOS分野で前人未踏の
52週(1年間)連続売上第一位(BCN調べ)を記録し、
数年来国内売上シェア第一位を誇るターボリナックスの
基幹デスクトップ製品「Turbolinux 10 Desktop」(以下10D)
の後継製品にあたり、 国産OSならではの完成された日本語環境はもちろん、
10Dで提唱したWindowsとの互換性をさらに強め、安全性、 安定性に優れた
デスクトップ環境を提供します。Windows環境との共存の強化により、Linux
とWindowsの優位性を融合した ハイブリッド・デスクトップリナックスOSとして、
企業、官公庁、自治体、教育機関などへの導入をより一層スムーズなものとします。
FUJIではOS本体とプラグインという新しいビジネスモデルを展開します。
これにより、ユーザーは基幹OSであるFUJIを入手すれば、
用途に応じてプラグインを足すだけで自分だけに特化したOSを利用することが可能となります。
現時点において、ビジネスユース向けプラグイン、 ホームユース向けプラグインやURLフィル
タリングソフトなど、セキュリティ関連プラグインの提供を予定していますが、都度ユーザー
ニーズを 市場から汲み取り、タイムリーに新しいプラグインを提供することがFUJIの価値を高
めるものと考えています。なお、FUJI発売と同時に プラグイン第一弾としてサイバーリンク社
の「PowerDVD for Linux」が決定しており、これら各種プラグインは新ツール"Turboプラス"経
由で提供し、 ユーザーは簡単に購入、ダウンロード、インストールができるようになります。
http://www.turbolinux.co.jp/cgi-bin/newsrelease/index.cgi?date2=20050920033408&mode=syosai
結局 UFS2+S に行き付く。
うひょー。 reiserfs(3.6)、FAQには最大ファイルシステムサイズ 16TB とあるけど、実際には8TBに壁があるとわ。ハマッタぜ。
すげーな。8T越えか。 jfsとかxfsはどうよ?sunのzfs(だっけ)とかも気にある。 さすがにそれだけあると再フォーマットする気にもならんだろうけどさ・・・
とっくのとうに
常識
920 :
916 :2005/11/08(火) 22:15:54 ID:MOc07+j7
921 :
login:Penguin :2005/11/08(火) 23:19:08 ID:4VjcNAzO
4G(32bit) x 512B(1block) = 2TB だしな
>>920 要するにxfs_repairはファイルシステムの中に書かれているファイルエントリが
多ければ多いほどメモリを食う仕掛けになっているが、ia32 (i386)環境では
プロセス毎に最大で4GBに制限されているため、いくらメモリを積んだところで
巨大なファイルシステムには対応できない、ということか。
8TBが、IA32 Systemでの xfs_repair を実行するには大きすぎる、 ということは分かったのですが、実際、IA32ならば何TBまでOKなのでしょうか。 4TBまでならばOKなのか、もっと小さいのか。
>923 を見る限り 8TB が大きいっつーよりは ファイル・ディレクトリの数が問題なんじゃないの? 一つ辺り数GBな映像ファイルしか格納しないなら問題ないとか?
>>923 >いくらメモリを積んだところで...
Windowsのリソース64k制限を思い出したよ
927 :
login:Penguin :2005/11/09(水) 18:41:29 ID:OfqFgXaM
ちんちんおっき
920のメールのスレであったけれど、 だいたい、1TBにつき1GBメモリが必要だそうです。
自動じゃなくユーザーによる手動GCを実装予定って本気かnilfs
>>930 それ、PostgreSQLのvacuumみたいだな…
まあ、PostgreSQLはlog structureだから似たような感じになるのは当然だけど。
PostgreSQLの場合8.1からはauto vacuumがデフォで入って、ユーザから
vacuumをあまり意識する必要なくなったけど、nilfsではまだ手動vacuumを実装すら
していない段階…
>>930 LKCの話を聞いてきたが、まともなGCが入るまで時間がかかりそうだのう。
当分は手動で頑張るしか。
まあお遊びレベルならcronあたりで使ってない時間帯にGC走らせればいいんでないかい。
>>930 いつGCするのが一番良いかは、たいてい管理者がしっているはずなので、
自動でするよりもいいんじゃないの?
だがそれは、平時は自動GCで かつ ユーザが緊急時に手動GC可能 というのが本来の動作のはずだ
935 :
◆IIiDC8JS7w :2005/11/18(金) 00:11:09 ID:oJmW3WGc
>最大ファイルシステムサイズ : 1YB >最大ファイルサイズ : 8EB 理論上はそうかもしれんが、実際のところどこまでチェックして あるのだろう。
>>936 確かに気になるね。
最大○○はビット数さえ増やせばとりあえず実現できるし。
そんなことより、copy-on-write はマジメに動いてるのか、
snapshot がマジメに動いているのか気になるところ。
あと、storage pool とかで sds が不要になるのはいつ頃だろうか。
Linux2.4もしくは2.6環境で使えて、 オンラインのスナップショット機能がある ファイルシステムってどんなのがありますか? 環境テスト用なのでVMwareでもいいんだけども。
>>938 LFSのやつがスナップショット使えなかったっけ?
>>938 FreeBSDなら5.x以降のUFS2使ってスナップショット作るけど、
LinuxだとfsでやらずにLVMでやれば?
941 :
login:Penguin :2005/11/20(日) 13:11:41 ID:6bRnjPit
ext2/ext3で、使われてないブロックをゼロクリアするようなツール・方法ありますか? ddで取ったパーティションのダンプイメージを圧縮する時に、 圧縮率を高めたいというのが目的ですが。 とりあえず一度でかいファイルを /dev/zeroから生成して削除することで ある程度の効果はあるようですが、もうちょっとスマートにやりたいのです。
使用率が少なければdump/restoreするほうが速いだろ
使われてないブロックがたくさんあるなら、 ファイルシステム上で圧縮したら?
レスありがとうございます。
>>942 dump/restoreですか。使えるかどうか検討してみます。
>>943 納品物件として、稼動するシステムのディスクイメージってのがあるんで
個々のファイルを圧縮するってのは無理なんですよ。
dd if=/dev/zero of=hogehoge bs=1024k count=てきとう mkfs -text2 hogehoge mount -o loop hogehoge /mnt cp -ar 納品物 /mnt umount /mnt とか。 どうしても今ある物を吸い上げる必要があるなら、 でかいファイルを作るのがいちばん安全じゃないかと。
それをやるなら touch hogehoge mkfs -t ext2 -f hogehoge てきとう のほうが早い。
>944 FreeBSD で UFS つかって ufscopy こそが正解 ダメですか…
>>946 うちのだと -f じゃなくて -F みたい。
でも mkfs だと sparse なファイルになっちゃわない?
>>948 あとで圧縮する予定なんだからsparseなファイルで問題ないだろ
945 のプロセスの一部を置き替えるだけだったのね。 既存ファイルシステムの空きを全部 zero fill する簡単な方法のつもりなのかと思った。
partimageでいいじゃん
デフラグのアルゴリズムってどんな? 単純にファイル長確保できたディスク領域に連続配置するだけだと デフラグによる速度低下ってありそうなんですが... 詳しく載ってるHPがあれば教えて下さい #デフラグのオーダーってどのくらいだろう!?
∞
>>944 亀レスですが・・・
稼動してる状態でディスクイメージ作るなら
mondorescueなんてのもありますね。
ブータブルDVDなんかも作れるしなかなか便利ですよ。
ZFS突撃報告キボン
いやさすがに無理だろ 誰もポーティングしてねえよ
今現在UDFの書き込みってのはどの程度安定して使える物なんだろうか? ちょっとDVD-RAMでも使ってみようかなと考えてるんだけど。
一応Windows XPにPanasonicのRAMドライバーを入れた物で UDF2.0フォーマットのDVD-RAMディスクに書き込み、 それをLinuxマシンに入れて読み込めることを確認、 Linuxで小さなテキストファイルを書き込んでWinXPの方で読み込める事を確認した。 とりあえずは問題なく動いてるようだけど、 それなりに運用経験のある人の意見が聞きたいなあと思ったので。
いっぱいありすぎてワカンネー奴は ext3(とext2)をつかっとけってこと?
ま、そうかな。 有名どころならハズレってことは特にないだろう。
964 :
login:Penguin :2005/12/28(水) 11:59:21 ID:GGzkOdw4
環境を再構築したのでext3からRaiserにしたんだけど、システムの起動やアプリケーションの起動が早くなった気がする。 Raiserの方がパフォーマンスいいの?
>>965 その質問の回答は、「得手不得手がある」としか言いようがない。
どっかでベンチマークみたことあるんだけど…どこだったか忘れた。
967 :
965 :2006/01/03(火) 03:17:24 ID:JN/GY0Pk
>>966 俺も書いた後でそう思った。スマン。
デスクトップ用途で使っているんだけど、どっかにベンチマーク資料ないかな
968 :
login:Penguin :2006/01/03(火) 16:40:23 ID:vvF1lec/
2.6.15が出たね。 2.6の正式バージョンが出てからもう2年になるけど、 そろそろ安定した?真面目に使い始めようかな・・・迷う。
無停止稼動し続けなきゃいけないとか2.6では今のシステムが動かないとかならともかく
>>967 ずいぶん昔の資料なら見た覚えがあるけど
最近のカーネルだと結果変わってくるんじゃない?
自分でベンチ取るのが早いかもよ
もはや2.6じゃないとなんだか不安です。セキュリティ観点だと。
そういえば,カーネル2.6のNFSってページキャッシュ使うんだっけ? 記憶では2.6になってからページキャッシュに渡さずに 直接ネットワークプロトコルに渡すよーになった気がするんだが,,, 分かる人居たらレス キボンヌ
∧_∧ + (0゚・∀・) ツヤツヤ テカテカ (0゚∪ ∪ + と__)__) +
OCFS2 キタ━(゜∀゜)━! 2.6.16-rc1から使用可能になりまつ。 楽しみです。 Oracleの作った並列ファイルシステム。 ところどころにxfsのソースを参考にしてますというコメントが。。。 >972 CONFIG_NFS_DIRECTIOでカーネルmakeしていてなおかつ ファイルのopenmodeがO_DIRECTならデータをキャッシュに 乗せない と思う。。 サーバ側とクライアント側、NFSv3とNFSv4共通なのかな? 気になってきたけど、 (つ∀-)オヤスミー
やっぱりreiserfsのmountは時間がかかるのか
reiserfs使ってるやつは彼女にマウントするのにも時間がかかる
俺にはマウントポイントが見つかりません。
つshared mount
ループバックがあるじゃないか
reiser4は、マウントした後は早いらしいぞ
NFSで遠距離
遠くにいる彼女と VPN で接続したいのですがどうしたらいいですか?