ファイルシステム総合スレ その10at LINUX
ファイルシステム総合スレ その10 - 暇つぶし2ch400: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のテストで酷いことにwww
ロックがうまく捌けてない?

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厨発見
ここから30レスくらいアンチが埋め尽くすはず

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
SSDの登場でむしろブロック依存は高くなるよ。
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経由で1回書き込むと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落ちてるwwwwwwwwwwwwwww









orz

539:login:Penguin
09/07/25 23:16:21 PLnhHNIh
バターさんwwww

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
いままでの3倍速でいけてますか?

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の何が他より優れているのか。
1行で答えなさい。

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
子供かw

613:login:Penguin
09/08/04 23:46:05 NQSypDHr
>>612
まぁ、未成年なので子供ですがw

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
とーばるさんのつんでれにサンさんがラブコールという記事を見かけた
でもエンディングまで待てないw

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板)

702:login:Penguin
09/08/25 12:56:23 lufMfa+G
エロ動画の保管に最適なファイルシステム
誰か作ってちょ

703:login:Penguin
09/08/25 13:25:36 Ynipj+Uz
xxxfs

704:login:Penguin
09/08/25 13:46:36 27Llmryy
>>702
winnyfs を実装するときが来たか。

705:login:Penguin
09/08/25 15:01:25 rMDnS/SS
p2pfs

706:login:Penguin
09/08/25 15:10:33 rVcXlX+8
暗号化は必須?

707:login:Penguin
09/08/25 18:21:40 ap/+zt18
だね。日本でも近日中に単純所持でも捕まるようになっちゃうだろうし、
海外行ったときなんて日本では完全に合法なものでもアウトになっちゃうし。

708:login:Penguin
09/08/27 20:03:17 OwDvsT+D
A short history of btrfs [LWN.net]
URLリンク(lwn.net)

709:login:Penguin
09/08/27 21:09:34 5I7Zy1ic
anonymousftpfs

710:login:Penguin
09/08/27 22:17:14 Lm4kVIxu
fuse de yare

711:login:Penguin
09/08/28 01:40:36 PybCg++g
gmailfsをraidz2で使えば
ファイルは海外だし分断されるし
冗長性も確保できるな。

