09/06/04 19:23:39 pOC2w+XZ
予定してた2TBのHDがまだ来る気配もないしF11も遅れてるし
とりあえず手持ちの1TB x 22でRAID6つくってxfsでも使ってよう。
URLﾘﾝｸ(www.picamatic.com)
251:211
09/06/05 18:14:10 MeOcKTW7
Fedora11_Previewでの
ext4
URLﾘﾝｸ(www.picamatic.com)
btrfs
URLﾘﾝｸ(www.picamatic.com)
上の20TBのボリュームは別の用途で使っているためRAID6のiSCSIボリューム約13TB使用
URLﾘﾝｸ(www.picamatic.com)
いまのところbtrfsはext4とxfsに比べて若干遅い(10%前後)
252:login:Penguin
09/06/05 21:20:15 zxcrO3om
ｽﾚﾘﾝｸ(unix板:282番)
282 ：名無しさん＠お腹いっぱい。：2009/05/23(土) 17:27:02
日経Linux最新号買った？
brtfs vs ZFS のがちんこ勝負。
結果は ZFS の負け。
理由はファイルシステムをマウントしたままデフラグができないからだそうだ。
え？
253:login:Penguin
09/06/05 21:43:43 YpJE6ayf
いったい何を勝負したんだ？
254:login:Penguin
09/06/05 22:05:11 YeULR2yk
btrfsなんてまだ評価以前の代物なのに。
255:login:Penguin
09/06/05 22:25:11 qIsowSsx
さあ早くtune2fs -o journal_data_orderedする作業に戻るんだ
256:login:Penguin
09/06/05 23:43:30 skD9hEdA
BtrfsとZFSがチンコ勝負…
SUNなZFSに勝てるなんてOracleはどんだけビッグなんだよ
257:login:Penguin
09/06/06 01:29:59 vPPd6Hlz
ext4のデフラグツールﾏﾀﾞｰ?
258:login:Penguin
09/06/06 07:48:15 gSrpMgBT
>>252
RAID-Zなどで使うのが当然というfsでデフラグってなんの冗談だ?
259:login:Penguin
09/06/06 10:54:31 EjsbOXDm
>>258
デフラグなんていらないって，こいつらに言ってやれよ
URLﾘﾝｸ(wiki.genunix.org)
260:login:Penguin
09/06/06 11:30:42 llsk3snN
洋の東西を問わずデフラグ信者がデスクトップ界隈にたくさんいるので、実質意味なくてもサポートは必要なんだろうな
261:login:Penguin
09/06/06 11:37:52 Esm55MCB
そういうのは、
dd if=/dev/hoge of=/dev/null
とかやって、適当に途中経過表示するだけで満足したりして。
262:login:Penguin
09/06/06 11:53:20 EjsbOXDm
意味の無いデフラグを提案する糞開発者ｗ
URLﾘﾝｸ(www.mail-archive.com)
>>261
（笑）
263:login:Penguin
09/06/06 12:10:54 sqIZeg7O
なんとなくだが、defragが安全に実装が完了するより先に、SSDの大容量化とコストダウンが
先行してしまうような気がする。
実際、鯖用途で考えたら比較対象となるHDDは容量大きくて低価格なSATAじゃなくて、
24時間運用可能だけど容量いまいちで値段が高いSASになるから、そうすると既にC/Pは
もうちょっとってところまで来てるもんねぇ…。
264:login:Penguin
09/06/06 14:45:58 0f310tGM
>>251
ファイルシステムのベンチマーク取るのなら、
bonnie++じゃなきゃ価値がないと思うんだが。
265:251
09/06/06 15:52:34 NHEM8KDs
>>264
そうだね
・ddの結果が「いわゆる」ベンチマークの結果だとは考えてはいない
が、当面の用途はビデオファイル(1個が5～20GB)なのでddの結果でも充分参考になる
・来週には正式版がでてくるのでPreviewで真面目に計測する気はない
>>251で「遅い」と言ったのはあくまでも
ddで出てくる xxxMB/secおよびiSCSI-H/W_RAIDの転送速度インジケータをみた目分量から
ちなみに、xfs、ext4では100MB/sec前後、btrfsで90MB/sec弱
実用で考えているFC接続で同じ傾向になるかはわからない
266:login:Penguin
09/06/07 03:04:10 04RnY7h3
>>252
6月号64ページのファイルシステム機能比較表のこと？
ZFSは参考として載ってるだけで、がちんこ勝負という風には見えなかったぞ。
対応RAIDレベルではbtrfsよりZFSの方が多くのRAIDレベルに対応と載ってるし。
267:264
09/06/07 11:47:46 n8O8daQH
ddの結果が参考になるって・・・・・バカなの？
常に単一の書き込みしか行わず、しかも同時に書き込むわけでもないddが参考？
bonnie++ですら参考程度にしかならないってのに、どんだけ幸せ思考なんだか・・・・・
本当、救いようのないバカだな
大体、分かってんのかな
ext4ってのは未だに、大量のパッチやバグ報告がML上で飛びかうstableなんて名ばかりのFSだし
XFSなんて、信者は無かった事にしてるがxfs_repairのメモリ大量要求や、不完全データファイルをゼロクリアする素敵機能付きだし
btrfsに至っては、experimental宣言している上に、つい最近New Experimental Branchが切られたばかりの、正に文字通りHeavy DevelopmentなFSだ
わざわざそんな不完全なFS集めて、何かある度ここで騒ぐわけ？ 勘弁しろって全くよ
つか、常識あったらWinからNTFSで作っといて、LinuxからはCIFS経由で使うか、
SolarisなりFreeBSDからZFSで作ってNFSか、Samba経由でCIFSマウントするって
どうしてもLinuxでやりたきゃ、ディスク区切ってext3一択だな
普通は障害があった時の事を第1に考えるからな、復旧の怪しそうなFSなんて候補にすら入らんよ
それをわざわざLinuxから、しかも問題の起きそうなFS選んでとか、ネタでもやらねえって
まあddが参考になる程度のIO想定ならexFATで十分だろうけどよ
268:login:Penguin
09/06/07 12:03:06 ALgbBw22
>>267
何ファビョッてんの
ビデオだったらxfsが無難だと思うけどね
269:login:Penguin
09/06/07 12:04:48 Oh8Lh+rd
>>268
いつもの人だから触っちゃダメ
270:login:Penguin
09/06/07 14:35:56 1iwXKTOD
xfsのゼロクリアってあえてやってるんでしょ？
271:login:Penguin
09/06/07 20:55:19 ELAUhkI1
ext2って電源断に弱いですか？
ファイルが損失する理由がわからないです。
ファイルを編集するときはメモリ上に書き込んで、HDD上は削除されるということなのでしょうか？
HDD上削除されなければ電源断時にも復活されるのでは？
272:login:Penguin
09/06/07 21:02:41 jYLS0xyE
>>271
前のファイルのままということはあっても、完全喪失というのは稀なレベル。
最悪でも普通はlost+foundに救出される。
273:login:Penguin
09/06/07 21:22:33 eb8s04gy
>>271
ジャーナルが無い分、「弱いか？」と聞かれたら「弱い」になる。
HDDにもバッファメモリがあるしOSもディスクキャッシュを保持するし
git clone hagehage してる時に電源が落ちたら何かしら壊れてくれそう
・・・ダメだ
いつも茶々入れてる人はこういう時に本領発揮して分かりやすく丁寧に、
「素人だったの私がこの解説を聞いたのがファイルシステムを開発するきっかけでした。」
って言わせるくらい趣き深い答えをしてあげてください
274:login:Penguin
09/06/07 21:41:54 Muz+bcji
そういえば、昔、Oracleで電源トラブル無くてもファイルのcorrupt問題があったような記憶が...
多分Cacheハンドリングのバグ(Oracleから言わせれば仕様)だったかな ?
275:login:Penguin
09/06/07 22:21:29 TUQDvEOj
>>271
メタデータの書き込み途中で落ちたら、参照できなくなって消える。
fsckで復活できる場合もあるが、かなり時間がかかる。
ジャーナルファイルシステムだとその心配が無いし、急な電源断時も完全なfsckは不要で復帰が早い。
276:login:Penguin
09/06/07 22:46:43 q7MhCH00
>>270
そうだよ
上のアレはきっと奥なんとかに毒されてる信者だから触るなよ
277:login:Penguin
09/06/07 23:43:52 hepWkHiO
>>275
ジャーナルファイルが壊れた場合はどうするんだ？
あれだってタダのデータだろ。
278:login:Penguin
09/06/07 23:50:17 XaFBxSJG
おまえの裏の人格が夜中に発動して壊さない限り壊れない
279:login:Penguin
09/06/08 06:41:04 pjr9nEOD
>>273>>275>>277
今時ext2を使っている人というのが想定できないが質問内容から照らし合わせるに
ジャーナルもメタデータもジャーナルファイルも全く意味不明の単語に聞こえるだろう。
280:login:Penguin
09/06/08 07:19:18 kvbAIbpF
>>271
現在主流のジャーナリングファイルシステムに比べれば、電源断に弱い。
しかしながら、「弱い」というほど弱くはない。
後継のext3が主流となり、ext4もできつつある今、
特別なパフォーマンスを要求しない限り、ext3を使った方がよい。
# って答えでいいか?
281:本当の264
09/06/08 10:04:03 4MvMHn9a
>>267
ちょっｗ 勝手に264名乗らないでｗ
282:login:Penguin
09/06/08 11:03:26 gamXREiU
現状では、実用性重視ならreiserfsしか選択肢が無いな。
283:login:Penguin
09/06/08 11:09:06 kvbAIbpF
>>282
reiserfsとかw
マジでそうだから困る。
284:login:Penguin
09/06/08 12:05:58 uuuo0ENf
何はともあれ、今時 ext2 は止めといた方がいいですよ。
285:login:Penguin
09/06/08 12:26:32 joEenCpk
/bootとディスクイメージ内のFSにext2つかってる
286:login:Penguin
09/06/08 12:32:17 Tzl1D/T+
/boot ext2
/ reiserfs
/var reiserfs
/home xfs
287:login:Penguin
09/06/08 12:48:59 hKwKsQNd
kernel watchによるとgoogleはext2をつかっているらしいけどね
288:login:Penguin
09/06/08 12:53:27 SObkUY93
>266
勝ち負け以前に、btrfsが今だexperimentalで、データがいつ消えても泣かない・ちゃんと
報告する程度のものってことに記事のどこにも出てこないってのはダメじゃないかな。
むしろ「Btrfsを使ってみよう」みたいなノリノリだからねぇ。
289:login:Penguin
09/06/08 13:40:49 AvnesfX4
不意打ちfsckでファイル名前が化けたりFAT32はchk.001とか作りまくるくらい脆い印象がある。
Ext2IFS？だったかWindows上で普通の感覚で使えるドライバーがあったがあれには重宝するんじゃないの。
Using The BTRFS Filesystem On Debian Lenny
URLﾘﾝｸ(www.howtoforge.com)
ソースのビルドを2GBの/dev/shmでやるのは苦しい時もあるので解決案を探してます
BTRFSもまだ試してないんだがCOWが使えるFSは今のところ何があるの？
reiserfsの小さいファイルの特性は飛び抜けてる?
今はext3を基調に/usr/shareと/usr/src、その他データ領域をxfsで使ってます。
私的感情の混じってない複数人のざっくりした見解が聞きたいです。
290:login:Penguin
09/06/08 13:43:50 xArk/8v2
tmpfsとswap使えばファイルシステムに依存しなくなるのにww
291:login:Penguin
09/06/08 13:48:05 9+zpPHhG
btr犬fs
自慰用
292:login:Penguin
09/06/08 13:58:12 AvnesfX4
>>290
ディストリによって違うんだろうけど/dev/shmって書いてあるだろが・・・
293:login:Penguin
09/06/08 14:03:07 Mf/AoFnn
>>289
/usr/srcをxfsにするなら、mkfsする際にlog関連のパラメータを適切に設定
しないと小さいファイルの削除がext3より遅くなるぞ。
294:271
09/06/08 23:11:11 LAXM1eVU
ほとんど変更のないパーティションはジャーナルいらないからext2でいいのでは？ と思ったからです。
/boot や / など。
ext2でファイルが壊れるってどんなとき？
ファイルが作成されて、変更もなしで、数日後にクラッシュしてファイルが壊れることもありうる？
295:login:Penguin
09/06/08 23:22:42 MjyV0szQ
あり得るか,と言われれば
あり得るとしか・・・この世のモノは全て壊れる運命なので・・・・
殆ど変更がなくて、
「後で復旧できるように構築手順かバックアップが取ってある」なら
ext2 でいいんじゃね？
インストール時に作られて手を入れてないとかいう部分だったら
再構築も楽だろうしそんなんでもいい、という用途はあると思う。
296:login:Penguin
09/06/08 23:23:06 oMVcdxiB
>>294
> ext2でファイルが壊れるってどんなとき？
今壊れちゃったらマジで困るってとき
297:login:Penguin
09/06/08 23:56:46 jfF7vcnN
ext3が作られたのはext2じゃfsck遅すぎてやってらんねってことだったっけ？
298:login:Penguin
09/06/09 00:07:04 ZW6/2JYO
>>294
むか～しpanicした時にやられた。
その後HDDがお亡くなられてしまったので、ext2関係無いような気もするが。
lost+found送りは何回か経験したが、中身壊れたのはその時だけかなあ…
299:login:Penguin
09/06/09 01:54:47 tJjVNlck
>>294
逆にジャーナルはあっても困るものでもないし、あえてext2を選ぶメリットがほとんど無い。
/bootをジャーナル無しにしてて、カーネルやinitrdの更新中に停電やメモリのエラーで落っこちたら困るでしょ。
滅多にないだろうけれども、ごく普通にext3とかreiserfsを選んでいればそんなことも無く、わざわざext2を選ぶ価値が無い。
300:login:Penguin
09/06/09 09:09:10 B66inO7s
ファイル倉庫はNTFS-3gなんだけど、なんか問題ある？
301:login:Penguin
09/06/09 12:51:04 EElS/ahk
>>289
そもそもdosfsckはダメ文字が駄目
使うもんじゃねえ
>>294
何が聞きたいんだお前は
結論ありきの質問するならずっとext2使ってろ
302:login:Penguin
09/06/09 13:43:16 F4Aa68Pq
>>299 みたいな場合でもジャーナルがあれば信頼できるの？
ジャーナルの処理するのって、カーネル起動してからだと思うんだけど。
303:login:Penguin
09/06/09 14:24:49 21hDzqo6
データは、どんなファイルシステムを使っても、常に壊れる可能性があるから
バックアップするしか無い。
RAIDもジャーナルも、サービス停止を短かくする手段だと割り切ったほうがいい。
だから停電の時に、ext3よりデータが消える確率が少し高くて、fsckに時間が
かかることに目を瞑れるなら ext2 でもいいんじゃないかな？
304:login:Penguin
09/06/09 14:34:10 sqCmm0Bn
>>302
なるほど
それがgentooの/bootがext2な理由か
305:login:Penguin
09/06/09 14:50:45 Cu2mKnoj
>>302
journalingに対するsoftupdateの利点はこれだったのか
306:login:Penguin
09/06/09 14:52:51 YwKe1rPj
カーネルが機動していないときに/bootを更新するって、
誰が更新するの？
307:login:Penguin
09/06/09 15:00:14 ooupGcCv
/bootをext2にする理由は、そもそも領域が小さくfsckの時間も無視出来るし
書き込むこともほぼ無いのにlog領域を無駄にすることはない、というものだと思う。
今更/bootを別パーティションにする理由もあまり無いけどな。
308:login:Penguin
09/06/09 15:09:44 sqCmm0Bn
いつ気づくのかニヤニヤしながら見守るとしよう
309:login:Penguin
09/06/09 15:16:23 5EAlHPvm
>>308
精神病患者はおことわりします
310:login:Penguin
09/06/09 15:24:01 sqCmm0Bn
ext3でもinitrdの更新を注意深く実装すれば
壊れたinitrdを作ってしまう危険はほぼゼロに出来るだろうから
/bootがext3でも構わないのかもしれないな
のんきにGRUBにパッチ当てて/bootをext4にしちまうようなディストリは論外、と
311:login:Penguin
09/06/09 15:30:56 aE6XIpG1
>>306
地球の裏側の人がEF経由Iで電源が落ちてても書き換えます
312:login:Penguin
09/06/09 15:30:59 YwKe1rPj
なんだ。また奥なんとかさんが出張ってきてるのか。
313:login:Penguin
09/06/09 15:35:09 aE6XIpG1
ごめんEFIね
314:login:Penguin
09/06/09 15:37:55 8w8xYP9i
>307
いまどき/bootを分ける理由っていえば、まぁ、mdでRAID5以上の構成にする時に、
grubが扱える様に/bootだけRAID1で残す為、位かなぁ…?
315:login:Penguin
09/06/09 15:41:49 ooupGcCv
なんだ、そんなことを言ってたのかよ。どのみちinitrdが壊れてたら
ディスクドライバをロード出来なくてブート不可能なdistroがほとんどだろ。
initrdが壊れるなんてことはめったに起きないし、万が一起きてもCDブートして
復旧するのが一番楽。
ちなみにdebianやubuntuではext2もモジュール化されてるからext2にしたところで
何も回避できない。
316:login:Penguin
09/06/09 15:45:10 sqCmm0Bn
38点 (100点満点)
317:login:Penguin
09/06/09 15:51:32 ooupGcCv
>>314
使いたいかどうかは別として、grub2だとLVMでもmdのRAID5でもブート出来るんだよな。
318:login:Penguin
09/06/09 15:52:31 sqCmm0Bn
いや38点はあげすぎかな
ぜんぜん理解できてないから0点だ
319:login:Penguin
09/06/09 15:58:15 5EAlHPvm
ID:sqCmm0Bnのような精神病患者はこのスレへの出入り禁止です
320:login:Penguin
09/06/09 15:59:39 sqCmm0Bn
にゃにゃにゃ？
321:login:Penguin
09/06/09 16:02:14 ooupGcCv
なんだ、単なる基地外か。
322:login:Penguin
09/06/09 16:05:40 sqCmm0Bn
なんというゆとりっぷり
正解を教えたりせずヲチしててよかった
323:login:Penguin
09/06/09 16:09:35 8w8xYP9i
>317
ま、そこは今はまだディス鳥次第なところなんで、あえて触れなかったんだけども。
324:login:Penguin
09/06/09 17:27:53 CF3nPqAI
>>322
ただ煽りたいだけのシッタカ乙。
325:login:Penguin
09/06/09 21:27:27 Wh4lHMAS
>>303
> RAIDもジャーナルも、サービス停止を短かくする手段だと割り切ったほうがいい。
ジャーナルはそれで正しい。
が、RAIDはサービス停止を回避するだけで、一旦アレイ破損等で
サービス停止すると普通より復旧遅くなりがちだから、短くするってのは変だな。
まぁ細かいところだが。
326:login:Penguin
09/06/09 23:01:21 7z+U+qgq
ジャーナルが実際にDISKに書き込まれるまでのタイムラグってどのくらいでしょうか？
数日ということもあるのでしょうか？
普通に考えれば数秒程度ですむと思うのですが。
327:login:Penguin
09/06/10 02:11:58 cSxSGaGP
>>325
RAIDの修復なんてホットスワップで裏でやらせとくもんだろ
328:login:Penguin
09/06/10 02:36:58 YPL1CLam
>>327
303はサービス停止って言ってるし、デグレードじゃなくて本当に壊れたときの話だよ。
単なるデグレードじゃサービスは止まらないから、ホットスワップとかそういう話じゃない。
329:やんやん ◆yanyan72E.
09/06/10 02:37:43 Lo8HmaM8
>>327
そうでなくて、修復できない状態のことをアレイ破損というんだろ。
330:login:Penguin
09/06/10 02:47:36 3e0Ap7d7
またそういうことを
331:login:Penguin
09/06/10 02:50:34 WUC9iD6p
チョコつけ棒自重
332:211
09/06/10 08:24:07 nf6usjF0
みんな、どうもありがとうね
HDが今日届くことになって、とりあえず
32TBをxfsで、8TBを試験的にbtrfsで使うことにした
333:login:Penguin
09/06/10 10:25:07 tTYdjDBW
いったいどんなデータを置くのかが気になるぜ
334:あ
09/06/10 11:23:32 O1yGBX4O
助けてください！教えてください！
クロック周波数が2.0GHｚのコンピューターの１クロックの所要時間は（a）ns（ナノ秒）である。 （a）は？ またこのコンピューターである特定の命令を実行するのに要するクロック数が８クロックであるとすると、この命令の所要時間は（b）である。（b）は？
335:login:Penguin
09/06/10 11:30:17 9L54Bn6h
>334
> 助けてください！教えてください！
消えろ。
> クロック周波数が2.0GHｚのコンピューターの１クロックの所要時間は（a）ns（ナノ秒）である。 （a）は？
キス
> またこのコンピューターである特定の命令を実行するのに要するクロック数が８クロックであるとすると、この命令の所要時間は（b）である。（b）は？
ペッティング
336:login:Penguin
09/06/10 13:54:08 lIw6J/4l
>>334
これが釣りでないとしたら、おまえ、今から身体鍛えて土方になるしかないな。
割り算の出てくる仕事は無理だから。
337:login:Penguin
09/06/10 14:03:12 Q0NjRuO3
>>336
え゛っ ? 掛け算もあるよ
338:login:Penguin
09/06/10 22:09:01 YaTU6CRl
>>326
ext3の場合は
#define JBD_DEFAULT_MAX_COMMIT_AGE 5
となっているな。ext4も同じ。単位は秒
339:login:Penguin
09/06/11 19:09:35 qTTLr2eL
>>289
ちょっと古いけど視覚的に分かりやすい。とりあえずどうぞ
Linux filesystem benchmark 2008/1
URLﾘﾝｸ(www.t2-project.org)
Linux filesystem benchmark 2008/2
URLﾘﾝｸ(www.t2-project.org)
340:login:Penguin
09/06/12 03:31:00 3YbKAhkr
>>339
やっぱり、reiserfs が一番無難なんだよな。。。
Btrfsはやくきてーー
341:login:Penguin
09/06/12 06:43:21 M+7JEAro
ファイルサーバ立てるときはいつもReiserFSだな。
inodeが動的に生成できて数に制限がないFSって他にある？
実際、inode数が足りなくなることはないと思うけど、上限があるのって不安だから。
342:login:Penguin
09/06/12 06:48:38 6HYudZDo
そんなことが心配になるなら、容量に上限があったら、さぞかし恐怖でしょう。
領域を動的に生成できて容量に制限がないHDDを使うべきでは。
343:login:Penguin
09/06/12 07:43:39 bYqPKkVz
LVMは無視ですかそうですか
344:login:Penguin
09/06/12 08:44:37 dPgUga8b
>>342
ext2のときに
大きくないパーティションをデフォルトの設定でmkfsした場合、
そこをmail/newsのスプールに使ったりすると割とすぐ足りなくなった。
dump/restoreが必要だったから、余裕を持って多めに割り当てるようにしてたよ
>>341
reiserfs以外でも、jfs,xfsは動的だけど後は知らない
345:login:Penguin
09/06/12 11:43:54 A+DVffOK
>>342
inode数と容量のふたつの制限があるよりはひとつのほうがいいに決まってんじゃん。
346:login:Penguin
09/06/12 11:52:44 jFKs2ejL
どっかのおバカなOSの/var以外にinodeがあふれることなんてあるのか
347:login:Penguin
09/06/12 12:02:07 UYT/GpZC
>>341はいつものreiser厨
348:login:Penguin
09/06/12 12:17:27 cm5nbj5o
そういえば昔RH7.3の時代にlogrotateが延々と
ファイルを増やしまくってinodeを食い尽くす、とかいう
バグがあったなあ...
349:login:Penguin
09/06/12 12:32:15 NfXF6BAy
ファイルサーバのときは、inodeよりもディスクの利用効率的にreiserfsを選ぶ。
350:login:Penguin
09/06/12 12:40:33 So72KRDF
ちなみに2ch専ブラのログ置き場は何にしてる？
考えたがそんなに差は無さそうだったから使ってるxfsにブッ込んでる。
>>339
ファイルシステムマニアのみなさん、こういうの日本語でやってほしいです。
351:login:Penguin
09/06/12 18:57:56 jFKs2ejL
>>348
URLﾘﾝｸ(bugzilla.redhat.com)
具体的にどの Bug# ?
352:login:Penguin
09/06/12 19:30:00 cm5nbj5o
>>351
これ
URLﾘﾝｸ(bugzilla.redhat.com)
単なる設定ミスといえばそうだが
353:login:Penguin
09/06/12 19:42:27 jFKs2ejL
>>352
やっぱりそれか。懐かしいな。sambaのlogで悩んだでたよ。
幸い /var が溢れる事態にはならなかったが。
354:login:Penguin
09/06/13 14:48:00 JubTxWA6
NILFSがlinusツリーにmargeって、GC問題は解決したのか？
GCさえ解決すれば非常に有望なfsの気がするけど。
355:login:Penguin
09/06/13 15:42:58 KIjTPhhe
>>354
GCがないのは問題ではなくて機能なのでは？
356:login:Penguin
09/06/13 16:14:31 SIDWa3ow
>>354
mergeは安定して使えるようになった事を意味しない
＃ところでマーガリンがどうしたって？
357:login:Penguin
09/06/13 16:43:01 aU2xhACg
>>355
「NILFSはGCがない機能があります。」
どう考えてもオカシイだろ。
358:login:Penguin
09/06/13 20:47:48 d4XO7s9x
NILFSにはGCという機能がありません。
だろ。
359:login:Penguin
09/06/13 21:19:57 KIjTPhhe
GCがないかわりに
過去のファイルをすべて保存しておく機能がある。
お前ら、頭が固いんだよ。
360:login:Penguin
09/06/14 11:27:38 INSOMoqp
結局「GCがない」は機能じゃない
それが問題かどうかは知らんが
361:login:Penguin
09/06/14 12:23:02 3MGoAqsu
ていうかmergeされたのはNILFS2であってNILFSじゃないんだが
362:login:Penguin
09/06/14 12:26:05 SExX3BMV
NILFS2はGCあるよな。3月にGC周りのバグフィックスとかもしてるし。
まあ使ったことないからどんな程度なのか分からんが。
363:login:Penguin
09/06/14 23:06:54 rQwfo9s3
ext4で透過的圧縮が使えないことを知った
絶望した
364:login:Penguin
09/06/18 23:56:35 ioEeQc9O
ext4でもまだファイル名255byteなんだよね。NTFSは255文字なのに。
日本語のファイル名をUTF-8で格納すると、入って85文字程度だしな。なんとかならんの。
ファイルサーバーをlinux+sambaに移行しようとしたらこのざまだぜ。
365:login:Penguin
09/06/19 01:27:45 Xfeqptff
vfsレイヤの問題
366:login:Penguin
09/06/19 10:17:22 qN4LPkrl
>>363
fusecompress
367:login:Penguin
09/06/19 19:17:33 eTXARmpf
>>364
そんな長い名前つけてどーするんだ・・・
368:login:Penguin
09/06/19 19:54:05 EeoS3mUJ
P2Pモノだと無駄に検索ワードが入ってたりするが
369:login:Penguin
09/06/19 22:25:00 w3Unrur6
>>367
メモとかw
370:login:Penguin
09/06/19 23:00:18 mnbKzcXv
結論
ext4は不要
btrfsの人柱たれ
371:login:Penguin
09/06/19 23:37:21 u8qVAw6f
そうは言うがbtrfsにも弱点はあるだろ？
372:login:Penguin
09/06/19 23:44:48 xpJPlhFx
>>371
遅いこと？
copy on writeの宿命な気がする。
373:login:Penguin
09/06/20 00:26:22 CdaCT9qt
>>367
プロジェクト通し番号+プロジェクト名+文書名+文書通し番号+日付+bakとかoldとかメモとか+拡張子
こういうふうなファイル名をつけると、UTF-8で255バイト越えがまれにある。
本当にファイル名にメモを入れる奴がいるから困る。
374:login:Penguin
09/06/20 04:14:59 pHcNf2hR
>>373
VCS使えよ
375:login:Penguin
09/06/20 09:13:33 bTbqwzKO
>>371
おまえがその弱点を修復していただければ幸いです
376:login:Penguin
09/06/20 13:18:15 xwPbisEm
外部ストレージ12T*3なファイル鯖立てる必要があるんだがファイルシステム何にしたらいいかな？(１ボリューム12TBで構築)
１ディレクトリに数KBのファイルを数十万個置く馬鹿がいたりしてext3は出来れば使いたくないんだけど。
(ls叩くだけで数十分戻ってこないとかになるし)
ちなみにOSは今のところRHEL5.2の予定なんでRHELで正式サポートしてる物で 速度より信頼性優先で考えてます。
自分一人だとSolaris10/zfsにするんだが Solaris不慣れなメンバが多くてRHELになりそうorz
377:login:Penguin
09/06/20 13:29:09 nE/nEMaI
正式サポートとなるとext3しかなかったような気がする…
転んでも泣かないのであれば他のも使えるが。
378:login:Penguin
09/06/20 13:35:29 pHcNf2hR
>>376
ext3より遅いzfsで問題ないならext3で良いだろ、と言いたいが12TBとなるとmax 8TBのext3は無理だ。
reiserfsかxfsをお勧めするが、サポートが欲しいならext4待つのが賢明かもしれない。
379:login:Penguin
09/06/20 13:45:57 43WBQfGz
>>376
Windowsにしろよ
380:login:Penguin
09/06/20 14:03:13 tISAQ4gm
>>376
ネットワークのFSは？ クライアント数は？ バックアップやスナップショットの必要性は？
381:login:Penguin
09/06/20 14:03:51 1JSai2FT
>376
> 自分一人だとSolaris10/zfsにするんだが Solaris不慣れなメンバが多くてRHELになりそうorz
素直にSolaris/zfsで組んでBrandZでRHE入れて公開とか。
382:login:Penguin
09/06/20 14:15:43 uTlYo/UV
SSD & btrfs(CoW)の組み合わせが最高
お互いの欠点を補い合い、長所を最大限に発揮する。
って何となく思った。だいたい合ってるんじゃないかな。
383:login:Penguin
09/06/20 14:17:11 43WBQfGz
Linuxとかなんかのジョークだろ
384:376
09/06/20 15:02:52 xwPbisEm
>>377
ReiserFS, XFSあたりってサポートしてなかったのか...
SuseでReiserFSにするならSolarisのほうが馴染みがあるし悩むなぁ
>>378
ext3 16TBまでサポートってRHEL5.0でテクニカルプレビュー、5.1以降で正式サポートじゃなかったでしたっけ？？
>>379
windows嫌い（ぉ というか telnet/ssh踏み台やら適当にscript走らせてるのでwindowsは...
>>380
NFSで繋ぎにくるのは２ユーザのみ。あとはftpで毎日400GB程度受信、300GB程度送信かと。
スナップショット不要でバックアップは毎日別鯖にrsyncの予定。
>>381
それは悪くないかもしれないですね。 Dell鯖だとSolaris正式サポートしてるし(キモイけど)
あまりDellは好きじゃないけど MD3000が安すぎて他の選択肢が存在しない(苦笑
385:login:Penguin
09/06/20 20:34:34 9xybmBgQ
>>384
これのことだすな。
URLﾘﾝｸ(blog.livedoor.jp)
386:login:Penguin
09/06/20 21:10:26 1JSai2FT
TBオーダーになると、本質的にfsck前提のfsじゃ運用がきつすぎるって……。
387:login:Penguin
09/06/21 01:56:50 x1fahonI
ext3って巨大ファイルの rm は遅いけど、大量ファイルの ls って、そんなに遅かったっけ？
388:login:Penguin
09/06/21 09:22:02 jR2Jwv49
>>367
ファイル名をつけないで内容の冒頭をファイル名にするといった
使い方が登場してるからね。
日本語ファイル名と同じで、なんやかんや言われるけど、そういう
使い方に一定の利点があることは確か。
389:login:Penguin
09/06/21 10:07:45 62ulX/zJ
>>387
2.4のころはすげー遅くなった。
最近は大丈夫なはずだが、そういう所はreiserfsにしてしまったので
実際どうなのかわからん。
390:login:Penguin
09/06/21 10:40:32 eb5/k6A8
ext4の使い心地や速度や信頼性はext3と比べていかがですか
何も変わらないですかそうですか
391:login:Penguin
09/06/21 11:27:48 LXWNEUWq
btrfsの使い心地や（ry
おまえがやれですかそうですか
392:やんやん ◆yanyan72E.
09/06/21 12:50:30 qnAMuU8X
ちょっと前に2.6.29のbtrfsで4つほどのディスクを結合して
一つのファイルシステムを作ったら、2日後ぐらいに
エラーだしてアクセスできなくなっていた。
今はそのぐらいの信頼性だということで。
393:login:Penguin
09/06/21 13:46:30 kS8xrTW4
>>392
btrfsの信頼性が低いのは分かってるので、
体感性能をレポートしてくれるとありがたい。
394:login:Penguin
09/06/21 15:06:25 eb5/k6A8
速くて怖くて臭い
395:login:Penguin
09/06/22 00:58:40 WFQSRo3G
>>390
挙動はかなり良い
スムーズ
信頼性ではまだメインでは使えないだろうな
396:login:Penguin
09/06/22 19:27:52 /UtaE34c
>>395
それは楽しみだな。
397:login:Penguin
09/06/23 00:26:31 +00i5bOt
>>395
ちょっと前に、getblkに排他入れるの忘れてた。なんてパッチが流れてて、底をどうやって忘れることががが・・・
と衝撃を受けたのは記憶に新しい
398:login:Penguin
09/06/25 17:31:23 moRwwRW2
btrfs
最高！
て言えるの、一体何時頃？
399:login:Penguin
09/06/25 20:10:17 KBIp5JGO
>>398
こんどの土曜日の午後２時頃
400:login:Penguin
09/06/26 02:04:24 F/JYcXGB
>>398
FreeBSDでzfs最高！って言えた後。
btrfs 再考！なら Sun買収の今ならあり得るかと。
401:login:Penguin
09/06/26 19:05:10 PoKFzBk0
URLﾘﾝｸ(uyota.asablo.jp)
95%を過ぎる頃からパフォーマンスが落ち始め、97%を越えた辺りからファイル操作が劇的に遅くなり
99%を過ぎる時には非常に醜い事態になる。って・・・・・
この人、本気でこんな事言ってるのかな
俺は某アルファブロガーさん程ZFSマンセーじゃないけど、
いちゃもん付けるにも程があるだろ・・・常識的に考えて
というか、対比としてUFSを挙げてるけど、実体験として5%ぐらいまでなら問題は無く、って事は
予約領域が8%で、そこを5%も侵食したって事で、要するに97%使用してるって事だろ？
FATのようなファイルシステムならまだ分かるけど、i-nodeやB-treeベースのファイルシステムで
空き領域が3%しかない状態なのに、性能を落とさず使えるもんなのかね
UFSを97%も使った事の無い俺には信じられないんだが・・・・・
＃ 昔、エロ目的でニュースサーバ構築しようと、80GB×5をまるっと1スライスで
＃ /var/spool/newsにマウントして使っていた頃は、%iusedが10%未満の状態ですら
＃ 40～50GBを越えた辺りから重くて使いものにならなかったのに
＃ UFSはいつの間にそんなに出来る子になったんだ？
402:login:Penguin
09/06/26 19:34:11 JYpSTooM
>>401
使用率90%以上のパフォーマンスダウンなんかだれも気にしないよな。
残り数パーセントを活用できたからと言って魅力はない。
それよりも、巡航時の性能の方が何倍も大事。
403:login:Penguin
09/06/26 19:54:54 NOfzkfFo
>>401
zfs quotaかけて制限ぎりぎりまで書き込もうとすると
かなりパフォーマンスが落ちるのは経験した。
そもそもCoWを高速化するためかなりメモリを使って
ディスクへの書き込みを遅延させて
実際の書き込みを削減するようになっているが、
残りが少なくなるとこの仕掛けが使えなくなり
頻繁にCoWの書き込みが発生してパフォーマンスが落ちるようだ。
（あくまでも推測です。ソースは読んでいません）
404:login:Penguin
09/06/26 20:49:12 mF9+I+S5
root予約領域の確保はほしいかも。
405:login:Penguin
09/06/26 22:44:47 O4vFMWYa
>402
今さっき、Solaris10 5/9で
# mkfile 1g /data/1G1 /data/1G2 /data/1G3
# zpool create tank raidz /data/1G1 data/1G2 /data/1G3
して作ったエリアに100Kずつmkfileでファイルを作ってくスクリプトをまわしたけどさ、
あっさりとAVAIL 0%まで突っ走ってしまったなぁ。
つーか、どういう運用であれエリア全部を使い切ってしまうようなら
管理者の無能を証明しているだけって気がするけどな。
406:login:Penguin
09/06/26 23:33:31 fjH2S1/1
HDDが1Tとすると、10%で100Gあるからなぁ
100Gあれば、まだ十分使えると思ってしまうのが普通だろ
407:login:Penguin
09/06/27 01:03:16 xSWgaNVh
>406
> 100Gあれば、まだ十分使えると思ってしまうのが普通だろ
それは試してみたかい?
俺が自分でpoolサイズをいくつか変えて試した感じでは、少なくとも遅くなるケースってのは
poolサイズの何%以下って動きじゃない。
1Tプールで残り100Gのところに99Gのファイルを作ろうとすると途中で遅くなるだろうが、
50Gのファイルならたぶん普通に作れる。しかし残りが100Gで既に存在する50Gのファイルを
同じファイル名で書き換えるなら引っかかるかもしれない。いずれの場合でも当該プールへの
アクセスが重くなるだけで、CPU負荷が増えるとかは一度も遭遇していない。
件のblogは「普段よりシステムが二、三倍ぐらい遅くなっているのに気がついた」とか書いてる
みたいだから、たぶんルートファイルシステムで空きがなくなるまでやってたんだろうな。
そこらへんの切り分けも出来ていないみたいなのはお粗末だとは思うが、まぁ、そんなもんだろ。
408:login:Penguin
09/06/27 09:48:01 9F/Mxzcj
>>405
ということは、遅くなるのは断片化の影響？
409:login:Penguin
09/06/27 17:37:41 CPmpdLib
>>406
おまえだけだろ。
410:login:Penguin
09/06/27 19:41:30 k4AyL1vK
HDDが1Tとか残り100Gとか、ダウソ板に居るのかと勘違いしたじゃないか
411:login:Penguin
09/06/27 23:36:47 sRzpWWk6
そりゃ管理者≒ユーザーなら残り容量も管理できるだろうさ
412:login:Penguin
09/06/28 00:14:38 PkMOJr/+
管理者とユーザーが同一人物じゃなければリソースの管理もできない管理者って、
なんのジョークだ?
413:login:Penguin
09/06/28 00:27:12 mHUBrjQ8
年金ジョーク
414:login:Penguin
09/06/28 09:46:19 rA+Z+0As
おまえらは黙ってbtrfsを使え
俺はreiser4を応援する
415:login:Penguin
09/06/29 15:29:26 EwMZtCko
[Phoronix] EXT4, Btrfs, NILFS2 Performance Benchmarks
URLﾘﾝｸ(www.phoronix.com)
416:login:Penguin
09/06/29 21:36:30 E54LAahb
狭い領域 そんなに急いでどこへ書く
417:login:Penguin
09/07/01 07:11:15 pFEUrnAn
途中までNILFS面白くね？と思ったが、Threadedのテストで酷いことにｗｗｗ
ロックがうまく捌けてない？
418:login:Penguin
09/07/01 19:06:34 VcKgLPIK
起動・システムパーティションにxfs使ってて、
uswsuspでs2diskしている途中なんかで無理矢理電源断すると
次回リブート時にxfs_repairしなか起動しなくなるんだけど、
これs2disk中以外の普通の突然の電源断では起きないのかな？
実マシンじゃ恐くて試してないけど、vmware上じゃあれこれ書き込んでる最中に
電源落としても大丈夫みたいだけど。
419:login:Penguin
09/07/01 20:27:43 rmCahXvL
>>418
ルートファイルシステムをXFSにして数年経つがxfs_repairなんて使ったことがない
420:login:Penguin
09/07/01 20:30:41 IqsTXi/V
ひさびさにXFS厨発見
ここから３０レスくらいアンチが埋め尽くすはず
421:login:Penguin
09/07/01 20:41:09 rmCahXvL
はいはいNGID
422:login:Penguin
09/07/01 20:42:27 T/tn+uoR
アンチが付くほどユーザ多くないだろ > XFS
423:login:Penguin
09/07/01 20:47:18 VcKgLPIK
>>419
その間突発的な電源断とかは？
s2disk中に電源落とすと再現できるかもだけど恐いからやれない。
s2disk中以外の電源断ならそのままリブートできるんなら自分的には問題ないけど。
424:login:Penguin
09/07/01 20:55:42 rmCahXvL
>>423
自宅なんで停電で落ちることもあるしoopsで固まった事も一度や二度じゃない
XFSの信頼性そのものは怪しいと思っているが、
xfs_repairしないと起動しなかったなんて経験は無いな
425:login:Penguin
09/07/01 20:58:34 UZTOndbd
>>418
ID:rmCahXvLじゃないけど。
俺がXFSを/で使っていた時の話だが、何事もなかったように立ち上がってきたぞ。
指輪物語の再生中でスクリーンセーバー切ったりとかついでに電源ケーブルも切ったりして
つい、バッテリー切れ起こして突発的に電源断しちまったんだな。
426:login:Penguin
09/07/01 21:00:10 VcKgLPIK
>>424
サンクスです。とりあえず今インスコ中のpcはまるごとxfsにすることにしました。
427:login:Penguin
09/07/01 21:17:55 Y9xsHfht
XFSﾏﾝｾｰ
428:login:Penguin
09/07/01 21:18:56 RgnVHoSx
皆さん人柱乙です
URLﾘﾝｸ(www.atmarkit.co.jp)
> 相変わらず、ext4のバグのペースはすさまじいものがあります。
429:login:Penguin
09/07/01 23:41:21 dnXeAx3U
>>415
使い方によって、FSでここまで差が開くってのは面白いね。
パフォーマンスを追求するのなら、
どのサービスを提供するかでFSを変えた方がいいってことか。
430:login:Penguin
09/07/01 23:44:39 aKLpib1z
>>429
フォードに車種が沢山あって目的に応じて選べるのと同じだね
431:login:Penguin
09/07/01 23:47:12 dnXeAx3U
>>417
シーク時間の影響かも？
今後、SSDが普及していくとしたら、複数スレッドからの同時アクセスでも問題なさそうね。
432:login:Penguin
09/07/02 00:00:29 6CzpStJa
ちょっと古いけど、POHMELFSのベンチマーク
URLﾘﾝｸ(tservice.net.ru)
NFSよりだいぶ早いわ。
小さいファイルを大量に扱うクラスタファイルシステムとしては、今後に期待できるのかも。
主な用途は画像共有サーバ、メールサーバとかか。
433:login:Penguin
09/07/02 20:46:34 rU1W47g5
XFS厨の特徴
・Linux Kernel Version2.6.17～2.6.17.6の時に何かあったのか思い出せない、しかし初期のReiserFSの不具合は今だに覚えている
・xfs_repair & xfs_checkが1TBにつき、およそ1GBのメモリを要求するのはアンチの流したデマだと思っている
・XFSのジャーナリングが、ext[34]で言う所のdata=writeback相当品だというのもデマだと思っている
・ext[34]のdata=writebackは極めて危険だが、XFSのジャーナリングは問題無いと思っている
・カーネル標準のVFSを介さないのでXFSは素晴らしい、そしてVFSを介する他のFSは糞だと思っている
・突然の電源断や、システムダウンでもXFSが壊れた事は無いと主張
・O_SYNCや、O_DIRECTでファイルオープン中に電源が落ちても、ファイルがヌルバイトに切り詰められるなどありえないと思っている
・O_SYNCや、O_DIRECTでファイルを開きっぱなしにしておくなんて、RDBMSであろうと行儀の悪い事だと思っている
・バカでかいRAIDアレイで、しかもあえてワンパーティション運用していてもノートラブル
・LVMやMDと一緒に運用していても勿論ノートラブル
・xfs_fsrをcronで毎日ブン回そうがノートラブル
・Unknown error 990なんて当然見たことも無い
・トラブルが起きないのでfsck.xfsだけで十分だ
・xfs_repair or xfs_checkなんて使ったこともない
・FSの性能比較などでXFSの結果が奮わないとデマだ、やらせだと大騒ぎする
・やたらと「次に使うFSを何にしようか」と聞いてくる、そしてどんなFSを勧められても結局「XFSにしますた」で終了する
434:login:Penguin
09/07/02 20:49:21 JUQuwRcW
何か仕事で辛いことがあったんだろうか・・
435:login:Penguin
09/07/02 20:55:14 hrym764a
そっとしておいてあげて。。
436:login:Penguin
09/07/02 20:56:46 S0MAGDAx
とりあえず確かなのは
おまえがアンチだということだな
437:login:Penguin
09/07/02 22:16:21 as0GGArF
>>433
英訳して本家スラドにタレこむと面白そうだな。
それはいいとして、その調子でJFS厨やReiserFS厨、Ext3厨の批判も頼む。
438:login:Penguin
09/07/02 22:17:16 Hm4AKlRl
LinuxのJFSって全国で3人ぐらいしか使ってないだろ
そのうち1人は俺な
439:login:Penguin
09/07/02 22:17:33 C87ApF+T
もう1～2年前の話になるが、
luksで暗号化したHDDの上にnilfs2を構築して使ってたら
約5秒ごとにファイルシステムに書き込み(？)が発生して、nilfs2のcpが5秒ごとに作られてた。
luks使ってないHDDだとこういう事は無かった。
今は余ってるHDDないから試せないんだが、まだ変わらないのかな？
440:login:Penguin
09/07/02 22:47:23 as0GGArF
ReiserFS厨の俺がReiserFS批判すると
・起動時間を競う今にマウントが桁違いに遅い
・BKLが残っててBKL使っている他の部分の速度を下げる
・早いのはいいが、CPU負荷も高い
・一日の長長しかなく、CoW使った次世代FSに速度を抜かれる運命
・開発者あぼーんで将来性が無い
こんなとこかな。ext系の独自機能への対応具合とか、技術的に詳しい人の批判が欲しいなぁ。
441:login:Penguin
09/07/02 22:56:17 kVxArKzn
途中でめんどくさくなってやめた。改めて見ると俺の英語力終わってるな。
”How should I talk with anti-believers in peace?"
One of my friend is an XFS-hater. He often retails bad-talkings
about XFS with neither verification nor evidence. He says that:
"All of XFS users are believers. They make an effort to forgot
what happened on 2.6.17-2.6.17.6 kernel, though, maintain
memories of early ReiserFS's issues."
... How should I talk with him in peace? Do I have nothing to do
except for gracious neglect?
442:login:Penguin
09/07/02 23:24:22 as0GGArF
How do you think about XFS? Recently, my friends talk about XFS-believers peculiarity. He would think "XFS is poor and its believers are foolish!". His opinions are here:
- ...
I doubt his opinions are truth. Please give me your opinions for his discussion.
443:login:Penguin
09/07/02 23:27:25 m2mL2E34
ファイルシステムには人の精神を狂わせる何かがある
444:login:Penguin
09/07/02 23:47:50 yfRomf3o
>>438
Ubuntuインスコ時にたまたまリストに出てきたから、で選んだ奴がもう3人くらいいるだろ多分
445:login:Penguin
09/07/03 02:36:47 uBL2xlI5
ファイルシステムというよりLinuxカーネルの安定性に激しく疑問を
持つようになってきたこの頃。
テストしているのか？レビューは？ビルドしてみたか？というような
体制側の問題と、新しいデバイスが出るたびにちょこちょこと出てくる
ハード側も絡んだ不審挙動があいまってうんざりすること多々。
最近より鉄板なWindowsServerに乗り換えようかと手を出しつつある。
何で俺がWindows鯖なんかに・・・
446:login:Penguin
09/07/03 02:54:39 ZPir+zN3
>>445
ええと、新しいデバイスならドライバも新しいわけで、当然バグもあるでしょう。
これはOS関係ないし。
鯖運営するんなら枯れたハードを使い、
そして最新のカーネルなんか選択しないと思うんだけど。
447:login:Penguin
09/07/03 12:38:51 pNxOnErm
ヒント：心の安定
448:login:Penguin
09/07/03 12:49:59 TiU7uWgl
ま、どのOSに乗り換えたって不満は出るんだけどね。
449:login:Penguin
09/07/04 10:06:32 oKHh/wD5
>>448
ただ、その程度の差は大きい罠
450:login:Penguin
09/07/04 13:04:03 aCWGVCOu
>>449
精神状態が不安定なだけ
451:login:Penguin
09/07/04 13:27:19 dWON3uVd
>>446
RHELやそのクローンって安定してる？
2.6.18というずいぶん古いカーネルだが
452:login:Penguin
09/07/04 13:42:05 aCWGVCOu
また不安定者か
453:login:Penguin
09/07/04 21:02:41 4I7qogug
結局Linuxでこれで鉄板ってFSってなんなの？
454:login:Penguin
09/07/04 21:21:15 epSeSByy
ext2
455:login:Penguin
09/07/04 22:16:50 c9qNSKKi
正解が必ずあると信じているのもゆとり世代の特徴
答はひとつと思い込みやすいのもゆとり世代の特徴
456:login:Penguin
09/07/04 22:35:48 lf/ENdM4
ゆとり世代で一括りにするのが
ゆとり世代じゃない真性ゆとりの特徴
457:login:Penguin
09/07/04 22:57:12 ueczLvj9
Linux板の平均年齢知らないのか？
おっさんは引っ込んでろ。
458:login:Penguin
09/07/04 23:16:29 B4QSauY5
どのlinuxディストリでも扱えるという点でext2かext3だな。
でかいアレイを扱うのは向いてないけどさ。
459:login:Penguin
09/07/04 23:20:22 c6siemrW
reiserfsのほうが良くないか？
460:login:Penguin
09/07/05 00:29:49 fbkB0Uiv
何がどう良いのか説明してくれ
461:login:Penguin
09/07/05 06:44:40 PXK9xHrV
XFS には、何度も煮え湯を飲まされた。 Linux 2.4 シリーズではいくらか実績があり、
一度 Linux 2.6 にしたマシンも 2.4 に戻して様子を見ていたが、結局 apt-get upgrade
でのパッケージのアップデート中や何かのタイミングで
Jul 7 01:41:45 db kernel: xfsforceshutdown(md(9,0),0x8) called from line 1086 of file xfs_trans.c. Return address = 0xf891c9eb
Jul 7 01:41:45 db kernel: Filesystem "md(9,0)": Corruption of in-memory data detected. Shutting down filesystem: md(9,0)
Jul 7 01:41:45 db kernel: Please umount the filesystem, and rectify the problem(s)
などと言い残して死んでしまうのであった。
でも、ext3 はどうなのよ? 伝聞によると、ジャーナリングなファイルシステムのくせに、クラッシュ後の
復旧処理でファイルシステムを壊すこともしばしばらしい。データセンターなので、長期の連続稼働で
不具合がでなければ問題ないのだが。
ほかのは… ext2: fsck 捨て。 JFS: 実績を聞いたことがないので敬遠。 ReiserFS: Linux 2.2
の時代に好んで使ってたが、ハード不良によるクラッシュ後の復旧でファイル消失したので捨てて、
その後に XFS に乗り換えた。長期運用では問題なさそうかも? Reiser4 はどうなんだろう?
色んな人の経験談や奥山さんの話を聞くにつけ、 Linux のファイルシステムはどれもダメなのかも。 Debian GNU/kFreeBSD でも試してみようかしら。
URLﾘﾝｸ(www.sfo.jp)
462:login:Penguin
09/07/05 08:42:28 PWp2gMGR
・伝聞によると
・らしい
・聞いたことがないので
・はどうなんだろう?
毎度必死過ぎて哀れを催すな。
463:login:Penguin
09/07/05 09:19:24 l701u5w+
おまいらにext3なんていらない
紙で充分さ
464:login:Penguin
09/07/05 09:42:17 mGEXPAo2
solaにゃんはだめなん？
465:login:Penguin
09/07/05 09:53:33 0pLzbEyN
>464
linux側だけの都合でlinuxに入らないものは悪みたいに思ってる人が結構いるから
きっとダメなんだろ。
466:login:Penguin
09/07/05 13:37:01 7/LltY/L
>>461
ハード不良でファイルが壊れるのは当たり前。raidでも使え。
467:login:Penguin
09/07/05 14:55:23 fQomHEI3
solarisのufsですが、どうもファイルシステムが壊れてしまったようです。
fsck でやると BAD SUPER BLOCKとでます。
エラーメッセージどおり、 newfs -N で代替スーパーブロックを探して、
でてきたスーパーブロックを指定して fsckやってもだめでした。
このような状態で、壊れたファイルを取り出す方法ってありますか？
468:login:Penguin
09/07/05 15:07:31 0pLzbEyN
>467
別に保管しておいたバックアップから戻す。
469:login:Penguin
09/07/05 20:18:24 p3GlOS2H
>>438
もう一人は俺。
/boot も JFS。
470:login:Penguin
09/07/05 21:23:59 ugjukesl
>>461
また奥山信者か
471:login:Penguin
09/07/05 23:02:10 J3bViw4a
>>465
Linux板で言われてもなぁ
ネガティブキャンペーンしたかったら少なくとも対比させてくれないと
そうで無いならUNIX板で
472:login:Penguin
09/07/06 14:00:48 76F9p4oQ
>>461
ext3いいよ。
クラッシュ後の復旧処理でファイルシステムを壊すことは無いし。
473:login:Penguin
09/07/06 21:03:00 vzyNkkoh
実ファイルが壊れるのが嫌ならnilfs2しかないのでは？
あれって実ファイルも保護されるんだろ。
外付けhddのfsがjfsだわ。
これで三人出揃ったかな。
474:login:Penguin
09/07/08 16:19:42 np245sVF
ext4の話題なし
475:login:Penguin
09/07/08 16:24:50 WUnZg/ty
reiser4を潰すために祭り上げられただけだからな
476:login:Penguin
09/07/08 20:48:20 FF8V0Gi/
Hans Reiserは、Linuxのファイルシステムに重要な貢献をしたが、
犯した罪は許されるものではない。
Linuxの歴史から抹消すべき人間なのでしょうか。
おまえらはどうお考えですか？
477:login:Penguin
09/07/08 21:16:15 jn2DkYfU
冤罪の可能性も・・・と言いたいところだが、司法取引しちゃったんでしょ。
478:login:Penguin
09/07/08 21:23:00 e+Y75R6E
司法取引で「遺体の場所ゲロったら刑を軽くしてやる」って言われて
ちゃんとそこで見つかったんじゃなかったっけ？
事実関係としては言い訳の余地なしだと思うよ。
情状酌量とか心神喪失とかはあるかもしれないけどね。
479:login:Penguin
09/07/08 21:29:38 t+wEbQ0Z
>>476
犯した罪は、Linuxのファイルシステムへ重要な貢献をかき消すものではない。
罪は罪、貢献は貢献。
それぞれ別々に扱え。
480:login:Penguin
09/07/08 21:33:08 XG1lAIaP
で、実際の所reiser4の現在のメンテ状況はどうなの？
481:login:Penguin
09/07/09 00:15:47 ztD5Pcm3
そんな事よりお前らの精神の健康が心配だよ
もとからあまり良いとは言えないのに
482:login:Penguin
09/07/09 00:56:41 /Q5asfJ/
>>474
ext4、まだまだ安定しないだろうね
Ubuntu9.04 ext4領域でbonnie++を実行するとOSがフリーズ
URLﾘﾝｸ(forums.ubuntulinux.jp)
483:login:Penguin
09/07/09 21:25:03 IWhYPriW
>>476
そりゃ、あからさまに間違った考え方ですな
484:login:Penguin
09/07/10 02:07:31 QSzdrBX1
貢献と犯罪・不名誉は別だろ。
古の微妙な例としてチューリングとか、ショックレーとかもいるし。
485:login:Penguin
09/07/10 11:07:35 nZxN7MAV
もうext4上にシステム組んじゃいましたっ！＞＜
486:login:Penguin
09/07/11 08:13:07 cmFWuOE8
ext4は千代に八千代にさざれ石の巌となりて苔のむすまで
487:login:Penguin
09/07/11 17:53:21 dw+R0cpX
God save our gracious FAT,
Long live our noble FAT, God save the FAT:
FATは永遠です。
488:login:Penguin
09/07/11 18:30:45 eY3grqUq
ええと、「神はFATに保存します」？
だから神が作った世界はこんなに
無駄や矛盾が多いのか。
489:login:Penguin
09/07/11 20:20:56 Im61ZZa+
>>487
やせなよw
490:login:Penguin
09/07/12 00:47:34 iD0Q34UO
Who's BAD
491:login:Penguin
09/07/12 07:34:07 iJiMLxYq
SEXFSってないの？
492:デムパゆんゆん
09/07/12 14:34:34 9nVuXLh1
>>490
パタリロ
493:login:Penguin
09/07/12 15:13:33 LtgRYUdo
>>491
ページ中央辺り
URLﾘﾝｸ(www.stanford.edu)
SExFS is a Semantic Extensible File System written in Python for Posix systems.
SExFS allows users to display files and information as an NFS filesystem,
with arbitrary file and folder names and contents. We have created several sample filesystems--
a calculator and a Flickr browser--to highlight the power and possibilities afforded by semantic filesystems.
Our flagship filesystem, however, is based on MySQL and allows users to browse media files based on their metadata.
Users can write new plugins to index files with metadata (photos, mp3's, ogg, etc.)
and can query their media libraries with a familiar command-line graphical folder-based environment.
494:login:Penguin
09/07/12 15:37:02 iJiMLxYq
>>493
豚
スタンフォードって楽しそうな大学だね
495:login:Penguin
09/07/13 18:08:11 16CQwfq3
ocfs2のサイズ変更ってどうやるの？
496:login:Penguin
09/07/15 00:28:40 xHza5ZRW
>>493
エロ動画のストレージに良さそうである
497:login:Penguin
09/07/15 10:32:13 Vdbxg4WB
一度使用しちゃうと果てちゃう…
498:login:Penguin
09/07/15 11:07:26 Mku6OjmN
逝っちゃったら困るな
499:login:Penguin
09/07/15 20:39:16 F/Ek3+WF
俺はすぐに果てちゃうから使わないほうがいいな
500:login:Penguin
09/07/16 00:04:24 GRWkU8Qh
英語なら come だから問題無い
501:login:Penguin
09/07/16 01:05:00 FlV1gCaO
英語といえば米でなく英
502:login:Penguin
09/07/16 06:27:55 BwdqRtQE
しばらくすれば自動回復するんだろ？
503:login:Penguin
09/07/16 18:38:28 ucvU0Ata
>>502
fsckすればするほどクラッシュの危険が高まるよ
504:login:Penguin
09/07/18 08:58:03 0IAjxnq5
ブロックアルゴリズムって時代遅れだと思いますか
505:login:Penguin
09/07/18 14:22:16 nOxMZ/om
古い手法だけど、それを完全に上書きするような手法が見つかってるわけじゃないでしょ
今はCPU暇だしな
506:login:Penguin
09/07/18 18:02:00 FXagXe+W
バイト単位でIOできる外部記憶が出るまでは
ブロックのままだろうなぁ。
それにしてもアルゴリズムを上書きするって言い方も新しいなぁ。
507:login:Penguin
09/07/18 20:27:29 1KHKmIMy
ＳＳＤの登場でむしろブロック依存は高くなるよ。
512byte単位のHDDに対してSSDは数十Kbyte単位になるから。
尤も、SSDもコントローラーによって512byte単位に見せかけているし
コントローラーの腕の見せ所でもある。
508:login:Penguin
09/07/18 21:33:00 7mIvsTn8
ちなみにSSDって何でそんなに内部のブロックサイズ大きいの？
チップのワード線とかカラム線当たりの記憶容量とかそんな事情？
509:login:Penguin
09/07/19 00:28:34 Ifg8bPkb
そうだよ。線あたりの容量が多くできるから大容量にできるわけで
510:login:Penguin
09/07/19 19:03:32 gKTPa9G2
bなんとかtreeのアルゴリズムでも
512byte単位は撤廃されないの？
511:login:Penguin
09/07/19 19:35:07 QnTN+OyJ
>>510
IOバスが512B単位のアクセスを要求しているから
PICex直結デバイスじゃないと512制限はなくせないだろう。
512:login:Penguin
09/07/19 20:57:12 LmnH9n3G
>>510
そのうち、HDDのセクタサイズが4Kに移行するから、事態はより悪化する
513:login:Penguin
09/07/20 06:00:54 ERQWb2xv
そのうち16バイトCDBとか言うのに移行するから
セクタサイズはそのままで良くなるんじゃねっけ
514:login:Penguin
09/07/20 11:18:37 jSHxxxDI
>>513
4K移行はむしろSSDからの要請
515:login:Penguin
09/07/21 03:27:28 f3V8GfSz
momonga6はbtrfs,nilfs2,reiser4が選択可能になったらしいが
516:login:Penguin
09/07/22 05:04:57 tKK3MQC8
まあ、Fedoraよりもさらに不安定を目指すmomongaだし。
517:login:Penguin
09/07/23 20:47:27 B7TBWA5b
JFSの何がいけないのか未だにわからん
きっと将来、NILFS2あたりも理由なく叩かれるんだろうな
まわりはみんなbtrfsだよ・・・という日本人らしい発想でな
518:login:Penguin
09/07/23 21:13:46 TAblAX+g
/bootだけext2にしてるがあとは全部JFSでなにも問題ないよ
519:login:Penguin
09/07/24 01:09:55 Ym8Z1KGq
btrfsはいつモノになるのか、そもそもOracleはモノになるまで放り出さずに
続けるかどうかも分からんってゆーのが最大の不安要素だな。
ぶっちゃけ、linuxでもzfsが使えれば今さらbtrfsでなければって要素も
ないから、OracleがSunを手に入れた以上はbtrfsの将来性はreiserfsの
次くらいには不安かな。
520:login:Penguin
09/07/24 03:12:27 X5f+VhgR
JFS使ってるけど、ext3とかと比べるとやっぱり遅い
あと、断片化が進みやすい
SANみたいに、膨大なキャッシュとウェアリングが用意できるなら全然問題なさそうな気もするけど。
521:login:Penguin
09/07/24 07:04:40 8OIypDf7
JFSの断片化率ってどうやってみるんですか？
AIXとかならデフラグできるんだよね。
522:login:Penguin
09/07/24 07:33:51 MOU8Mq8R
いやいや、JFSは速いよ。特に最初だけは。
でも、そこからどんどん劣化してゆく。
原因は断片化なんだが、ext[234]とかReiserFSなんかと違って
JFSは空き領域が十分にあっても、使っているだけで断片化してゆくから
遅くて使えないイメージをもたれる。
元々のJFSはデフラグ出来たらしいが、Linuxには移植されていない。
断片化が進むといっても、流石に書き込みが発生しなければ断片化しないから
インスコ後は、Webブラウズと2ちゃんだけみたいな使い方なら、次のインスコ時位までは大丈夫でしょ
ってな事を、過去スレ その3辺りから、MLのアーカイブやOSS系のblogをソースとして、何度か指摘されて来たみたいだけど。
このスレには、どういう訳だか「俺のJFSは大丈夫」的な、JFS信者が居てそいつらの所為でイメージが悪くなっているのは確か。
因みに俺が使ってみた感想としては、3ヶ月程度の常用でもう遅さを実感出来た、Arch Linuxで使うには相性が悪いみたいだ。
523:login:Penguin
09/07/24 13:08:03 y4l15h2n
gentooで使ってるけど、まあ俺は大丈夫としか言いようがない。
524:login:Penguin
09/07/24 15:32:06 gHNTnF5y
よくいるよね、俺は大丈夫ってひと
525:login:Penguin
09/07/24 16:53:43 99ViSCNs
じゃあext3は最高ってことですね？
526:login:Penguin
09/07/24 21:39:12 D0YbIG0Z
XFSは耐障害性に不安があるが、デフラグが出来るので、長期運用に耐えるんだよね。
長く使っていると性能落ちてくるからな。
reiserfsにデフラグがあったらな。
実験レベルではいろんなファイルシステムを試してみても、
結局製品にはext3を使ってしまうが。
527:login:Penguin
09/07/24 21:51:18 xsQ+pNmK
zfsマンセーなんじゃない？
Linuxでも標準で対応してほしいな
528:login:Penguin
09/07/24 21:55:45 qlwn44yy
もうfuse経由で１回書き込むとext3/ext4/reiserfs/reiser4/jfs/xfs/btrfs/ntfs/ocfs/gfsに
それぞれ書き込んでいくような構成で使えよ。
それで数年間プロファイル取りながら使い続ければ自分の使い方での
優劣と信頼性はっきりするだろ。
529:login:Penguin
09/07/24 22:46:06 D0YbIG0Z
>>527
せめてfuse経由じゃなくなったら、試してみても良いんだがな。
530:login:Penguin
09/07/24 23:29:48 +FICJFrb
JFSそんなに遅くなるか?
具体的にどういう使い方でフラグメントで遅くなるのが体感できるの?
531:login:Penguin
09/07/25 00:01:04 6HQ5H67u
フラグメントなんて関係なく遅いよ
俺のエロ画像置き場をJFSにしてたけど
他のPCとrsyncでミラーするとext3に比べてもはっきり遅かったよ
今はxfsとext4でミラーしてるけどext4のほうが速いわ
532:login:Penguin
09/07/25 02:29:01 a8C1eZGa
>>530
JFSが特に遅いという訳じゃないけど、
長期間書き換えが続くと、どのファイルシステムも遅くなっていくよ。
AIXでわざわざデフラグ機能が用意されているのもそのため。
533:login:Penguin
09/07/25 15:09:16 SPBomRQY
>>519
Hammerのこともたまには思い出してあげて
534:login:Penguin
09/07/25 15:14:24 2k5R61Zs
遅くなるって、どの程度なのか定量的な資料がないんだよな。
大丈夫って話と同じく、遅くなるってのも
俺が、って話が多い。
ちなみに俺はJFS使ってても気になるほど遅さを感じたことはない。
IMAPメールサーバ用途。
535:login:Penguin
09/07/25 15:48:41 AmW3ipV8
JFS使ってるマシンで、postfix+dovecotをMaildirでつかってるけど、特に遅く感じません。
XFSはやっぱり、削除とかファイル作成が遅く感じる。
2つディスク用意して、XFS to XFSでrsyncするときとか、
ext3とかreiserfsでは感じないつっかかりを感じる。トータルでも遅い。
JFSでは同じことやったことないからわからん。
536:login:Penguin
09/07/25 16:13:50 lzFVun58
>>535
確かにXFSのファイル削除は遅いが、version 2 logにしてlogbsizeを増やせば
劇的に改善されるぞ。
537:login:Penguin
09/07/25 18:00:14 wdRQEHVW
俺のXFSは速いぜ
ext3なんて目じゃない
なぜって？
俺がXFSを愛してるからだ。
538:login:Penguin
09/07/25 22:47:52 2/7PSo3q
/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 28167/768544 files (3.9% non-contiguous), 1451870/1536207 blocks
Warning... fsck.ext3 for device /dev/sda1 exited with signal 11.
[root@hoge ~]#
fsck落ちてるｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
orz
539:login:Penguin
09/07/25 23:16:21 PLnhHNIh
バターさんｗｗｗｗ
540:login:Penguin
09/07/26 00:00:17 hBFHdbhU
>>535
そういうライトユーザには影響ないよ。
それに、長期間ヘビーに使うと遅くなるのは、JFSだけじゃないから、
別にJFSがダメといっている訳じゃないぞ。
541:530
09/07/26 01:55:52 wjhuvhRQ
で、JFS がフラグメントで遅くなるのが体感できる人は、具体的にどんな使い方で体感できたの? > 522
JFS が元々あんまり早くないのは周知だし、
JFSに限らずフラグメントで遅くなるだろう事も周知じゃん。
542:login:Penguin
09/07/26 01:57:49 wjhuvhRQ
>>540
具体的にどうゆう使い方なの?
543:login:Penguin
09/07/26 10:28:35 up8GAVd6
エロ動画置き場もXFSにしたら速すぎてワロタ
544:login:Penguin
09/07/26 10:31:58 3m7I2El9
遅くなったとか言っても具体的な数字が無いとわからないからさぁ、
ルールを決めようよ。
ファイルシステムを作成した時にbonnie++でベンチマークしておくこと。
遅くなったと感じた時には、bonnie++で再度ベンチマークすること。
パッチ当てて、よろしく。
URLﾘﾝｸ(plaza18.mbn.or.jp)
545:login:Penguin
09/07/26 11:22:18 UThMHETq
寝る前の快適な動画ライフにはXFSが欠かせません
546:login:Penguin
09/07/26 12:38:17 1L63znlZ
nilfs2はこのスレ的にどうよ？
547:login:Penguin
09/07/26 16:27:48 zE9g6p5d
何がいいのか誰か解説しておくれ。
微妙な良さだったら手を出さない
548:login:Penguin
09/07/26 16:41:13 Pgi1JFDo
linuxでバックアップがわりにスナップショットをとるなら
btrfsとnilfs2しか選択肢がなくて，btrfsとnilfs2を比べると，
nilfs2の方がだいぶ人柱度が低い．
549:login:Penguin
09/07/26 17:07:30 SJc9FADs
>>543
いままでの３倍速でいけてますか？
550:login:Penguin
09/07/26 22:56:52 hBFHdbhU
>>543
おまえの性癖すごいな。
>>549
それだと、1こすりと1/6じゃないか。
551:login:Penguin
09/07/27 15:26:20 1rnYRPHC
opensuseにreiserfsなんですが、
HDDアクセスすると妙に引っかかる動きをするのですが、
何かわかります？
552:login:Penguin
09/07/27 15:36:57 bemC+Vkx
reiserののろい
553:login:Penguin
09/07/27 16:13:10 26kfPdFl
dmesg で不吉なメッセージが出てなければいいね
554:551
09/07/28 12:07:29 9Q9PEzX+
エラーとかではなくて、PIOモードみたいなんですよね。SATAなのに。
555:login:Penguin
09/07/28 15:43:15 zAh/ZwBs
結局おまえらのハードディスクの大部分は
エロ動画やエロ画像を溜めてあるだけなんだろ？
そんなのXFSで構わん。
大きなデータが高速に読み書き可能
ばれそうになったとき急いで消せば復活が難しい
ぴったりじゃないか
556:login:Penguin
09/07/28 17:34:44 F7x9aH/R
>>554
$ hdparm -i （HDDデバイス）
でどのモードか、わかるやろ
557:login:Penguin
09/07/29 04:38:11 UAfxPrcB
どうせ遅いって行ってる奴は、工作員だから無視
558:login:Penguin
09/07/29 15:01:47 VWOuWJPW
>>555 >>557
釣り針 乙
>>556
マジレスしとくとSATAを(普通そうだが)libATA経由で使っている場合、(当たり前だが)hdparmは使えない
思うに君は、まだ人にアドバイス出来るレベルじゃないと思うよ
大体からして、ファイルシステムと何の関係もない時点でスレ違いも甚しいんだから
とっととopenSUSEスレに誘導すべき
559:login:Penguin
09/07/29 15:55:44 ECOx3YRB
>>558
使えるぞ
いつから頭が止まってるんだ?
560:login:Penguin
09/07/29 16:01:46 Y3KdxcyS
SATAがlibATA経由になるくらいの頃からじゃね？ww
561:login:Penguin
09/07/29 16:05:28 YLBcoCMj
sataのpatchが必要なのは、kernel 2.6.22 と 2.6.23 くらいだ
それ以外は必要無い
562:login:Penguin
09/07/29 16:35:49 aOQ4ySW7
思うに君は、まだ人にアドバイス出来るレベルじゃないと思うよ
思うに君は、まだ人にアドバイス出来るレベルじゃないと思うよ
563:login:Penguin
09/07/29 17:38:16 BkS/l//X
>>558
556やけど
恥ずかしがらんと、またおいでや
564:login:Penguin
09/07/29 19:30:59 g9AlD0Tp
dmcryptで暗号化する場合に最適なファイルシステムを教えてください
中身はお察し下さい
565:login:Penguin
09/07/29 23:24:22 Lyt3N/wI
>>561
また嘘ばかりを・・・・
566:login:Penguin
09/07/29 23:39:12 YLBcoCMj
>>565
2.6.24以降はlibata用のhdparmのpatchは必要無くなったはずだが
何がどう嘘なの？
567:530
09/07/29 23:57:41 Dai87m7Q
結局ただの嘘つきか。> 552
使ってもないんじゃないの?
568:login:Penguin
09/07/31 04:00:07 VaVCoKjY
2.6.19以降は、/dev/hdaが/dev/sdaに変わると聞いて
設定ファイルを書き換えカーネルを入れ替えて再起動したら
/dev/hdaのままで困ったことがある
上で出てた断片化による速度低下だけど使い方によるよ。
Windowsはツールで断片化の具合が確認できるから
自分の使い方での傾向が分かるけどLinuxでは難しい。
基本的に同じサイズのファイルを書き込みつづける場合は影響を受けにくいよ
一番影響受けやすいのは、
大量の細かいファイルと巨大なファイルを同居させた場合。
Linuxは大量に細かいファイルを作る傾向にあるから、
音楽ファイルや動画ファイルはルートパーティションから隔離しとくと吉
569:login:Penguin
09/07/31 15:03:09 MK+pGXZ2
>>568
妻を殺した人が作ったファイルシステムを
ルートパーティションに使うべきということですね
570:login:Penguin
09/07/31 20:51:02 k+Upna9N
>>569
何の関係もないな。/でも/bootでも使えばいいさ
571:login:Penguin
09/07/31 21:36:42 tbYA8+dL
btrfsが実用的になるまではreiserfsしか選択肢が無いなぁ。
572:login:Penguin
09/08/01 00:20:50 SNB9Lm9T
>>568
SQLサーバのパーテーションを分けておくべきだったと後悔。
>>571
reiserfsって、今どの程度メンテナンスされているのかな。
SuSEのデフォルトfsからも落ちちゃったし、先がないのは分かっているが、
現状でもっともマシなんだよな・・・。
573:login:Penguin
09/08/01 06:29:20 exuELPVL
>>571
○○○もいいよ。
スレが荒れるから名前は伏せるけど。
574:login:Penguin
09/08/01 07:49:48 eQAKtpCe
FATか
575:login:Penguin
09/08/01 11:54:52 4UAEiy8v
reiserfsの何が他より優れているのか。
１行で答えなさい。
576:login:Penguin
09/08/01 12:13:57 VgzA3aXA
名前の長さ
577:login:Penguin
09/08/01 13:01:41 mXx3DngF
名前は長いほうがいいのか？
戒名みたいだな
578:login:Penguin
09/08/01 16:48:33 IAPkS0Yu
「戒名」「法名」の長さについて
URLﾘﾝｸ(black.no-blog.jp)
579:login:Penguin
09/08/02 01:14:52 Xdq0E5w1
googleのファイルシステム公開してくんないかな
580:login:Penguin
09/08/02 01:33:18 +uNZh5d6
そんな特化したFS公開されても・・・
581:login:Penguin
09/08/02 02:04:26 HFtAZHUu
>>579
使い道ないじゃん。
582:login:Penguin
09/08/02 07:54:45 43zxi/8E
>>579
ReiserFSの気がするのは俺だけだろうか
583:login:Penguin
09/08/02 08:09:22 BsPAG2ZW
個々はext2だという話だったような。
それを多数で分散冗長化しているのが独自技術で。
584:login:Penguin
09/08/02 09:22:39 uUBOpM9k
URLﾘﾝｸ(labs.google.com)
585:login:Penguin
09/08/02 11:44:22 y9A4+xpk
Filesystem Specifications - Links & Whitepapers
URLﾘﾝｸ(www.forensics.nl)
586:login:Penguin
09/08/02 11:56:57 HWrwkQRU
誰かHAMMER移植してくれないかな。
俺？能力的に無理ぽ orz
587:login:Penguin
09/08/02 12:52:02 S1KUAPtn
Googleext2の上にGoogleFSを構築している。壊れるのが前提だからjournalingいらんし
ext4にjournalingなしのモードがついたのは、ext2からext4に移行したいgoogleがプッシュしたから
GoogleFSはオープンソースの実装が出てるけど、普通の単体ファイル操作は猛烈に遅い、
っていうか専用の API を通してしか操作できないから、一般人が使えるものじゃないです
588:login:Penguin
09/08/02 13:47:37 oNmo8zqP
>>587
万が一にもsyncしないでマシンが止まることはないのを保障しているのか？
電源障害でたくさんのマシンが一斉に落ちたりすると
fsckの時間が無視できないと思うんだが。
589:login:Penguin
09/08/02 14:02:27 +uNZh5d6
公開された先生のサーバってノード毎にバッテリー載ってる戯画のカスタム板だよな
590:login:Penguin
09/08/02 14:08:32 xaBD/3Nd
>>588
そういうレイヤーのファイルシステムじゃないんだろ。
591:login:Penguin
09/08/02 14:36:00 T8DPlbOa
>>588
Googleは、サーバーは「どんどん壊れるもの」が前提なので、保証もなにも、そんなことはどうでもいい。
実際どう運用しているのか知らんけど、fsckしようが、その時間が無駄だからmkfsしてサラにしようが、
大して違いがない。どうせ同じデーターが世界の別の場所に最低2カ所あるんだし。
592:login:Penguin
09/08/02 16:01:34 6M6aomwO
「潔いのだな Googleは」
「そこに惚れたのでしょ？ラル大佐も」
593:login:Penguin
09/08/02 19:47:06 nThwvegR
流し読みしただけでよく読んでないけど、
FSってより、APIだなこれ
memcachedをインデックス管理できるようにしてクラスタ化するとこんな感じかな?
594:login:Penguin
09/08/02 22:06:58 t3P+JXcL
>>568
> 上で出てた断片化による速度低下だけど使い方によるよ。
> Windowsはツールで断片化の具合が確認できるから
> 自分の使い方での傾向が分かるけどLinuxでは難しい。
e2defrag 使ってましたがなにか?あれはフラグメントの様子が視覚化できるんだよ。
win でも linux でも defrag は自分の使用条件ではたいして効果なし。てのが結論。
シーケンシャルリードばっかじゃないからね。
可視化ツールには一応 DAV と言うのがある。未だに ext2/3 のみだが。
URLﾘﾝｸ(dav.sourceforge.jp)
> 基本的に同じサイズのファイルを書き込みつづける場合は影響を受けにくいよ
> 一番影響受けやすいのは、
> 大量の細かいファイルと巨大なファイルを同居させた場合。
そんなの周知だよ。昔から。フラグメント問題はメモリ割り当てとかでもあるんだよ。
> 音楽ファイルや動画ファイルはルートパーティションから隔離しとくと吉
ていうか、読み書きの多いファイルとほとんど書き換えなし/消去なしのファイルはパーテーションわけしておく、とか。
昔から行われていることだよ。
周知なネタばかりじゃん。
595:login:Penguin
09/08/02 22:08:05 zuGU9fys
>>594
はいはい、君は物知り博士だねぇ。
596:login:Penguin
09/08/03 01:37:56 kZ8h29CW
>>594 メモリのフラグメント問題と ディスクのフラグメント問題は ぜんぜん違う問題
597:login:Penguin
09/08/03 02:13:54 4ahQ/E8a
メモリのフラグメントは
実質使用量が増えて最終的に割り当てが出来なくなる(可能性がある)というのが一番の問題だけど
ディスクの場合はアクセス速度が遅くなることが問題点だもんね。
まあ稀にディスクの空き領域が足りなくなるまで書き込む人もいるかもしれないけど
ディスクの場合は分断されていても獲得は出来るのに対し
メモリは(アドレス空間の)空きが分断されていたら獲得自体が出来ないから。
598:login:Penguin
09/08/03 02:26:59 0psqM35I
MMUなんて便利なもんがだいぶ前から使われてるんだけどな
今は、メモリ管理情報の肥大化による問題の方が大きい
599:login:Penguin
09/08/03 02:31:08 4ahQ/E8a
へー、MMUでアドレス空間の不足を解消できるのか。
600:login:Penguin
09/08/03 06:52:39 D9UOKH8p
物理アドレス空間と論理アドレス空間を区別してない時点で
4ahQ/E8aも0psqM35Iもまともな議論はできてねーよ。
お互い勝ったつもりなんだろうが。
601:login:Penguin
09/08/03 06:57:53 Ihjxl/59
>メモリは(アドレス空間の)空きが分断されていたら獲得自体が出来ないから。
これが物理アドレスの話の可能性があると思えるなんて異常すぎる
602:login:Penguin
09/08/03 07:01:40 Ihjxl/59
アドレス空間の空きのフラグメント解消に
ページングを持ち出す598はもっとすごいな
603:login:Penguin
09/08/03 09:05:45 +7q4foS8
天災同士の貴重な議論は
逸般人にはどうせ理解できないものなので
他所のもっと落ち着いた場所でやるほうが
有益だと思います
604:login:Penguin
09/08/03 11:53:41 qdW8N29Q
dosかなんかの話してるんじゃないの？
605:login:Penguin
09/08/03 12:26:54 XZq6o4Nt
メモリのフラグメンテーションの話はスレ違いだ
そんなに罵り合いたいなら他でやれ
606:login:Penguin
09/08/03 22:30:12 NM+z6upI
次スレタイはこれで。
【釈放】Hans Reiserは木が得意【ﾏﾀﾞｰ?】
607:login:Penguin
09/08/04 00:51:40 wKfZCk0q
頭悪そうだな
608:login:Penguin
09/08/04 12:03:16 hDAUtPxp
悪そう、じゃなくて悪いんだよ
頭も心も
609:login:Penguin
09/08/04 20:37:36 ZIj5Pq57
btrfsﾀﾝ、ハァハァ
610:login:Penguin
09/08/04 21:35:23 zBDyWBP8
>>607-608
おまいらよりはマシだ
611:login:Penguin
09/08/04 21:38:52 NQSypDHr
だから頭悪いって言われるんだよ。
何を基準にそう判断したんだ？
612:login:Penguin
09/08/04 22:55:27 2uDO8De7
>>611
子供かｗ
613:login:Penguin
09/08/04 23:46:05 NQSypDHr
>>612
まぁ、未成年なので子供ですがｗ
614:login:Penguin
09/08/05 02:37:35 gTZRwnjz
あれだけいわくつきなファイルシステムなのに
未だにreiserfsが支持されてる(少なくとも風化してない)のはすげーな。
ext2しかない時代に現れた時は確かに神かと思ったが。
あの時に比べるとext4やらなんやら出てきても
派閥争いうぜえ、面倒だからext3でいいや、で終了してしまう俺。
615:login:Penguin
09/08/05 05:41:45 ah5TOzXe
reiserfsになんのいわくがあるの？
616:login:Penguin
09/08/05 06:32:27 W7q6iatu
>>614
・そこそこの性能
・適度な枯れ具合
・他FSに移行するのが面倒
なので使ってる人がほとんどじゃないかと思う。
617:login:Penguin
09/08/05 09:10:40 MqOHb/7H
nilfsで検索しても「2.6.30カーネルに取り込まれた」って記事ばかりで
人柱報告がほとんどない
実際どうなの？＞人柱の皆さん
618:login:Penguin
09/08/05 09:15:31 Uzfwchw8
日本以外ではメジャー
619:login:Penguin
09/08/05 09:47:05 RYqMjlu9
国産なのにな
620:login:Penguin
09/08/05 19:25:29 Ta8o51LO
>>616
そこそこの性能ってどれぐらい？ext3より早い？
ext3ばかりをDBに使っているオレに分かるように
reiserfsのありがたみを教えてよ。
621:login:Penguin
09/08/05 19:38:07 l0ecsUdB
自分で使ってみればいいじゃん
622:login:Penguin
09/08/05 20:15:21 uRwqclf+
てかDBに使うならどのfsでも大差ない。
623:login:Penguin
09/08/05 21:54:52 jAE0qfFT
動的inodeじゃない時点で却下
624:login:Penguin
09/08/05 22:49:05 5pkgixmk
>>623
動的iノードのファイルシステムを支持するとスレが荒れますよ。ご注意を。
625:XFS
09/08/05 23:24:27 r1cVDk5Q
荒らす奴が悪い。
626:login:Penguin
09/08/06 15:28:15 Ak5ILM8x
>>622
ほんとか？詳細キボーン
627:login:Penguin
09/08/06 16:01:18 V0OhXb2J
>>626
btrfsなどCoW系のはデータの書き換えで
メタデータのチェックサムを更新するから遅そうだ。
nilfsなどLOGFS系は明らかに向いてないだろうね。
ext2などブロック管理のは
DBファイルのサイズが大きくなったときに性能がおちる。
それ意外のはキャッシュのつくりがよほど弱くなければ
似たような性能になるんじゃないのか?
628:login:Penguin
09/08/06 20:33:02 QxBdNWpW
つーか、動的i-nodeって一言で言っても
例えばReiserFSとか、NTFSや、Btrfsみたいに、
使われてないi-nodeは確保せず、必要に応じて
ファイルと一緒にi-nodeも拡張してゆくようなのと
XFSみたいにi-nodeとして使われているエリアがあって
そこが足りなくなってくると、i-nodeエリアを一定量ずつ
再確保してゆくようなのとでは同じ「動的i-node」と言っても
実際にはほとんど別物だと思うんだ
仮にFSとして使える量だけ考えてみても
前者は最後まで無駄なく使えるのに対して
後者はi-nodeとして使われてる空間が多少なりとも使えずに残るし
スピードだって
前者は最後の方に行くに従って段々と遅くなるけど
後者は、後から追加したi-nodeから参照するデータはガクッと遅くなる
単純に「動的i-node」とかって、ひとくくりにしないで欲しいよな
後者のは、昔っからある静的i-nodeスタイルなFSに、i-node再確保システムを
後付けしただけなんだから
むしろ後からちまちま再確保せず、始めっからドカッとi-nodeを確保する
昔ながらのFSの方が潔いし、スピードもそっちの方が速いよ
629:login:Penguin
09/08/06 20:40:47 RMpOGeqI
>>628を要約します
XFSはクソ
630:login:Penguin
09/08/06 20:50:32 IKCdGcSv
>>628
> 後者は、後から追加したi-nodeから参照するデータはガクッと遅くなる
> 昔ながらのFSの方が潔いし、スピードもそっちの方が速いよ
この2点のソースは？
631:login:Penguin
09/08/07 11:32:52 utwdKufT
無駄なi-node領域があるのはかまわないんですよね。まあ多すぎるのは意味ないですけど。
必要に応じて振る方法が、最後の方になると遅くなるはなんでですか？
たとえばReiserfsだと、ファイルの情報は全部ツリーに入ってる(から動的)わけで、
ファイル数が増えた(=ツリーが大きくなった)という理由以外だと、
空きobjectidの検索があるから？でも動的じゃなくても空いてるの探すのはありますよね？
XFSはAG毎に管理してるから、後からのやつが遅くなるってことは無さそうなんだけど、
遅くなるんですかね？もちろんAG数に依存はすると思うけど。
632:login:Penguin
09/08/07 13:14:15 +w6MBDzH
XFS+UPSが最強なのにまだやってんのかよ
いい加減にしろ
633:login:Penguin
09/08/07 13:20:22 Y0OUSY1v
>>631
いつものアンチXFS厨だよ。気にすんな
634:login:Penguin
09/08/08 06:47:21 KCg3bIRj
>>632
/bootだけはext2だろ
635:login:Penguin
09/08/08 09:48:48 ZAmfBvdJ
全部xfsじゃダメなの？
md使ってたらgrubがxfs対応してないから/bootはext2にしてるけどさ。
636:login:Penguin
09/08/08 09:57:05 1jiNUxA+
>>635
XFSは地獄
ext2/3/4は天国
この現実を知らないの？
/bootがXFSなら明日は起動しないかもよ？
637:login:Penguin
09/08/08 10:09:28 +0qGTwxr
>>635
馬鹿に構うなよ
638:login:Penguin
09/08/08 10:10:58 urqjNkQr
/bootとかブートに関係するとこは高機能なのよりできるだけ単純というか、
よく揉まれているtried & trueなファイルシステムの方がいいっていう話じゃないか。
XFSとかreiserも低リソースで起動しなきゃいけないブートローダがサポートするには色々複雑で大変だよな、
みたいな。
EFIとか使うとEFI用の領域ってFATになるよな。たしか。
639:login:Penguin
09/08/08 10:28:55 1jiNUxA+
>>637
わかりました。
640:login:Penguin
09/08/08 10:50:31 mBkq56h9
/bootは殆ど書き換えないから、単純な方がいいな
641:login:Penguin
09/08/08 11:23:54 i8n9snwz
GRUBはジャーナルを使わないから/bootをジャーナリングファイルシステム
にするのは無意味どころか有害って既出の話
カーネルの更新中にクラッシュしちまうような
日頃の行いの悪い子以外はどうでもいい話だけどな
642:login:Penguin
09/08/08 11:37:57 urqjNkQr
うんうん。
/以下をまるごと同じファイルシステム使っていると、そのへんの加減ができないからやっぱ駄目だよねえ。
643:login:Penguin
09/08/08 13:22:09 ZAmfBvdJ
639
？
644:login:Penguin
09/08/08 15:01:13 zDfovaF0
Linuxのファイルシステムはよくない、んだとよwww
URLﾘﾝｸ(q.hatena.ne.jp)
645:login:Penguin
09/08/08 15:04:37 2KSMxYa2
またマカーか
646:login:Penguin
09/08/08 15:32:07 SmLZHg3a
HNに注目
647:login:Penguin
09/08/08 15:53:33 +gGkG7kS
swap と / しかパーティション切ってない orz
昔NetBSD使ってたころは / /usr /home /var とか色々分けてたけど段々面倒になってきて．．．
648:login:Penguin
09/08/08 16:47:44 2Mh/ngI8
俺は/と/homeだけだな
swapはファイルにした
649:login:Penguin
09/08/08 18:05:10 LOt12QIC
今さらboot分ける意味ってなくね？
650:login:Penguin
09/08/08 19:08:08 0nmwXefb
>>649
逆にext4がデフォルトになったディストリだとブートローダの都合で必須じゃね？
651:login:Penguin
09/08/08 19:17:38 f2dxNLiR
/boot / home /usr /var
652:login:Penguin
09/08/08 19:22:37 KCg3bIRj
/bootを分けるのは気分の問題だな。俺は。
CentOSを永いこと使ってたから、どのディストリでも/bootと/をプライマリ、スワップを拡張に切りたくなる。
653:login:Penguin
09/08/08 19:45:01 Op0NLWmu
モジュールを置く場所ってどうして /lib/modules/バージョン/・・・
のままなの？
モジュールってカーネルとセットで扱わないと意味無いんだし
/bootとかそれに似たところにカーネルとうまく組になるように
置くべきだと思うんだけど どうなの？
654:login:Penguin
09/08/08 20:05:41 I2Fkxttz
>>653
どうでもいい。
655:login:Penguin
09/08/08 20:08:39 jjZY8imH
>>650
ubuntuのgrubは独自パッチが当たってて、ext4からブート出来るんじゃなかったっけ？
656:login:Penguin
09/08/09 03:20:15 BjcglXB+
>>653
モジュールのロードにはboot loader関与しないし、
boot時に必要なモジュールはinitrdに入れるのがLinux流だから。
みんな特に不満が無いんじゃない？
657:login:Penguin
09/08/09 19:13:32 IkGSFCMm
[Phoronix] Merging Tux3 Into The Mainline Linux Kernel
URLﾘﾝｸ(www.phoronix.com)
658:login:Penguin
09/08/10 13:12:09 c0CFIMPr
>>653
initrd使わない人なの?
659:login:Penguin
09/08/10 15:11:55 Dcoo3+kG
>>655
Yes
660:login:Penguin
09/08/11 04:19:13 E8HEqNfN
>>628
NTFSは事前にインデックス用の領域を確保しちゃうよ （MFTという名前）
ただし、空き領域が不足したときはMFTの一部を開放して
ファイル用に割り当てることができるから容量は最後まで使い切れる。
だから >>628 が言う前者と後者の両方の利点をNTFSは持ってる。
しかし、容量ギリギリまで使おうとするとMFTが断片化して遅くなるのも事実。
661:login:Penguin
09/08/11 10:12:17 tRKWJbdY
嘘だらけの知ったかに食いつくなよ
662:595
09/08/11 12:18:52 Lzu/ezTE
> >>594
> はいはい、君は物知り博士だねぇ。
一体誰が物知り博士だなんて主張してる?
周知って言葉の意味を知らんのか。
>596
>>594 メモリのフラグメント問題と ディスクのフラグメント問題は ぜんぜん違う問題
一体誰が同じだなんて主張してる?
文章読めないのか。
>597-598
君は知らなそうだが、内部断片化、外部断片化てのも周知の話だよ。
結局、初歩的、初心者的知識すら乏しいじゃん。
663:login:Penguin
09/08/11 12:49:22 gCZov+kt
>>662
664:login:Penguin
09/08/11 18:41:05 ZkXwyRtm
まだまだ夏だねぇ・・・
665:login:Penguin
09/08/11 18:51:23 WK11feHT
何言ってんだよ。もう秋だよ。
666:login:Penguin
09/08/11 19:05:11 iCFlOGmM
今年は夏なんてなかったし
667:login:Penguin
09/08/11 21:13:41 f+c4YjXq
Symantec の Norton Ghost v14 は ext3/4・ダイナミックボリュームに対応だそうですが、
こういったディスクイメージ操作型バックアップツールで 動的inodeの reiserfs も
ディスクイメージとしてバックアップ出来るツールってあるんですか？
668:login:Penguin
09/08/11 23:15:39 f2B87ZB1
dd?
669:login:Penguin
09/08/11 23:35:18 f+c4YjXq
ghostですと、
・CDやFDから起動して、DOSまたはLinux?上で動作。（ブートディスク作成時に指定）
・ハードディスク丸ごとそのままコピーも出来れば、パーティションを圧縮してコピーも出来る。
・イメージファイルとして保存・復元するほか、直接Disk間コピー・パーティション間コピー出来る。
・コピー元の使用容量が少なければ、コピー先パーティションにコピー元より小さい容量のパーティションが指定できる。
・イメージファイルの保存先としてCD-RやDVD-R、SCSIメディア、SCSIテープ、シリアルP2P、ghostサーバ(ネットワーク)も選べる。
・コマンドラインオプションによりブート後の動作をほぼ自動化できる
・windows上でghostエクスプローラによりイメージファイルの中身を編集できる
ddを調べてみましたが、知らないと難しいとはいえ上記の半分以上をddで出来てしまうようですね。
GUIでddバックアップできる専用のCDブートのディストリビューションとかあったらghost要らなくなりそうです。
670:login:Penguin
09/08/11 23:55:37 TECp/WKW
URLﾘﾝｸ(sourceforge.net)
もしそうならこれをKNOPPIXカスタマイズして組み込んだりしたらうまいかな？
KNOPPIXのベースであるDebianとの相性にはついては確認していないが。
671:gparted
09/08/12 00:11:27 oaMYKOHs
>679
呼んだ?
672:login:Penguin
09/08/12 00:27:21 V+ssuppU
そういやこんなものもあったね。
URLﾘﾝｸ(gigazine.net)
ddはファイルシステムフリークの友。
673:login:Penguin
09/08/12 01:09:19 SVsEtJYf
>>670-672
情報ありがとう。
そういえばBackup&RestoreとPartition編集の両方が1枚に収まってるのって知らないな。
AcronisはTrueImageとDiskDirector(旧PartitionExpert)とで別のブートCDに焼くようになってたと思う。
マルチブートCDを自作すれば1枚に収まるけど機能の切り替えに再起動が必要になるし。
ちなみにDiskDirectorとGPartedでは両方とも対象との相性で出来る・出来ないみたいなのが出るので、
どっちが優れているというよりも両方用意してると安心だと思った。
674:login:Penguin
09/08/12 01:17:22 SVsEtJYf
というか>>670こそまさに1枚に収め得るGUIツールなのか…
AIR (Automated Image & Restore) is a GUI front-end to dd/dcfldd
designed for easily creating forensic disk/partition images.
Supports MD5/SHAx hashes, SCSI tape drives, imaging over a TCP/IP network,
splitting images, and detailed session logging.
こいつはSymantecさんに俺の心がベンダーロックインされている場合では無さそうだ。
675:login:Penguin
09/08/12 12:31:31 yJ4s2NJK
つ Clonezilla Live
676:login:Penguin
09/08/12 16:44:47 NA/P7dE7
nilfs2の人柱になることにしました。
壊れたらまた書き込みます。
677:login:Penguin
09/08/13 21:50:34 h/nV7bVc
>>675
LVMもサポートか。ghostもTrueImageもセクタバイセクタでのみ複製可能、ghostはその後そのままでは起動しない。
URLﾘﾝｸ(service1.symantec.com)
Ghost ではシングルストライプボリュームまたはミラーリングしていないシングルセグメントボリュームだけがクローニングされます。
Ghost でイメージを作成したり、ディスク間でクローニングを行う場合、LVM ボリュームは通常のパーティションと同様に扱われます。
したがって、Ghost では復元先に LVM ボリュームを再作成できません。
これらのボリュームは単純なパーティションであるかのように複製されます。
手動で設定ファイルを編集する必要がある場合もあります。
復元先ディスクにある既存の LVM ボリュームには、1つのパーティションのみをクローニングまたは復元できます。
この場合、既存のボリュームはオペレーティングシステムの LVM に残ります。
678:login:Penguin
09/08/15 21:28:35 KcxMl9KA
ZFSの本が出てる。これは物凄く大きいメリットだと思うんだが。
reiserfsは開発者にケチついちゃってるし、ext3はinodeがあれだし。
679:login:Penguin
09/08/15 21:42:08 FlV6hdNl
>>678
言わんとすることがよく分からない。本が出ていることが大きなメリットなの？
ZFSそのものがLinuxにメリットをもたらすわけでもないし…
680:login:Penguin
09/08/15 21:50:15 WPxIDL04
btrfsとかやろうとしてるけど、ああいうのが出てくるのはzfsで効果の
実証があったからだろうからな。メリットがないと言い切るのは言い過ぎだと
思う。
681:login:Penguin
09/08/15 22:03:12 ZR4fGY5t
btrfsの開発が始まったのは、大体同じ時期だし
ああいうファイルシステムは、専門家は以前からしたためてたでしょ
あれ、開発してるのオラクルだし
682:login:Penguin
09/08/15 22:34:11 WPxIDL04
>btrfsの開発が始まったのは、大体同じ時期だし
btrfsの開発が始まったのが大体同じ時期って、何年だっけ?
zfsの方は割とはっきりしていて2000年だよね。同じ頃というと
2001年～2002年位の話?
683:login:Penguin
09/08/15 22:57:38 ZR4fGY5t
>>682
btrfs開発者のインタビューされてただろ
684:login:Penguin
09/08/15 23:38:21 WPxIDL04
>683
だから、その時期がいつ頃の話かを知らないから聞いているんだけど。
Oracleから0.13の発表があった頃が2007年だろ? でも、開発をいつ頃から
始めたか、具体的な時期はまだ見た記憶がないんだ。
685:login:Penguin
09/08/16 00:11:37 F4NvMXmo
あれ？もしかしてLinuxやめて
OpenSolaris or FreeBSD + ZFS + Samba
ってすれば安泰ってことなのか？？？
686:login:Penguin
09/08/16 00:23:43 QxEbJKQ2
どうぞお好きなように
687:login:Penguin
09/08/16 00:39:36 EfKoUPIm
ZFSつかうならSolarisにしとけ。FreeBSDのZFS実装は甘すぎる。
688:login:Penguin
09/08/16 01:06:01 2aCY1egN
Linux やめるぐらいなら、2008 だと思うけどなあ。
クライアント側の restore previous version でスナップショット見れないんじゃ、ZFS の意味があんまり。
689:login:Penguin
09/08/16 01:31:30 3d2dkhnf
>>687
唯一の不満がscrubかけてる間使いものにならない点なんだけど
Solarisだとscrubかけてても極端にパフォーマンス低下しないで済む？
690:login:Penguin
09/08/16 02:17:48 kxH41sn/
ボリュームシャドーコピー(w
691:login:Penguin
09/08/16 09:43:08 F4NvMXmo
DRBDによるミラーリング
URLﾘﾝｸ(www.atmarkit.co.jp)
使用できるファイルシステムにも特に制限はありません。
（中略）
なお、バージョン8.0.0以降では、
OCFS2（Oracle Cluster File System 2）と
GFS（Global Filesystem 2）に限ってですが、
アクティブ／アクティブ構成も可能になりました。
ただし、使用できるLinuxカーネルのバージョンは2.6系のみとなっています。
URLﾘﾝｸ(www.hitachi.co.jp)
両方のサーバが業務処理を実行（アクティブ）している，
このようなクラスタシステム構成を，アクティブ・アクティブ構成と呼びます。
692:login:Penguin
09/08/16 14:05:40 ydTy1Pxn
>>685
Solarisにすると、Sunの力を思い知るが、
同時にLinux(というかOSS)のコミュニティーの力も思い知る。
693:login:Penguin
09/08/16 14:09:21 30gxzye8
まあな、企業だと買収されるからなwwwwww
Oracleあたりに
694:login:Penguin
09/08/16 14:12:15 F4NvMXmo
とーばるさんのつんでれにサンさんがラブコールという記事を見かけた
でもエンディングまで待てないｗ
695:login:Penguin
09/08/16 15:32:11 ShXgtsTb
結局Sunさんはドライバ君が目当てだったりで泥仕合。
696:login:Penguin
09/08/16 18:23:11 XCb/HOyT
オラリスﾏﾀﾞｰ？（・∀・)っ/凵⌒☆
697:login:Penguin
09/08/16 19:46:59 +EY5QaoN
MIRACLE LINUXって死んじゃったんだっけ
698:login:Penguin
09/08/16 20:52:53 oCPtyYoh
>>697
王大人発見
699:login:Penguin
09/08/17 14:30:26 gU6WCNRC
Solaris + Oracle で Miracle Solaris とか作ってくれよ。
700:login:Penguin
09/08/17 14:33:57 JgKFoyEe
Miracle SolarisにOracle Linux出せば完璧
701:login:Penguin
09/08/17 17:37:05 Mtq0KkUg
>>1
●過去スレ
01 ｽﾚﾘﾝｸ(linux板)
02 ｽﾚﾘﾝｸ(linux板)
03 ｽﾚﾘﾝｸ(linux板)
04 ｽﾚﾘﾝｸ(linux板)
05 ｽﾚﾘﾝｸ(linux板)
06 ｽﾚﾘﾝｸ(linux板)
07 ｽﾚﾘﾝｸ(linux板)
08 ｽﾚﾘﾝｸ(linux板)
09 ｽﾚﾘﾝｸ(linux板)