ファイルシステム総合スレ その10at LINUX
ファイルシステム総合スレ その10 - 暇つぶし2ch700: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と一部の特性取り替えたような感覚。

846:login:Penguin
09/09/25 11:02:40 QNISpLjD
5年程前に5TBのreiserfs3の運用経験から。
リブートは年1回だがな。

847:login:Penguin
09/09/25 11:22:37 8shufhsA
ext4フォーマットで使ってる人、感想を書いてくれ。

848:login:Penguin
09/09/25 11:29:07 kIBKD3uE
5分で2回もリブート行けるような小規模環境なら、何使っても大して変わらんでしょ。
うちのサーバはOS読み込み前のハードウェアチェックなんかだけで3分から5分は
かかるわ。


849:login:Penguin
09/09/25 11:30:43 hnnN3qZg
>>847
特になし

以上

850:login:Penguin
09/09/25 11:45:19 8lp7KrzM
マウントのときジャーナル領域をソートでもしてんの?
O(nlogn)くらいの。

851:login:Penguin
09/09/25 11:48:09 H6F4VVWn
>>847
たまに、ext2/ext3を前提としたコードがコンパイルできない。
それ以外はext3と同じ感じ。

852:login:Penguin
09/09/25 21:29:55 7i3jmdwD
>>687
FreeBSDのZFSが使い物になると宣言されましたよ。

853:login:Penguin
09/09/26 04:31:20 IigKfcmL
OracleがSunを買ってから、本当にbtrfsの話題が減ったなぁ…
NIFLSのほうが話題多いんじゃないだろうか。このスレに限らず。

>>852
URLリンク(gihyo.jp) ですな。

ただ、OpenSolarisのZFSはL2Arc URLリンク(blogs.sun.com)
なんていうSSDをキャッシュに使う機能なんていうのも実装されて、
ますます進化しているけど。

854:login:Penguin
09/09/26 10:02:46 6/kVht60
835> URLリンク(blogs.sun.com)
ZILは高頻度でsync()するアプリケーションに効くよ。
emacsはデフォルトでファイルを書くとsync()してくれるから
ZILでmewが速くなった。


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