あれ誰か来たよ(ry

712:login:Penguin
09/08/28 10:00:18 3cErYICB
確かに、p2p系はとんでもなく負担かけるよな

713:login:Penguin
09/08/28 15:50:17 JuTWH5Ln
>>691
兄さんそれ双方向スタンバイ…


714:login:Penguin
09/08/31 20:21:40 hlVG4OeU
ext3でフォーマット済みのパーティションで
あとからinodeのサイズを確認するには
なんてコマンドを使えば委員だっけ?

715:login:Penguin
09/08/31 20:27:18 czE5p4HU
tune2fs

716:login:Penguin
09/08/31 20:32:08 hlVG4OeU
>>715
おおありがとう

717:login:Penguin
09/08/31 23:40:39 NM/F4JQT
スレリンク(mysv板:59-73番)
ZFSが鉄板なのかなぁ

718:login:Penguin
09/08/31 23:47:41 QJZeUh74
zfsは重い
ホントに

719:login:Penguin
09/09/01 19:14:59 2tx1Usqt
>>718
nativeで実装されれば、ほかのfsと同じぐらいなんだろうけどな。。。

720:login:Penguin
09/09/02 14:05:40 wWBxl7sL
ネイティブでもメモリGB単位で使われるときつい。
64bit環境じゃないと使えなさそう。

721:login:Penguin
09/09/02 17:17:52 k2E6GSj0
快適さの代償としてある程度メモリを食う設計をしたわけだ

64bit 環境前提にしたって「今時は普通64bit」だよね
1万円強の激安サーバとかだって64bit な時代だし


722:login:Penguin
09/09/02 22:43:05 GiXsIMx1
RHEL5.4で、xfsとext4はいったね。

723:login:Penguin
09/09/02 23:12:40 nqxR64uo
いろんなディス鳥で標準のファイルシステムとして採用されだしているext4だが、
シーケンシャルアクセスの性能は結構よさそうだ。グラフを見てみて。

Linuxファイルシステムベンチマーク第2回 ext3,ext4,JFS,ReiserFS,XFS,NILFS2
URLリンク(plaza18.mbn.or.jp)

(引用)
シーケンシャルアクセスの性能比較では、ext4、XFS、ReiserFSの性能の高さが目立つ結果となりました。

ランダムアクセス 及び メタデータ操作の性能比較では、ext3、ext4、ReiserFSが全体のバランスが取れており、総合的に性能の高さが目立つ結果となりました。

724:login:Penguin
09/09/02 23:25:15 9doIYiKA
>>723
>私は経験的に、HDDには「機嫌が良い日/機嫌が悪い日」があることを知っています


725:login:Penguin
09/09/02 23:44:45 vemvobjw
>>723
>ext4 (※ bonnie++ 実行中に毎回OSがフリーズするため中止)
コーヒー吹いた


726:725
09/09/02 23:49:00 vemvobjw
>>723のリンクは第一回のほうじゃないか
第二回はこっちね
URLリンク(plaza18.mbn.or.jp)

こちら(Ubuntu 9.10)では ext4の不具合が解消されてるらしい。



727:login:Penguin
09/09/03 00:01:16 pDX9eyYg
結論としてはxfs最高ってことでいい?

728:login:Penguin
09/09/03 00:47:11 8kyyBkpc
>>725
同じような試験を手元でやったけど、
bonnie++で結果が出ないことはザラにあった。

ext4に限らないが、当時のext4+bonnie++ではダメだった記憶がある。
OSフリーズはしなかったが。

729:login:Penguin
09/09/03 02:54:22 qQvyibMp
Real World Benchmarks Of The EXT4 File-System
URLリンク(www.chineselinuxuniversity.net)
Comparison of File Systems And Speeding Up Applications
URLリンク(www.amitshah.net)
Re-comparing file systems
URLリンク(www.amitshah.net)
NILFS: A File System to Make SSDs Scream
URLリンク(www.linux-mag.com)
SquashFS: Not Just for Embedded Systems
URLリンク(www.linux-mag.com)
Creating and using squashed file systems
URLリンク(tldp.org)
>>293
xfs_estimate -im /usr/src
/usr/src will take about 0.5 megabytes
URLリンク(linux.mini13i.gotdns.org)

2002年4月01日の
URLリンク(www.ibm.com)
ちょっと古い情報かもしれないけど、
なんとなくext3より快適な気がする程度で使ってたxfsだが
激しく一長一短でそれを踏まえて全体的に高評価されてるってこと?

730:login:Penguin
09/09/03 22:32:44 1emXHjlu
URLリンク(plaza18.mbn.or.jp)
このベンチマークの不思議なこと

・320SCSIという、今となっては低速なHDDをあえて選択している
 俺もST336732LWやST373454LW、Atlas 10k IV&V、Atlas 15k IIを愛用していたSCSI原理主義者
 だったので良く分かるが、今となってはSASでないSCSIは低速なデバイスでしかなく、ぶっちゃけ
 ST336732LWなんて2世代前のRaptorやAtlas 10k Vより全ての面で遅く、ST373454LWですら現行Raptorには及ばない。
 回転数が高ければHDDの速度、得にランダムアクセスが速くなるなんて幻想。
 HDDの速度を決めるのは、HDDが作られた「世代」につきる。2世代も離れたらもうね・・・
 ましてやHDDやSCSIアダプタの型番すら書かないなんて論外。

・HDDによってランダムアクセスに強い製品や、RAIDを組んだ時に遅くなりにくい製品、
 単体で使うのが一番速い製品など色々と特徴があるのは常識だが、このベンチマークでは
 型番すらないSCSI HDDの一騎がけのみのベンチマークであるにも関わらず、ファイルシステムの評論をしている。

・ベンチマークの仕方がbonnie++だけという、意味があるんだか無いんだか分からないベンチマーク
 最低限、linux kernelの展開に掛った時間だとか、全文検索アプリ(例えばEstraierとか)のインデックス作成に掛った時間とか
 DVD ISOイメージのコピー・削除に掛った時間とか、色々とやり方はあるだろうに、あえてbonnie++だけ。意味あるのかと。

・一部のJFSのベンチマーク結果が異常に低いが、その事には一切触れず
 また、やり方や環境構築にミスがあったとも考えない、幸せ指向なベンチマーク。

731:login:Penguin
09/09/03 22:33:55 WwZ4h9O/
>>730
文系脳のベンチマークってやつ?

732:login:Penguin
09/09/03 23:50:17 v9Io1Ht2
比較ベンチマークは大抵結果が先にあって、それに合わせて条件を設定しているってばっちゃが言ってた

733:login:Penguin
09/09/03 23:51:45 ZdVEs5wD
プラシーボなんちゃら

734:login:Penguin
09/09/04 01:28:32 l63+Dyyc
>>730
ベンチマークなんだから、定量的なことはわからないんだよ。
米の糖度をいくら正確に測っても、料理の味は決まらない。
ベンチマークの数値を鵜呑みにせず、定性的な傾向を把握できればいいんだよ。

735:login:Penguin
09/09/04 12:32:41 Fok7DRls
>定性的な傾向
ファイルシステムの機嫌が良い日と機嫌が悪い日を察するとか
そういうの?

736:login:Penguin
09/09/04 12:39:43 BIskKf5v
>>734
ベンチマークだから定量的なことしかわからないんじゃ?


737:login:Penguin
09/09/04 14:32:56 l63+Dyyc
>>736
数値で結果が出るから定量的な指標となる、
と思ってしまうのが、ベンチマークの罠だと思う。

738:login:Penguin
09/09/04 14:45:52 BIskKf5v
>>737
数値を出さない定量的な指標ってあるの?


739:login:Penguin
09/09/04 19:30:58 l63+Dyyc
>>738
数値で結果が出るのは十分条件じゃなくて、必要条件なので、
ベンチマークは数値が出るからと言って定量的という訳ではないってこと。

もちろん、実際に稼働中の実システムで統計を取ったベンチマークは、
そのシステムにおける定量的な指標になり得るけどな。

それ以外の一般的なベンチマークは、定性的な傾向しかわからんよ。
無理に定量的に理解しようとすると >>730 みたいになる。


740:login:Penguin
09/09/04 21:38:09 BUDJTh40
定性的かも知らんが。
性能が必要なDBを作るならNILFS2が向かなさそうなことはベンチ結果から見てとれた。
俺ならシーケンシャルIOがいけてるっぽいext4、XFS、ReiserFSをまず候補にするな。

考察にも書いてあるが、NILFS2にはスナップショットの機能があるし、
NILFS2の安定版が出たらSambaのファイルサーバ用途とかでは使えそうだ。

メールサーバならランダムIOがいけてるっぽいext3、ext4、ReiserFSがまず候補。

公開されているベンチ結果なんて、所詮こういう使い方じゃね?
で、実環境にミドルウェアとかアプリを乗せて、自分で最終確認するのが大原則だ。

>>724
だから、1ファイルシステムを2日に分けてベンチしてるんじゃね?
条件は一緒のはずなのにいつもより性能が出ない日というのは確かにあるからな。
で、それでもベンチ結果に誤差はありますよ、と書いてある。

>>726
Ubuntu 9.10で解消されている話。詳しくは↓
URLリンク(forums.ubuntulinux.jp)

741:login:Penguin
09/09/04 22:15:05 eIcGAGpG
どうでもいいが、どのあたりがLinuxシステム構築Tipsなんだろう
ひたすらベンチマークしかしてないような感じだが

742:login:Penguin
09/09/04 22:23:37 l63+Dyyc
>>741
マシンやパーテーションの用途によってファイルシステムを使い分けられるのが
Linuxの良いところだと考えると、構築Tipsになるじゃん!
・・・だめ?

743:login:Penguin
09/09/04 22:27:58 dszZlRA1
つまらん

744:login:Penguin
09/09/04 22:29:12 hWPP+mOR
btrfsの完成に期待

745:login:Penguin
09/09/04 22:32:35 medVVj1W
オラクルがんばれや。

746:login:Penguin
09/09/04 22:51:44 BUDJTh40
>>741
ファイルシステムとしてext3しか知らない連中にとっては結構なTipsだったかもね。
この板に出入りしているオマイラにはTipsでもなんでもないんだろうけどさー

747:login:Penguin
09/09/04 22:57:55 cJIr+IgL
短時間のベンチで安定性や運用性は全く見えないからなー
地雷がわかる程度か


748:login:Penguin
09/09/04 23:02:03 hR6bX513
>>747
fsが多少遅いのは問題なくても、
OSごと固まるのは地雷と言ってもいいと思う。

749:login:Penguin
09/09/04 23:10:06 BUDJTh40
>>747
確かに。Ubuntu9.04のext4は地雷踏みそうというのが分かった。

730が指摘してるようにUbuntu9.10のJFSはシーケンシャルライトがダメダメで
これも地雷っぽいな。再現した人いる?
第一回を見ると、Ubuntu9.04ではJFSも悪くないんだよね。
Ubuntu9.10でも正式リリースの頃には結果が変わっているかも。

750:login:Penguin
09/09/05 00:45:03 OTIeQwIl
Ubuntuのext4がって言うよりは新しいものはいつだってそういう危険があるってだけの話な気がする。
思えばext3が出たばかりの頃もext2に比べてトラブルまくりだったし。

751:login:Penguin
09/09/05 02:44:50 04v/j8aE
JFSは最近手入れされてるの?

752:login:Penguin
09/09/06 04:33:55 oZEFrl9q
>>751
されてるわけがない・・・

753:login:Penguin
09/09/06 10:52:55 H61tC/K7
fs名の前はスペース4つ
$ grep '^ ext2:' ChangeLog-2.6.30 |wc -l
4
$ grep '^ ext3:' ChangeLog-2.6.30 |wc -l
12
$ grep '^ ext4:' ChangeLog-2.6.30 |wc -l
49
$ grep '^ reiserfs:' ChangeLog-2.6.30 |wc -l
47
$ grep '^ reiser4:' ChangeLog-2.6.30 |wc -l
0
$ grep '^ jfs:' ChangeLog-2.6.30 |wc -l
6
$ grep '^ xfs:' ChangeLog-2.6.30 |wc -l
65
$ grep '^ btrfs:' ChangeLog-2.6.30 |wc -l
2
$ grep '^ nilfs2:' ChangeLog-2.6.30 |wc -l
65
$ grep '^ nfs:' ChangeLog-2.6.30 |wc -l
3

754:login:Penguin
09/09/06 16:03:37 mLF5287r
ファイルシステムの安定性・信頼性を評価できるベンチマークソフトってある?
bonnie++やIOzoneで1週間負荷をかけ続けるとか、そんな感じ?

755:login:Penguin
09/09/06 21:27:07 Wp8w55Q4
負荷だけでよければいいんじゃね
そんなものが信頼性になるのかはしらんが

756:login:Penguin
09/09/06 22:33:16 GI5dE/j3
>>754
安定性の評価は大変だぞ。手法論的に。


757:login:Penguin
09/09/06 23:12:15 3X0QxlvX
手法論って何だよw

758:login:Penguin
09/09/06 23:44:32 zCors7qm
>>753

reiser4、かわいそうだな…。
reiser4に春は来るのだろうか…。


759:login:Penguin
09/09/06 23:53:03 oZEFrl9q
とりあえず新しいfs試すときはカーネルmake clean、makeを一晩中繰り返してる

760:login:Penguin
09/09/07 14:27:15 irG6WRrN
>>753
うを、Btrfsの開発大丈夫なの? Oracleはやる気失っちゃった?

761:login:Penguin
09/09/07 15:53:26 MXKkyeqk
>>760
よくしらんが、本家ページ見ると
0.18が2.6.29で、0.19が2.6.31みたいだから2.6.30では特に変化無かったのかもね。

762:login:Penguin
09/09/07 16:02:22 KqXlaO+k
>>761
btrfsprogs0.19で作ったファイルシステムは、2.6.30以前のカーネルでは読めなくなるらしいね。

763:login:Penguin
09/09/07 16:37:30 usSRMi9H
btrfsがデフォルトのファイルシステムに採用されるのはいつごろになるのだろうか

764:login:Penguin
09/09/07 17:11:34 iBhE16g8
btr熟成がもっと進んでヨーグルトfsかチーズfsになる頃じゃないの?


765:login:Penguin
09/09/07 17:16:17 x4HLPBqD
つまらん

766:login:Penguin
09/09/07 18:06:27 EXMiBcjf
まずまずだとおもた

767:login:Penguin
09/09/07 23:23:30 lwFYYS2f
>>755
>>756
>>759
ありがとう。ファイルシステムの安定性・信頼性に関しては、
これっていうベンチマークとか評価手法をWebで見付けられないんだよなぁ。
各社さんの貴重なノウハウだから、タダで表には出てこないってところかな?

768:login:Penguin
09/09/08 22:17:56 oPYlyRcA
>>764
なるほど。最後はMILFsに(ry

769:login:Penguin
09/09/08 23:05:54 xzM1y3n7
Network File System を導入したいのだが、今からやるならどれがオススメかな?

NFSはメジャーだけど、アクセス管理がアレゲなので面倒。
WANからも利用したいから、なるべくセキュアなものがいいんだが。。

770:login:Penguin
09/09/08 23:13:18 KlcQeG0P
>>769
pohmelfs

771:login:Penguin
09/09/09 00:33:19 g3D+JiDv
>>770
ありがとう。
さっそく人柱になるよ。

772:login:Penguin
09/09/09 01:28:06 NYs3AwwP
Linux kernel watch
SSDをめぐる議論に浮かび上がるベンダ模様
URLリンク(www.atmarkit.co.jp)

TRIMなんてアテにしてなかったけど使い物になるならそれはそれで良きかな



773:login:Penguin
09/09/09 01:45:35 kDa2N0cK
個人的には、書き換え可能回数がHDDより何桁も低い今の時点では、
単純に選択肢にならないから、どうでもいいけどね>SSD絡み

774:login:Penguin
09/09/09 02:19:23 Q3Oe4C5K
>>772
> また、所要時間はTRIMの発行数に比例するが、1つのTRIMで消すサイズにはほとんど比例しないそうです。
> 彼によると「rm -rf /usr/src/linux」はTRIMで30分以上(!)もの時間を費やすけれど、
> 50GB+のシングルエクステントは消去するのに数秒しかかからなかったとのこと。
クソワラタ
カーネルソース削除で30分って、TRIM実装すんなって言われて当然だろ

とりあえず実装してしまって、クソハードに「windows専用」のレッテル貼ってしまうのも手だと思うけどな


775:login:Penguin
09/09/09 04:52:05 ol4Nzc2Z
SSDは発展途上なうえにBIOSアップデートできるってことが問題をややこしくしてるな。
OSSなBIOSがあればもっと話は簡単になりそう。

776:login:Penguin
09/09/09 04:53:04 ol4Nzc2Z
あ、ミスった。
BIOS→ファームウェア

777:login:Penguin
09/09/09 05:31:48 PAQMReSq
SSDコントローラのRAMケチってるからこういう事になるんだろう。
安くするためにそうなるのはわからんでもないが…


778:login:Penguin
09/09/09 18:52:07 XVGdMI4v
>>777
SSDの価格を考えると、
数MBのキャッシュがコスト的に問題になるとは考えにくいが・・・。


779:login:Penguin
09/09/09 19:07:23 9Mpz0HQd
SSD側のキャッシュをいくら増やしても、数万のファイルを削除したりすれば詰まる。
フラッシュメモリの特性なんだからしょうがない。
それを上手に隠蔽するためにも、コントローラ側の改善とSSDに適したFSが望まれる。

780:login:Penguin
09/09/09 19:10:48 XVGdMI4v
>>769
俺も遠隔地とのnfsの代替手段探してるんだ。
期待してるぜ。

781:login:Penguin
09/09/09 19:54:55 g3D+JiDv
>>780
いまカーネルコンパイル中。
君も人柱となれ!

782:login:Penguin
09/09/10 00:05:56 dK4dgFZW
>>769
セキュアが好きなら Kerberos と AFS でも使っておけば・・・まあ人柱が好きな人には勧めないが

783:login:Penguin
09/09/11 23:52:53 I4yrGSQ+
sshfsとかはどうよ?
パフォーマンスはショボイだろうけどセキュアだろう。

784:login:Penguin
09/09/12 00:01:26 iI00hN0z
>>783
SFTPの仕様上、使えないシステムコールもあるのが残念だった。
たとえばlink(2)を呼び出すと Not Implemeted と言われる。

785:login:Penguin
09/09/12 00:24:21 pOS/oIpq
難しいこと考えずにNFS over VPNでいいやん。

786:login:Penguin
09/09/12 18:04:04 UBFPOEoW
>>785
現状そうしてます。
速度も結構出てる。
そう言えば、fscached が動かないんですよね・・・。

787:login:Penguin
09/09/14 03:08:03 ueK3wYLx
NILFS2、スナップショット機能が良いな。
でかいファイルを作成する時間はext3の2倍弱ぐらいかかるけど。

788:login:Penguin
09/09/14 12:20:29 N9qSdTFh
追記式だからSSDに向いているしね。GCが実装されるまでは完全におもちゃだったけど、
GCが実装されてからは、SSDの普及もあいまって、いきなり実用的になっちゃった。

789:login:Penguin
09/09/14 22:23:25 A/G7rJlM
NILFS2でサーバ運用してる人とかいるの?
安定性や不具合はどうなんだろう?

790:login:Penguin
09/09/14 23:11:21 vbkhczLA
>>789
サーバ運用はしてないがSSDのノートでNILFS2使ってたらどこかのマッピングが
壊れたのか、ディレクトリが読めなくなったり mount できなくなったりした…



791:login:Penguin
09/09/15 18:17:39 SX8MjkBW
>>790
バージョンは?

792:login:Penguin
09/09/16 00:50:33 2te4vzEX
>>791
Kernel 2.6.30 で nilfs-utils-2.0.13

mount できなくなってたのは / の inode が壊れてたぽいんだよね。
bogus imode って出てたし


793:login:Penguin
09/09/16 07:20:35 nI44nyRO
>> debian スレから誘導された人へ
ext3 で良いじゃん。
仕事のメイン環境が Linux で、nVidia とか VMware とか、
プロプリエイタリなドライバ入れることもある私としては、
奴らが試験に使っていそうで、一番枯れていそうな ext3 が良いと思っている。
(あくまで推測なのが悲しいけれど、RHEL のデフォルトなんだから試験してるだろ。)

ヒトバシラーになってみたいとかパフォーマンスがうんぬんとか、
そういう方はこちらのスレにお住まいの皆さんと交流してください。

>> スレの皆様
下記のような経緯で見知らぬ奴らが来るかもしれません。遊んでやってください。
スレリンク(linux板:306-352番)


794:login:Penguin
09/09/16 10:12:22 ZTeRHZXm
お騒がせしました・・・
自治厨房はコチラで引き取りますので・・・

795:login:Penguin
09/09/16 13:58:10 3J121Znd
reiser4がいつのまにか-mmツリーから消えてる

796:login:Penguin
09/09/16 14:15:36 RJIgMBey
>>795
URLリンク(userweb.kernel.org)
へ移動しますた。

誰か骨を拾ってあげてくらはい。


797:login:Penguin
09/09/16 19:39:23 UJcLYraY
Reiser3もSuseに見捨てられたしいつまでmainlineで使えるかわからんな。
そのうちext4にでも移行するか。

798:login:Penguin
09/09/16 21:26:31 uGxSPoco
fsの各操作のボトルネックになる性能指標ですが、bonnie++だと以下を読む感じで正しいですか?
ファイルのfs内移動 → Sequential Create/Random Createのcreate/deleteのうち最低値
ディレクトリリスティング → Sequential/Random Createの Read のうち低い方

5TB3000万ファイルほどで、ディレクトリリスティングと
ファイルの移動が多いので上記のような基準で検討していまして、
いまのところreiser3が最有力なのですが問題ありそうでしょうか?

799:login:Penguin
09/09/16 22:52:50 Tl/wx3w4
どのカーネル使うのか知らないがreiser3はやめとけ。スケールしない。
あとマウント時間が分単位。

800:login:Penguin
09/09/16 23:27:09 V6HHYy1n
移動したのでID変わります

>>799
スケールしないというのは容量?速度?
容量でしたら8TBに達するのはずいぶん先に見積もっていて(増加ペースが鈍い)、
先にリプレースが来そうなのであまり問題視していません。
速度ですと、約100万ファイルまで増やしながらテストした際に最も
遅くなりづらかったのがreiser3という結果が出たので…。何か変なのかな…。

マウント時間が分単位というのも、自宅用ファイルサーバで
立ち上げっぱなしなので起動時のみの時間ペナルティと判断しています。

いろいろ後出しですみません

801:login:Penguin
09/09/17 08:41:23 lwWWpZYR
マウントそんなにかかるか?ジャーナル処理してるんじゃないの?

802:login:Penguin
09/09/17 09:14:43 imVaodyK
>>800
スケールしないのはコンカレントアクセス。
個人で使うならいいんじゃないの?

803:login:Penguin
09/09/17 09:23:17 8K0Ea6hu
>>801
2TBのボリュームをReiserFSで使ってるけどマウントは5分くらいかかるよ。

804:login:Penguin
09/09/17 10:18:03 eygHzDXf
マウント高速化パッチがあったような気がするけど取り込まれてなかったのか

805:login:Penguin
09/09/17 23:42:40 hqfb/bz2
>>802
BKLか、了解ー

806:login:Penguin
09/09/18 21:00:52 fWyof+eR
おいおいBKLは関係ないだろ

大体からして、CONFIG_PREEMPT関連がカーネルに導入された経緯のひとつに
BKL処理の効率化があった事はあまりに有名

未だにジャーナルの処理に一々BKLかけるReiserFSは
今、あえて選択する必要のないFSではあるけど
BKLのせいで並列アクセスがスケールしないとか言うのであれば大間違い
そもそもBKLがどうやって処理されているのかソースを読んで理解すべき

つーか、今は亡きCK kernelが、どうしてext3とReiserFSだけを推奨し、他を非推奨にしたのかをもっと考えるべき
CKがパッチの提供を辞めてから、色々とLinuxで使えるFSも増えたし、改良もされたけど
俺は未だにext[34]とreiser[34]以外のFSはクソだと思っているよ

807:login:Penguin
09/09/18 23:29:04 lWlnTusC
もっと考えるべき
とか
読んで理解すべき
としか言わない奴は十中八九自分では説明できない

808:login:Penguin
09/09/18 23:29:47 cB7i7bsS
それ以前に糞も味噌もいっしょくた

809:login:Penguin
09/09/18 23:42:30 lWlnTusC
よく見るといつものアンチXFS厨か?

810:login:Penguin
09/09/18 23:59:15 BrKFjTEP
いつものww

しらんがな

811:login:Penguin
09/09/19 00:04:18 LBONijMH
単発だし間違いなさそうだな

812:login:Penguin
09/09/19 00:26:49 YH6i3rVh
オヤジ!いつもの!

813:login:Penguin
09/09/19 00:51:48 ZNMyo7Z+
>>806
あの頃はデスクトップではUPが普通だったから、マルチコア時代の現代とは単純に比較できないような

814:login:Penguin
09/09/19 04:05:10 nzH+YeBA
>>812
トンスルお待ち!

815:login:Penguin
09/09/20 13:19:53 wV9s5HBg
>>803
300GBの話で参考にならないかも知れんが一連の起動時間全体で20秒くらいです。
mkfsのパラメータやマウントオプション、ハードウェア、いろいろあるけど
きっと君は間違ってるw

816:login:Penguin
09/09/20 13:25:28 7/vSTIy+
300G→2Tで20秒が5分になる
これを「スケールしない」と言います

817:login:Penguin
09/09/20 14:18:12 C1QJ3cI8
reiserのマウントの独特のシーク音は好きだったけど、
パーティションがでかくなるとそういう弊害もあるんだなw

818:login:Penguin
09/09/20 14:30:24 Lx3Z4LGX
2Tのパーティションとかブロックサイズどのくらいにしてるの?
というか、未だに1セクタ512バイトが最小単位なのか。。

819:login:Penguin
09/09/20 14:38:49 wV9s5HBg
スケールしない
スケーラビリティがないこと
キャップしない
キャパビリティがないこと
リライしない
リライアビリティがないと

訳のわかんない事いうのやめようよ・・
もうすでに標準なの?

820:login:Penguin
09/09/20 14:39:52 Lx3Z4LGX
動詞もあるよw
URLリンク(dictionary.goo.ne.jp)

821:login:Penguin
09/09/20 17:41:51 OY0QxSDJ
>>816>>819>>820
キャップしないって何だよwそいつはお断りだ

しないとできないは違う
信頼しないのと信頼性がないのは違う
スケーラビリティで使われてるのは拡大縮小可能もしくは比例しうるって意味。
スケールしないは比例しないの意味だろうが
比例しないって書けよ
チェンジとかスイーツとかファイルシステムとか
なんで片仮名ばっかり使うのバカなの死ぬのw?

822:login:Penguin
09/09/20 18:43:19 YJrAu4JI
そこで鼠型入力装置ですお

823:login:Penguin
09/09/20 20:38:21 W9OGi4v1
鍵盤型入力装置ですね

824:login:Penguin
09/09/20 20:48:48 6W0WwjBm
田宮1/35比例しない独逸兵下士官乙

825:login:Penguin
09/09/20 21:12:08 YJrAu4JI
カタカナ語というのは同字異義語を増やさないための知恵なんじゃないかと思った。
敵は正確な発音ならカタカナではこう厨。

826:login:Penguin
09/09/21 08:53:39 6BBUoYSs
>>825
ヘプバーンとヘップバーンとヘボンは異字同義語

# mkreiserfs -t 512 -h rupasov /dev/sda9
mount -r reiserfs /dev/sda9 /hoge/hage -o noatime,nodiratime,block-allocator=border,data=writeback

2chブラウザとログ置き場をこれにしてみたら、うっひょー。
マジおすすめ

rupasovはハッシュがダブるって書いてあるが実際にどうなのかしばらく試してみる。
ライトバックなのは2chログだから。

効果は不明だが
manの表記が不正なんでこう書かないとブロックの割り当てが変更できない。
block-allocator=border (hashed_relocation, no_unhashed_relocation, noborder)
URLリンク(web.archive.org)

827:login:Penguin
09/09/21 12:11:29 uDbg8rz1
>>826
スレチですまんが2chブラウザは何使ってるの?

828:login:Penguin
09/09/21 18:27:20 ChTxPFKE
>>799>>803
うちも360GBで参考にならないかもしれないけど
確かにジャーナルの最大サイズは100数十MBかもしれないけど
マウントって零コンマ何秒?ってくらいで全く引っかからないよ。

829:login:Penguin
09/09/21 18:42:30 B/OHxQzK
>>828
そのサイズだとまだまだだな
指数関数って怖いよな

830:login:Penguin
09/09/21 19:12:45 SXdmmE3S
>>829
ゑ? O(n)じゃなくて、O(n^2)すら超えてO(e^n) なの? なんでマウントに
そんなわけのわからんアルゴリズム使っているんだ?

831:login:Penguin
09/09/21 19:24:37 9q2aeNv/
>>830


л
л
пシ



832:login:Penguin
09/09/22 20:34:17 dZ+D1fmw
確実にファイル名が似通ってるから2chログ置き場をrupasovにしてみたんだけど
カーネルソース置いてコンパイルしてみたりしたが今のところ何ら異常はない。

俺は今後はrupasov使うわ。
reiser4は使ったことないけどreiserfs3と比べてどんな感じ?

>>827
V2C。

833:login:Penguin
09/09/23 11:19:44 hYkmayu9
>>627
意外とDB用途に最適かもよ?
URLリンク(ulfs.sourceforge.net)

834:login:Penguin
09/09/23 21:37:08 h2t+Bp3U
>>827
IDに決まってるだろ

835:login:Penguin
09/09/24 11:06:23 joayn3d8
log structured FSが最近勢いづいているのは何で?

836:login:Penguin
09/09/24 11:11:50 +QoMJhH9
nilfs2がマージされたからだろ

837:login:Penguin
09/09/24 11:20:13 9WTD7LOo
>>835
SSDで有利だから

838:login:Penguin
09/09/24 20:40:07 x6/1cqZT
>>834
JDじゃなくて?

今天的 Tetralet 又在????了
URLリンク(tetralet.luna.com.tw)

ちょっと前に会社で停電があってreiserfs使ぅとったのが立ち上がらんようになってしもたんや。
fsckしたら直ったけど冷や汗もんやな。
reiserfsの悪い評判とも関係あるけど。こんな事もあるんやなって身に染みて分かったわ。
で、結局何がえぇんよ?
半日ググったけど自分で試してみるんが一番ってことで。

839:login:Penguin
09/09/24 23:26:23 +0yImHYg
で、reiserfsのマウント時間が容量の指数オーダーというのはガセなの?
ほんとならソースくれ。


840:login:Penguin
09/09/24 23:29:36 oepUEYYM
ガセというか、落とし方やそれまでの稼働時間にも拠るんじゃね?


841:login:Penguin
09/09/25 00:10:23 8lp7KrzM
nがFS全体のサイズでなくてジャーナル領域のサイズとかだとしても
指数オーダーてのは直感的に想像できない。そんなだったらとっくに死滅してるはず。
>>829が指数の意味を誤解してるんだろう。


842:login:Penguin
09/09/25 00:24:02 If6aiUCb
組合せ論的爆発

843:login:Penguin
09/09/25 00:27:44 DlSn0Qec
芸術的爆発

844:login:Penguin
09/09/25 10:08:45 kIBKD3uE
>841
指数かどうかはともかく、直線的にスケールしないってのは普通にあると
思うけどな。問題はその程度って話でしょ。


845:login:Penguin
09/09/25 10:47:21 i8/4OJv9
reiserfs3は普通の環境で最大値は
ブロックサイズ4096、ジャーナルサイズが32749ブロック、トランザクションが1024ブロック。
これが*TB規模になると問題になるのかもしれんが。

マウントもリプレイも速すぎて目で追えないんだが遅いってか?
5分もあったらデスクトップ出してからリブート2回できるっちゅうに。
>>838でもマウントが遅いって書いてある。これはきっとアンチreiserfs厨の罠だな

NILFS2使ってみた。速度を求めるものではないが使う分には遅さは感じない。
遅い印象があったけどそのせいで逆に速く感じた。jfsと一部の特性取り替えたような感覚。


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch