/**ファイルシステム総合スレ その3**/

前スレのSCSIケーブル引っこ抜き問題に対する
パッチがlkmlに投稿されているね。
http://www.uwsg.iu.edu/hypermail/linux/kernel/0501.0/0614.html

誰にCc:してるのかわからないけどコメント付かないね。
日本人の英語なんて、誰も読みたくないのかな。

パッチで修正される個所↓のような返り値見てなさっぷりにワロス

diff -Nru linux-2.4.29-pre3-bk2/fs/ext3/fsync.c linux-2.4.29-pre3-bk2_fix/fs/ext3/fsync.c
--- linux-2.4.29-pre3-bk2/fs/ext3/fsync.c 2002-11-29 08:53:15.000000000 +0900
+++ linux-2.4.29-pre3-bk2_fix/fs/ext3/fsync.c 2005-01-04 19:58:32.000000000 +0900
@@ -69,7 +69,7 @@
if (test_opt(inode->i_sb, DATA_FLAGS) == EXT3_MOUNT_WRITEBACK_DATA)
ret |= fsync_inode_data_buffers(inode);

- ext3_force_commit(inode->i_sb);
+ ret |= ext3_force_commit(inode->i_sb);

return ret;
}

>>184
うひゃ。commitを失敗すること考えとらんのか。
ext3って一時が万事この調子でコーディングされてそうで怖いね。
って、ext3に限らずこんな調子なのかなぁ。

LinusがSolarisなんて参考にならんなんて豪語しとるけど、
ttp://japan.cnet.com/interview/story/0,2000050154,20079899,00.htm
2.6になってもNFSでkernel panicだとか、ext3のこのコーディングだとか、
とても自慢できるような状態じゃないぞ。

たしかにSolarisを参考にしたところでなおらんわな(w

ちなみに、2.6のfs/ext3/fsync.cのext3_sync_file()を見ると
int ext3_sync_file(struct file * file, struct dentry *dentry, int datasync)
{
struct inode *inode = dentry->d_inode;
int ret = 0;
J_ASSERT(ext3_journal_current_handle() == 0);

if (ext3_should_journal_data(inode)) {
ret = ext3_force_commit(inode->i_sb);
goto out;
}
if (inode->i_state & (I_DIRTY_SYNC|I_DIRTY_DATASYNC)) {
struct writeback_control wbc = {
.sync_mode = WB_SYNC_ALL,
.nr_to_write = 0, /* sys_fsync did this */
};
ret = sync_inode(inode, &wbc);
}
out:
return ret;
}
ってな感じで大きく書きかわっている模様。2.6のext3は一から作り直した
という話が実感できるなぁ。

あのう、件のパッチですが、
2.4.x系へのパッチはfs/ext3またはfs/jbd以下なのに対して
2.6.x系へのパッチはfs直下なんですが…これはどう考えたら…

>>188
fileの置き場所が変わったという話ではなくて？

>>189
2.6.10-bk6へのパッチでは
fs/buffer.cのfile_fsync ()
fs/fs-writeback.cのwrite_inode_now ()
fs/inode.cのgeneric_forget_inode ()
fs/jbd/commit.cのjournal_commit_transaction()
が書き変わり、include/linux/fs.hでwrite_inode_now()がvoidからintに
変更されているわけだけど、これって他のfsにも波及するんじゃないかって
ことでそ。

Filesystem 1k-blocks Used Available Use% Mounted on
/dev/md0 2068476 610616 1352788 31% /
/dev/hda2 21958 3404 17420 16% /boot
/dev/md1 3102836 288668 2656552 10% /var
/dev/md2 13624648 13166756 0 100% /home

使用率が100％になってしまいました。
原因は、root のメールボックスが一杯になっていたためで、dele コマンドでメールを全部削除して、
システムを再起動してみたんですが、上記に変化はありません。

du で調べると、root のメールボックスのフォルダ以下のサイズは減っているんですが・・・
ファイルの更新ができなくて困っています。
どうすれば良いのか教えて下さい。

釣りですか？

ちがいます。
本気で困っています。

>>193
rootのメールボックスとやらは、/root以下にあるのではないかな？
/homeが100%になってるのに、/root以下を削除しても、意味ないのではないかな？

>>194
root 管理者のことです。
よくわからないんですけど、システムで何かあるとメールが送られてくる奴です。
/home の下にあるメールボックスです。
今も調べていますが、何も改善されません・・・

普通は、rootのメールボックスは、/root以下にあるものなんだけどね。
移動したの？

ただ単に、ファイルがいっぱいなんじゃないの？
普通に不要なファイルを消せばいいと思いますよ。

/dev/md2 13624648 13166756 0 100% /home
見る限りは、きっちり100%ってわけじゃないと思うよ。

 

>>196

FTPでファイルをアップロードすると

452 Error writing file: No space left on device.

と出続けてしまいます。
小さいファイルなんですけど。

iノードの数は？
df -iしてみて。

Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/md0 262752 46064 216688 18% /
/dev/hda2 5688 26 5662 0% /boot
/dev/md1 394400 4082 390318 1% /var
/dev/md2 1733312 390146 1343166 23% /home

これでいいですか？
ちなみに、その後も、少しファイルを削除しました。

エラーメッセージが出ると同時にsyslogにも何か記録されてるかも知れないから、
/var/log/messagesとかチェックすると何か分かるかも。

>>191
これのいったいどこがfsスレの話題なんだ? しかもageてるし。まったくバカの
やることときたら…

/dev/md2って、ソフトウェアRAIDですか？
rootへのメールになんて書いてあったんだろう。

>>200
ログからは何も得られませんでした。

>>201
じゃあ、ファイルシステムってどういう意味？

>>202
違います。

du すると、途中でとまってしまいます。
大きなファイルが見当たらないのですが、どうしてなんでしょうか・・・

>>202
RAIDはファイルシステムじゃないですから！

>>191
もうちょっと勉強したらどうだ?

もしファイルシステムの定義が知りたければ、カーネルソースの
Documentation/filesystems/　以下のファイルを読むべきだろう。

du -s かけてほっとけ

/homeのパーティションをnewfsしたら0%になる。

>>203
ＲＡＩＤじゃないとしたら、何？

ソフトウェアRAIDのデバイスは、通常/dev/md?で表されます。
とＬＰＩ認定試験で出てたけど。

>>208
知能障害者は放置放置

知らないなら、黙っててもらいたいのですが。

（　ﾟдﾟ）ﾎﾟｶｰﾝ

釣り堀はここでつか？

>>210
そちらさまこそ知らないなら黙ってて下さいな＾＾
すれ違いな上、板違い。知能障害に付いての相談なら人生相談板にGo。

206と210のIDが同じに見えるのは漏れだけ？

自殺自炎乙

おれは携帯からiMonaで書いたぞ。
初期設定のサーバ使ってる。

よかったね

>>191は初心者スレ行けよ。

(;:. @�u@)　
http://www.netjapan.co.jp/FAQ/PQ_solutions/101-200/sol152.html

2.6.11-rc1-mm1にマージされたFUSEのネタは出てこないんかいな
http://kerneltrap.org/node/4546?

userspaceのfsかぁ

filesystemじゃあなくて、block deviceをuser spaceに持ってくる
方法ってあったっけ？

raw device
問題はcachingの方。

>>220
FUSEの使用例
ttp://richard.jones.name/google-hacks/gmail-filesystem/gmail-filesystem.html

若干古い資料だが、NTFSとの比較テストなどものっている。

http://www.osdl.jp/newsroom/events/event_ks4.html/document_view

「ジャーナリングファイルシステム比較」（資料）
講師：株式会社野村総合研究所 システム技術部 システムエンジニア 西村 崇 様
http://www.osdl.jp/osdl/docs/ks4-200304/ks4_jfs.pdf

>>225
この結果からすると、ext3は突出した性能はないけれど不可も少ない、
ということですかね。
ま、ジャーナリングの性能だの信頼性だのは個々の環境で判断すべきで、
他人のテストの結果なんて役に立たないのだけど。

>>225
漏れは去年の今頃の2.4カーネルでJFSに嵌まってた。
穴は塞がってなかったのかな。
今は全部XFSにしたのでどうでもいいけど。

JFS人気無いね

期待だけはしてるよ

reiser4は心元ないし
xfsはｲﾔﾝだから

>>229
なんでXFSｲﾔﾝなの？

>>226 でも人によってジャーナリングの信頼性が揺らぐようじゃ
ファイルシステムとしてどうかと思うぞ？

2.4.18の頃だったか、JFSのパーティションを自動
タイプ認識でマウントしたら、reiserfs
だと認識されてしまって、巻戻しが始まって
エライ目にあったな。
おれが操作したんじゃないし、おれのデータでも
なかったから、まぁ他人事だったんだが。

ええ〜そんなことがあるのか。
こわ、ちゃんとファイルシステムを指定しようっと。

>>230
昔から根拠を示せないアンチXFSが生息。

俺がXFSを使わなかったのは、カーネルの再コンパイルが面倒くさかったから。
今使ってないのは、惰性。
ほとんどの奴はそうじゃない？

>>235
XFS使ってるが、kernelにマージされる前は一生懸命手パッチあててkernel作ってたな。
今ではそんなことないけどね。

>>235
漏れはPBRに入れたブートローダを壊されるらしいので使ってない。
まあTB級のHDD使ってる訳でもないし、GB級のファイルを扱う訳でもないし。
それにエラーセクタの回避できないから。

このマシンの寿命がくるまでにReiser4あたりが安定してくれりゃ万々歳、ってとこ。

＞PBRに入れたブートローダを壊される
その考えは逆だよ

>>238
ん？まさかPBRにブートローダ入れるとXFSの方が壊れるとか？

PBRｗ

>>237
その情報元がソフトウェアRAIDパーティションのPBRと間違えてるんじゃ、

>>241
http://oss.sgi.com/projects/xfs/faq.html
>Q: Does LILO work with XFS?
>This depends on where you install LILO.
>Yes, for MBR (Master Boot Record) installations.
>No, for root partition installations because the XFS superblock is written at block zero, where LILO would be installed. This is to maintain compatibility with the IRIX on-disk format, and will not be changed.

XFSはPBRも使ってるからインストールしちゃ駄目よ
IRIXとの互換性を維持したいから仕様が変更される事はないよ(超意訳)
って事じゃないの？。

LILO捨ててGRUB使えばいいって話じゃないの?

キミは実に莫迦だな

>>243
>>157 で既出だがXFSの欠陥のようだ。
XFSの partition には boot loader を入れてはいけない。

>> 234
TBのパーティションを作ってるので、XFS使ってます。
他のFlieSystemはあまり実績が無い。(reiserfs, jfs)
マウントに時間がかかるExt2, Ext3 は論外。

って以前書いたんだけど、スルーされたのか。

>>242,245
XFSにそんな特徴があったとは知らなかった。
俺にとって、RAIDとはソフトウェアRAIDなんで、
XFSには極めて大きな欠陥があるのも同然だ。

>>242
ソースの変更は絶対に簡単な筈だから、PBR使用しないように変更すれば
いいのに、

Persistent Superblock はパーティションの一番後ろだぞ

>>245-246
そんなに片仮名で書くのが嫌なのか。

>>248
>>246は非常に誤解を招く書き込みだった。
一応、俺もソフトウェアRAID（ミラー）の
パーティションからbootしてます。

でも、ソフトウェアRAIDパーティションでPBRの破壊を何度か
経験してるんで...

SATA導入記念に/をReiser4にしてみた。

WARNING: Keys are inconsistent. Fsck?

二日目で起動中にエラー、ログイン出来ず。orz
2.6.11-rc1-mm1 debian reiser4progs 1.0.3-2

なんで2.6.11-rc1-mm1なんか使ってるの？

Fuck?

に見えた
欝だ死のう

>>252
手っ取り早く使えると思ったんで。ググったら
http://www.xy1.org/[email protected]/msg02154.html
半年前か…

スレ違いだが、
>>253
BE付いてるけど、クライアント何使ってるの？

今のところ、XFS以外の選択肢がない。
JFSはぶっ壊れた事あるし怖い。

自分がたまたま壊れたからもう使いたくない、
ってのは心情的によく分かるけど、実際分からんよな。
その壊れたfsがbrokenなのか、今まで一度も壊れたことが無いfsが安全なのかは。

>>256
まあね。

JFSは前にも出てるけど、
拡張アトリビュートに対応してないからSELinuxがつかえない。
ext2,ext3,Reiserfs,XFS,tmpfsは対応してる。

XFSがカーネルツリーに入る前はReiserfsだったけど、何回か壊れた。

ついでにJFSはgrubでも何回かはまった(stage2がロード出来ない)から、避けてる。
別に悪いとは思わないけど、あえて選ぼうとは思わない。

なぜ、基本的にカーネルを置くだけの /bootを
XFSやJFSやReiserFSにして、対応しているだの
問題があるだの議論をするのか良く分からん。

カーネル(やgrub)をアップデートする時以外には
マウントする必要がなく(従って壊れることもない)、
容量も極めて小さい(のが通例の)ファイルシステムを
ジャーナリングしなければならないのか。

>>258
/bootを別パーティションにせず、/とswapしかパーティション分けないような人に
とっては重要。

jounalする必要は無いがext2である必要も無い。

ここはもうminixfsだな

ブートローダーの置き場所ならばファイルシステムである必要すらない。
拡張（not論理）領域の先頭だっていい。
まぁ素直にMBRに入れるのが無難さね。

MBRにgrub onlyは危険。
複数のOS入れてても、stage1_5(or 2)が置かれてるパーティションが壊れただけで全部起動できなくなる。
念のためパーティションの先頭にも入れとくべし。

>>263
grub（に限らずブートブロックで完結しないブートローダー）を使うならstage1をどこに入れようと
> stage1_5(or 2)が置かれてるパーティションが壊れただけで全部起動できなくなる。
だと思うけど…。
いざというときの保険ならブートローダー入りフロッピー(orCD)じゃないかな。

>>263-264
俺の場合、
MBRは必ずMBMを入れる。（簡単に入れ直しが出来る）
grubはraid1の両/に入れている。
その上、双方のgrub.confにはhdd1,hdd2両エントリー記述してある。（hdd0を取り外した時のために）

でも、grubインストール用CD（兼memtest、MBR補修、MBMインストール）も用意してるんで
本当は、PBRがいくら壊れても全然平気

>>257
何回か壊れたとあるけど、どのような状況で何回か壊れたのか
教えてもらえますか？

>>265
パーティションを壊したりできるようなもんをMBRには入れるのはチョット…。

>>267
どゆこと？MBMがパーティションを壊すとでも、

俺はMBM６年くらい使ってるよ。

パーティションテーブルを自由に弄れる区画エディタをすぐに呼び出せるMBMを〜
ってことじゃない？

そういうことをするような人がブートローダーの画面を触れるようなPCはどれ使っても同じだと思うけどね

>>269
なるほど、

>>269
パスワードを設定できたりすれば、また違うと思うけど。
悪意がなくても知識もない人も触るようなPCなら。

>>266
2.4/2.5(2.6直前)で使ってた時、2.5で死んだり(Oops)すると、
2.4で自動復旧出来なかったりした。

一番つらかったのは、
壊れたのを直そうとしたら、bitmapがおかしいって事で
bitmapを作り直させたら、途中で死んでbitmapが完全に死亡。
無理矢理復旧したら(やり方はもう忘れた)ファイルは無事だけど、
名前がわからない状態になった。
しかもディレクトリ構造も殆ど残ってないから、ファイルを救い出すのに苦労した。
まあ、これはext2/3でも同じか。

マウント時に必ずジャーナル見るんで、
ジャーナル領域にbad blockが出来ると終わりな事かな。
カーネルいじってジャーナル無視させたけど。
XFSはまだbad block出来た事がないのでわからん。

今はカーネルツリーに入ってから時間経ってるし、普通に使ってれば平気じゃない？
最近設定するマシンはXFSだけど、Reiserfs使ってるマシンも問題ないし。

>>272 マウント時に必ずジャーナル見るんで
nointegrityオプション使ってもだめ?

ごめんJFSと勘違いしてた。

一応xfsにもnorecoveryってあるよ

>>184みたいに、戻り値をチェックする/しないってのは、
結局動作させてみて、問題が発生するかどうかを見るしかないの？
全ての戻り値をチェックしてたら、処理の手間が増えるだけで、
いいことはないわけじゃん。

>>276
コミットという処理がどういう処理なのかお勉強して出直すこと

>>276 チェックしないほうが怖いと思う。

まぁいちいち戻り値をチェックするのを書くのは面倒ってなら、
アプリケーションレベルのコーディングでは例外処理を使うんだろうけどね。
カーネルレベルでそんなの使いたくないし。

NFSv4とCIFSってどっちがいいの？

CIFSは仕様が公開されてない。

またまたご冗談を

>>279
CIFS

>>281
何で冗談なんだよ

276=281=しったか包茎

漏れ=ニート方形

CIFSのドキュメントってこれだけ？
http://www.microsoft.com/mind/1196/cifs.asp

これで一同簡単なデータ構造なんかもこれで見れるけど。。。
CIFSの仕様は金払えば見れるらしいけど、それは
ストレージ業界を意識してのものなのかな？

>>286
ttp://www.snia.org/tech_activities/CIFS/CIFS-TR-1p00_FINAL.pdf

>>287
サンクスコ。

>>287
これは各社集まってリバースエンジニアリングしてつくった仕様じゃないの?
それともInformationalになる予定のRFCに結局全部載って、同じものなの?

Microsoftは昔から一部だけ公開して「うちはオープン」って言うのが得意だけど、
CIFSがそうでなくなったなら好ましいことです。

Griswold & GoodmanってMicrosoftの人がco-authorだね。

なんだってー(AA略

タコな質問ですが、ディストリごとにお奨めってあると思うけど
代表的な物は素で選択可能なのかな？
ここしばらく新規で入れてなかったのでext3以降の情報がさっぱりなのです…。

>>292
ディストリによっては選べる。

Debian 厨の俺が宣伝する。
Debian はいろいろ選べる。
Debian 厨の俺が宣伝した。

Ｒｅｉｓｅｒ４使いたくて仕方ないんだが、
わかりやすい説明がみつからなくてなんか面独裁

>>295
迷わず使えよ。
使えば分かるさ。

>>296
設定方法がわからなくて使えません！
ひろしです。。。

>>296-297
>>295は先日Fedoraスレに現れた厨房だよ。感覚が世間ズレしてる

>>293
おっすおっす色々試してみます。おっすおっす

>>298
はあ？

【合併】新市名に異論続出 中田(なかだ)市、後田市、奥手市……
http://tmp4.2ch.net/test/read.cgi/bakanews/1107737935/l50

Protected and Persistent RAM Filesystem
http://pramfs.sourceforge.net/

linuxじゃないがExt2fsdに入ってるumount.exe
umount c:
が出来ちゃってびっくりだよおい

CD-ROM File System
CDFSを使ってまっさらのＰＣでＣＤ−Ｒを起動させたいんだけど・・・
このシステムファイルってどこにあるの？

>>304
libiso9660かな?

>>304
ブート可能CDを作りたいんですがどうすればいいですか?
ってこと?

CDFSってマウントするとセッションごとのISOイメージがポコッと置いてあるように見えるんじゃなかったっけ？
それとまっさらのPCで起動っていうのがわからん

>>305-307
多分単にブートするCDを作りたいだけだと思う

mkisofs

すんまそん、厨房的な質問ですんません。

ATAPI-HDDの一部のボリュームを切りなおそうと思っているのですが、
同じデバイスの一部のパーティションをマウントしている状態で、同じ
デバイスの別の領域に fdisk でボリュームを削除したり追加したりっ
てできるものでしょうか？

現在、/dev/hdb を増設ディスクとして使っています。
hdb1 ：誰かが使用中
hdb2 ：誰かが使用中
hdb3 ：バックアップ保存用なので、深夜バッチ処理しか利用しない。昼のうちに容量修正したい。

てな感じですが、どなたかアドバイスお願いします。

>>310
できません。fdiskで変更は出来るけど、カーネルにはリブート後に反映されます。
そういう事ををやりたければあらかじめディスクをLVMで管理しておかなければならない。

>>310
>>311の念押しだけど、
深夜バッチの前にリブートとフォーマットが出来ればOKということだよ

>>311 さん、312 さん
了解です。サンクスです。助かりました！

利用者にメイルして、今夜サービスを止めて fdisk してリブート、フォーマット、再マウントします。

>>313
別にそれでいいけど、

fdiskは今すぐできるよ。>>311をよく読んでね

>>314
補足サンクスです。ディスクのスライスはいまできるけれど、反映にはリブートが必要ということですね。
先に必要ないボリュームを削除して領域設定しておきます。ありがとうございます。

http://jfs.sourceforge.net/
>The JFS project is managed by a small,

MIB! MIB! MIB! MIB!

小人が管理してるの？

Turbolinux 10 Desktopで650M程のファイルをUSBの外付けHDに書き込んで
いる途中でマシンが不安定になってリセットかかりました・・・＿|￣|○
外付けHDはFAT32でフォーマットしてありましたがファイルシステムの一部が
壊れたのかLinuxでもWindowsで見ても沢山ゴミファイルができていて
しかもゴミファイルを削除すらできない状態です。
削除しようとしても「そんなファイルねぇぞゴルァ！」と怒られます。
どうしようもなくバックアップ後再フォーマットしましたがこんな場合は
どう復旧してます？fsck？

>>319
FAT32ならwindowsでchkdsk/scandiskじゃない？

>>320
もう何年かWindowsでディスクチェックしてなかった（する必要がなかった）から
すっかり忘れてた・・・
漏れって馬鹿・・・＿|￣|○

バックアップメディアとしてDVD-RAMを使いたいのですが無駄領域が少ないファイルシステムを教えて下さい。
条件
100KB程のファイルを50〜60個まとめて１つのディレクトリの中に入れています。
そんなディレクトリが大量にあって、合計4G程です。
このディレクトリ構造のままバックアップする。
月に2回位の頻度で1ディレクトリの中味を更新する可能性があります。
パーミッションは不用です。

ｱﾁｬｰ、正直に「エロ画像のバックアップ」と言えば回答があったかもしれないのに。

うpしてくれたら回答するのに。

エロ画像ってバックアップしたら
二度と見ないような気がする。

>>325
そうそう。HDDと運命を共にするデータってのもあっていい。

1995年のタイムスタンプのエロ画像今でもあるよ。
Mosaicでplayboyのサイトから落としてきたやつ。
昔はこんなのオカズにしていたのかと思うと感慨深い。
今では炉利画像でないと駄目なんだよな……

漏れのオカズ置き場ファイルシステムは
ext2→ext3→XFSだな。
やっぱり動画が多くなるとXFSは有利。
さーて関西援交で抜くか。

FAT32だろ。

まあFDDなら。

FDはFAT12

ところでおまいらreiserfs4は使ってますか。明日外付けのファイヤワイヤ
ハードディスクの250GB を買いに行くんだがこれをreiserfs4で使ってみる
つもりだ。age

勇者だな。

貴重なエロ画像が……

>>333

勇者必要だな。

勇者たちに質問です。
このたびLinuxでファイル倉庫を作ろうと思ってます。
いままでファイルシステムに無頓着だったんですが、ext3よりもreiserfsとかXFSというファイルシステム
の方が良さそうに思いました。HDDを4台でソフトウェアレイド5にしようと思ってます。
動画とか溜めるのにやはりファイルシステムは速度等考慮して、ext3以外のものを選択した方が、
後々違いが出てくる（有利になる）ものでしょうか？
一回倉庫を作ってしまうと、あとで変更するのが難しそうなので勇者たちにアドバイスをいただけたらと
思っています。m(_ _)m

Reiser4使ってるよ。もう7ヶ月くらい。
1.5TB RAIDアレイからLVM2でいろいろ切り出して運用してる。問題があったのは
ボリュームサイズ拡張してもファイルシステムのリサイズがうまくできなかったこと
くらいかな。でもLVMなんで空きをかき集めてそこにファイルシステム作ってデータ
移してから元の領域を解放して、みたいにして対処してる。
Reiser4の速度を知ってしまうと他のにはもう戻る気になれない。statの応答速度が
モロに効いてくるプログラムがぶん回ってるんで。

inodeサイズを2KBまで大きくしたXFS
ほんのりお勧め

そんなにファイルシステムで違うものですか。参考になりました。
いろいろと調べていると、Reiserfsが情報が多いようなので、ファイルシステムはそれで
作ってみようと思います。ありがとうございました。

ちなみにReiser4は、カーネル2.6以上のディストリしか対応してないですよね？
SUSEのFTP版があるようなので、そちらで試してみたいと思います。どうもです。

>>338
XFSももう少し調べてみます。どうもです。

>> 336=ID:w5/mqsWn
すまん。漏れは337の内容は332,333へのレスのつもりで書いた。

一つのディレクトリあたり数千個のファイルが転がってるような環境でReiser4は
圧倒的な優位性を発揮してくれている。これが数十個程度のファイルしかなくて、
ファイル一個あたりのサイズが数ギガなんて環境でも同様にReiser4が優位かどうかは
ベンチ取ったわけでもないので何とも言えない。
Hans Reiserがそんなタコな仕事をするとも思えないけど実際に使用・評価して
目的にあったものを選ぶのはユーザの責任なんで、そこんとこよろしく。

参考までに。Gentoo Linuxでmmなカーネルソースね。Reiser4で運用してるの。

丁寧にどうも。勘違いしました。
仕事で使うわけでもないので、何かあった時は、少し涙を流せばいいだけです。
消えて困るものは、バックアップは取っておきます。
おっしゃってることもわかってますので、違うファイルシステムも試してみたいという興味の上で、
実験をかねてやってみたいと思います。

おれが yamada-fs 作ったら使う？

>>344
特徴きぼんぬ

名前が reiserfs よりかっこいい。

Hans ReiserはちょっとDQNなのがなあ。

×ちょっと
○かなり
もっとも、Theoだのdjbだの上には上がいるけどね…

rms はどうよ

誰か知ってたら教えて下さい。

hostAとhostBの両方に/pubという同一名のディレクトリを作り、それをお互いにNFS等で
マウントさせて、片方のhostに書き込まれたファイルは、もう片方のhostにも書き込まれる
ようにする事は可能なのでしょうか？
ちなみに、NFSで試してみたところ、同一名のディレクトリにお互いにマウントさせる事が
出来ず、どちらか一方のみしかマウント出来ませんでした。
出来れば、フリーのソフトでそういった事が出来ると良いのですが･･･。
よろしくお願いします。

LesserFS

>>350
基本的な考え違いを起こしてるような気がします。

例えばsambaだとお互いからマウントできます。

しかし、たとえそのような状態でも
一度の書き込みで”両マシンそれぞれに直接接続されている物理ディスク”に同時に
書き込むことは出来ませんよ

そちらがやりたいことはネットワークを介したミラーリングであるような気がしますが、
両方でマウントしあってもそのようなことは実現できません。

>>352
補足です

NFSでもお互いからマウントできますよ
但しNFSはsambaと比べると多少制限がきついです。
例えばhostAの/usr/と/usr/localがexportされているとします。
これをhostB側でそれぞれ/usrと/usr/localにマウントすることはできません。（例が良くないですが）
（実装によって制限つきで可能な場合もありますが、一応これは出来ないとされていることです。）

でもとにかく一つのマウントポイントで読み書きできるのは一つのファイルシステムだけですから（当たり前
ですが）、マウントし合うことによって同時に二つのディスク（場所を隔てていてもいなくても）に書き込む
ことはできません。

もし実現できればディザスタリカバリに最適な手法ということになりますが

ネットワークを介したミラーリングってのは今のところ難しいです。
普通はLVMを導入して稼働中のバックアップを定期的にとることでそれに準じた効果を得ます。

hostBのバックアップを常にhostAにとっておきたいというのであればhostBをNFS-ROOT式にすれば良いと思います。
あるいはバックアップしたいpathだけをNFSにしてもいいと思います。

350はDBのレプリケーションみたいなことをやりたいわけか?

fdiskのソースコードってどっかにあります?

>>349
rmsの場合思想が過激だけど、DQNかというとちょっと違う気がする。
んまぁ、似たようなもんだといえばそうだけど。

rpm -qf `which fdisk`

>>355
util-linux

ありがと

>>350
ttp://www.jp.redhat.com/manual/DocAS21/RH-DOCS/rh-cm-ja-1.0/s1-service-samba.html

今は2.4系のカーネルでreiserfs使ってる。十分早いし満足してるけど
reiserfs4の噂を聞くと早くそっちに移行したい。2.6の-mm をmakeして
みたけどエラーがかなり出た。漏れのはvine2.1が元になってるシステム
なんでアップグレードしなくちゃいかんものが多過ぎ。2.4系で使えるように
なんねえかなあ。

>>350
つDRBD

両方からは無理だよな

クロスマウントすると管理面倒になるからやらない。最近の若いもんは普通にやるもんかね。

>>350自身からは一切レスがないようだな
だから>>350がどれくらいわかって書いたのかが全然わからん

クロスマウントすると、シャットダウンとか面倒だね。

/pubをAで作ってエクスポートして、
Bがそれをマウントするのじゃだめなの?
いまいちわからんな。
もしくは、AかBに適当にディレクトリ作って、
両方が/pubにマウント。

大きいファイルはxfsがいいとかよいとか

不用意にfsckして破損したファイルシステムを
ls -all ./
したら、ディレクトリなのに
?--------- ? ? ? ? ? .thunderbird
になってるディレクトリ以下(にあるInboxだけでも可)を救出する方法ってありますか?

アイドル時にHDDをスピンダウンさせてくれるファイルシステム探してます。
今JFS使ってるのですが、経験とソース斜め読みした感じですと、
ある程度(結構少ない)dirtyなデータが貯まると必ずHDDに書きに行くようで、
ntpdやらの書き込みだけでも結構な頻度でHDDが起きてしまいます。
ext3やらXFSやらはどうですか?

dirtyなデータをできるだけ早くストレージに書き出そうとするのは
まともなファイルシステムなら当たり前だと思うが。
頻繁に生じる書き込みをram diskに移す方が本質的な解決だと思う。

咥えて言えばHDDのスピンアップ/ダウンはHDDの健康にいいの?悪いの?
ってのはHARD系の板でよく議論になっとるね。宗教論争だが。
まあ>>369がやりたいってのなら、止める理由はない。

>>369

noflushd がありますよ。
バッファが満杯になるまでアクセスを控えます。
ディスクをスピンダウンさせる働きもあり。

他に bdflush でも調整可能ですよ。
書き込み間隔をとても長くすることで
近い効果を発揮します。
（　むしろ信頼性の観点から標準より短めに
　 するのが推奨されているけど。）


以上の様な方法でギリギリまで HDD を起こさずに
済みますが、停電したときのダメージが大きいので注意。
( もし UPS があるんなら余り心配ないけど。 )

早く reiser4 が標準カーネルに取り込まれないかな・・・。

MM パッチは自分の所では動作しないので、
reiser4 パッチを当ててる。
/ を reiser4 にするには結構な手間がかかるので
インストーラが reiser4 に対応して欲しい所。

漏れの所は、こんな感じ。

AGE=60000
DIRTY_RATIO=40
DIRTY_BACKGROUND_RATIO=5

echo 5 > /proc/sys/vm/laptop_mode
echo $AGE > /proc/sys/fs/xfs/age_buffer_centisecs
echo $AGE > /proc/sys/fs/xfs/xfssyncd_centisecs
echo 3000 > /proc/sys/fs/xfs/xfsbufd_centisecs
echo $AGE > /proc/sys/vm/dirty_writeback_centisecs
echo $AGE > /proc/sys/vm/dirty_expire_centisecs
echo $DIRTY_RATIO > /proc/sys/vm/dirty_ratio
echo $DIRTY_BACKGROUND_RATIO > /proc/sys/vm/dirty_background_ratio

ノートパソコンだと回転止まって欲しいときあるね。

>>373
今日/をreiser4にして入れたけど、
/boot切っちゃった。
grubが対応してれば、/一発でも行けるかな。

>>376
ｆtp://ftp.namesys.com/pub/reiser4progs/grub/LATEST_PATCH
人柱報告よろしくー。

>>377
最新patchじゃないけど試してみた。
kernelが2.6.10+reiser4-for-2.6.10-2、
grubがgrub-0.95-reiser4-20041021+手修正、
パーティションはswapと/(reiser4)のみ。

インストールして、grub入れるまではうまくいったけど、
起動時にstage2に行くところで探せない模様でresetがループする。

http://www.namesys.com/install_v4.html
この問題かな。

自分もGentooだけどreiser4早いねえ。
早く本流に入らないかなあ。

今 reiser3 使ってるんだけど、ext2 -> ext3 みたいな感じで
アップグレードできるの？reiser4に。

まぁダンプ→リストアすればいいんだが、面倒だ

>>380
reiserってダンプ/リストアできるの？
単にアーカイバを使う以外に方法がなかったような気がする。

そんなファイルシステムは嫌だ。

俺用メモ
http://www.jp.redhat.com/magazine/NO1/
XFSには、XATTRに関して1つ大きな問題があります。XATTRがiノードに収まらない場合は、1つのデータブロックごとに1つのiノードという形でデータブロックに格納されるのです。
mkfs.xfs のデフォルトの設定は、ブロックサイズが4096バイト、iノードのサイズが256バイトになっています（SELinuxのXATTRを格納するには、iノードが30バイトほど小さすぎます）。
つまり、デフォルトのXFSファイルシステムでは、SELinux のXATTRが1つのiノードにつき4096バイトを占めることになり、多くの場合これはディスク空間のかなりの部分に相当してしまいます！
XFSファイルシステムの作成時に“-i size=512”というオプションを使用すると、iノードのサイズが512バイトになり、SELinuxのXATTRがiノードに収まるようになります（スペースと性能の面で大きなメリットが得られます）。
また、512バイトのiノードにすると、明らかにその他の操作も少し性能が向上します。
XFSを使用する場合、もし将来SELinuxを使う予定があるなら、512バイトのiノードを使ってすべてのファイルシステムを作成しておくと良いでしょう。

2.6.12-rc1-mm4
- New resierfs4 code drop

Ext2Fsd 0.24 is released!

XFSにそんな罠があったのか。容量は余りまくってるから良いけど、
パフォーマンスが落ちるのはやだな。

「ファイルシステム」って日本語だとどう言うの？

算帳系

>>387
ファイルシステム

>>386
心配しなくてもSELinuxは面倒くさくて切って使うことが多いよ

FUSE使って2chfsとかできるのかな?
base64で書き込み。あ、削除ができねーか。

追記型ならできるかも。
でも書き込みは1000回まで。

ReiserFSについて質問です。
400GBのSATAディスク7つRAIDコントローラボードに接続して1つのドライブ（2.18TB）をつくり、
シングルパーティションでReiserFS (3.6)のファイルシステムを作りました。
そのまま使っている分には問題なかったのですが、ある日rebootしたら2Tのディスク容量が
200GB弱になっており、FSもぶっ壊れてました。reiserfsckしたらとりあえず
データ（<200GB）は救済できたのですが、容量の1割しか使えないんでは困ります。
これって仕様なんでしょうか？
システムは最近インストールしたばかりのGentooです。
よろしくお願いします。

age他方がいいのでしょうか・・

アーキテクチャが何だかわからないが
ix86のような32bit Linuxは2Tまでしか扱えないと思ったが。

sfdisk -V
すると驚愕の結果に！


なったりして

＊＊　おおっと、便座の中　＊＊

5.1TBのreiserfsのボリュームがあるよぉ。
リブート恐いよぉ。

すでに、どこかぐちゃぐちゃかもな。

400万個のぬるぽに満ち溢れて

人柱だという自覚が足りん
実運用に入る前にちゃんと検証すれ

reiser4 ではなく、reiserfs なら別に人柱じゃないだろ。
ただ、HDDがトラぶった時のリカバリ方法とかのノウハウが
あまり世に出てこないから。


>393

既知だと思うけど、
ttp://japan.linux.com/kernel/03/10/31/1455200.shtml

あとは英語のページで情報漁るくらいしかないのでは？

ReiserFSを試してみようと思い、調べていたのですが、>>71を見てちょっと
困りました(>_<)

ext3よりも、障害耐性は弱いのでしょうか？

電源ぶち切れなんて年に１度あるかないかぐらいの確率だと思うのですが、
やっぱり気になります。

どうなのでしょうか？

ちなみにOSはCentOS3(kernel-2.4)です。

>>403
漏れは>>71のようなことになったことはない。
ハードウェア的に問題があったか、さもなくばよほど運が悪かったのだろう。

仮にそのような事態を想定するとしても、それはファイルシステムに対してではなく、
重要なファイルを定期的にバックアップする心がけに注意を払うべきではないのか。

いくらジャーナリングファイルシステムだからといっても、
それは単にファイルシステムとしての整合性が保たれるってだけのことで、
アプリが書き込んだつもりの情報が失われることから守られるわけではないのだから。
# 書き込む直前にメモリにキャッシュされていた内容は反映されないから

運が悪いとファイルシステムの整合性が失われるジャーナルファルシステムなんて
ありえないんだが。

運悪く隕石が当たって整合性が失われるとか
運悪く宇宙人にいたずらされて整合性が失われるとか

運が悪いと＝バグに遭遇すると

バグの無い実装などありえないでしょ。

そしたらバグで fs が壊れる実装なんて使えねーって結論になるよ。

>>403
試してみようと思ってるなら、実際にやってみりゃいいやん。

ext3で電源ぶち切れたら運悪くジャーナルファイルがぶっ壊れて
マウントできなくなったことはある。
ext2でマウントしてみたらできたけど。

>>405-411
ありがとうございます。>>71のような事例はそうそう無いということですね。
知り合いにReiserFSを使っている人が一人もいないので、参考になりました。助かります。
とりあえず試してみようと思います。

reiserfsってパーティションのdumpって取れないの？

>>413
取れません。

アンビリーバボー

reiserfsのdumpツールがないのは痛いね。
しかたがないんでpartimageで代用してる。
partimageはマウント中のパーティションはバックアップできないんで
KNOPPIXからpartimageでイメージ作ってる。
スナップショットを使えばオンラインでバックアップできるかもしれないけど
やってみたことないんでわかんない。

reiserfsは、dumpの必要性がないファイルシステム(･`ω´･)

Can I use "dump" and "restore" with ReiserFS? Any caveats?
http://www.namesys.com/faq.html#dumprestoretar

reiserfsのFAQが正しいとするとext2でもdumpは必要なさそうだけど
実際のとこどうなんだろ？

dump自体がレガシー。
HDDが数GBしかなかったころのバックアップ手法。

>>420
数十〜数百GBのHDDのバックアップ手法キボンヌ

>>421
nbd+mdでraid1とか。

>>421
rsync+ssh

>>422
RAID1は予防策であって、復旧には使えんだろ、バーカ

旧態依然だといわれても他にdumpより良い方法がないからなぁ。なんかいいのある？/procとか問題なくrestoreできるなら正直なんでもいいんだけど。

LVM

>>425
/procの中身を取らないという意味ならtar -l (--one-file-system)は？

tarかよ

IQ56 orz

cp -ax
っつう手もあるな。dumpと比べてメリットがあるのかどうか知らんが。

てゆーか、dumpが無いって事は壊れないって事だ。

>>424
脳タリンが紛れ込んでるな。

>>432
バーカ バーカ

dumpfsは？

基本はスナップショットとれるfsをつかって、スナップショットをとったあと
時間をかけてお好きな方法でって感じで、特にこれといった決め手はないような。

>>433
バックアップにRAIDとかほざく馬鹿は放置しとけ。

>>422はnbdって言ってるから、
ネットワーク越しにRAID1組んで
片方死んでももう片方から復旧させるという手法なのかな？

瞬間的には逐次的なバックアップと見なせなくもないけど、
操作間違って消したらおしまいだしな。

sync終わったら切り離すって手法じゃね？

>>431
ファイルシステムがいかに優れていて壊れなくても、人間というものはアフォで
すぐ壊すからバックアップは必要なの。

Red Hat Enterprise Linux 4のファイルシステム(ext3)上で
ディレクトリをtarで固めると、順番めちゃくちゃに格納されちゃう。
Red Hat Enterprise Linux 3のファイルシステム(ext3)だと大丈夫。
何か変わった？

>>439
H-Treeのオンオフが違うとか?

>>439
例えば、weekという名前のディレクトリ以下に、一定の並びでファイルが
入っていると仮定します。
$ ls -f week
. .. Sunday Monday Tuesday Wednesday Thursday Friday Saturday
H-Treeがオフの状態のext3上で
$ tar cpf week.tar weeek
を実行すると、その並びでtarファイルが作られます。
もし、H-Treeがオンの状態のext3上で同様に作りたければ、
week/Sunday
week/Monday
week/Tuesday
week/Wednesday
week/Thursday
week/Friday
week/Saturday
のように、あらかじめファイル並びを記述した「week.order」を用意しておき、
$ mv week week~
$ mkdir week
$ touch -r week~ week
$ tar cpf week.tar week
$ rmdir week
$ mv week~ week
$ tar rpf week.tar -Tweek.order
の順番で実行すればOKです。

>>440 >>441
いろいろ教えてくださりありがとうございます。
なるほど、H-Treeが原因のようですね。
H-Treeがオンの時、tarファイルに格納する対象としてディレクトリを
指定すると、その配下のファイルがまとめて固められてしまうので、
このような手順を踏んでいるのですね。参考にさせていただきます。
取引先に納品したtarファイルのリストが従来と違うと文句を言われて
いたので、大変助かりました。
ただ、この方法だとディレクトリの深さが１段までなら大丈夫ですが、
さらにツリーが深くなると、再帰的な処理が必要になると思われます。
ちょっと考えてみます。何か良い案があればよろしくお願いします。

FUSE: Filesystem in Userspace (2)
http://japan.linux.com/kernel/05/05/11/2027206.shtml

tar で順番変わると何がマズいんだろ。

ただ気持ち悪いだけだろ。

ファイル展開時に関連するファイルがディスク上に並んで置かれないため、
状況によってはシーク性能に影響するということが考えられるね。

ひょっとして、cpioとか使ったことないのか?

>>447
cpio だとどうなの?

find | sort | cpio -H tar

>>446
tarにおけるアーカイブ順と、ディスク上の物理的な書き込み位置
が関係あるの?

DQNをとりまく世界ではあらゆることが起きうるから
tarにおけるアーカイブ順の如何で世界が滅亡しても不思議じゃない。

cpioだったら、たとえば、
find hogehoge | sort | cpio -H ustar -vo | gzip -9 > hogehoge.tar.gz
みたいなことをやって、中間ファイルなしに
ファイル名順にそろえられるとかじゃない?

sortしちゃったら、Sunday→Monday→…の順じゃなくなるからダメでしょう？

確かH-Treeがオンの状態でも、従来モードにフォールバックできるようになっ
ていて、ファイルシステム上には格納順が残っているはずだから、その情報を
参照すれば良いんじゃないかな。readdir()の時はそっちを使え、みたいな。

>>453
VFSが挟まってるのにどうしろというんじゃい。

>確かH-Treeがオンの状態でも、従来モードにフォールバックできるようになっ
>ていて、ファイルシステム上には格納順が残っているはずだから、その情報を

詳しく

>>451
どうせ滅亡するのはＤＱＮの脳内世界なのだから
かってに滅亡させておけ

>>453
sedなりperlなりでfilterすればいいだけでは？
月の名前だったらsortだけでもできるけど。

H-Treeオンの状態だと、H-Treeオフの状態と比べて、意図したファイル並び
という情報が欠落するわけだな。これは、POSIXでは規定されていないから
直ちに欠陥とは言えないが、この性質を利用したアプリケーションは困る。

>>H-Treeオンの状態だと、H-Treeオフの状態と比べて、意図したファイル並びという情報が欠落するわけだな。
「意図したファイル並び」とはどう定義するんですか?
1秒未満の作成/変更時間を反映した順番とかですか?

>>458
> この性質を利用したアプリケーションは困る。

具体例プリーズ。

fdcloneはいったんテンポラリにファイルを移動 -> 並び替えたい順番に
移動しなおす、という動作でファイルの並びを操作しようとするな。

それは暇そうな操作でつね。

DOS使ってた方が幸せなんじゃないか?

DOSのFDがそういう操作してたからfdcloneは
わざわざそれにあわせてあげてるんじゃないの?
もともとDOS使ってたほうが幸せな人向けのものな希ガス

何で話がそういう方向になるのかなぁ。

じゃあ戻しを試みると、
fdcloneとかのアプリは、fsによって挙動が変わる可能性があるってこと？

DOSからの人でファイルの内部並び順ウンヌン言う人いるけど、
本来保証されていないもの。
ファイル並び順の情報を保存したければ、別の方法で保存するのが筋。

検索の高速化のために内部で並び替えちゃう fs は多いよ。

それじゃ、readdir()の実装はどう説明すれば良い？
dir_indexが有効だと"."や".."を含めて並びが乱れるよ。

>>468
乱れるからどうだっていうんですか?

>>469
ディレクトリリストを見るときls -flを使わない人ですか？
先頭が"."と".."と想定しているプログラムが支障をきたします。

そんなプログラム死ねよ

>dir_indexが有効だと"."や".."を含めて並びが乱れるよ。

>先頭が"."と".."と想定しているプログラムが支障をきたします。

結局dir_index(tune2fsでのH-Treeのスイッチね)は有効にするなということでFA?

なんか馬鹿が腐れた自作プログラムの擁護するのに大変そうだね…
でも、馬鹿がいくら擁護したところで、自分の馬鹿さ加減をより晒すだけだよ。
あと、暖かくなってきて恥垢臭がきつくなってきたんで、いい加減
包茎手術したら? 馬鹿は治せないけど包茎なら治せるんだし。

>>470
たとえばどのプログラム?

>>470
そういう想定をするプログラムが悪いだけでは。
そもそも先頭が"." ".."になることを仕様として保証しているファイルシステムなんて
そんなにないんじゃないか？

>>475
ﾎﾟｶｰﾝ

Error counter log:
Errors Corrected by Total Correction Gigabytes Total
EEC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 0 0 0 0 0 116.318 0
write: 0 0 0 121 121 162.833 0
verify: 0 0 0 1 1 109.298 0

Non-medium error count: 0

Error Events logging not supported

smart-ctrl にてこんな感じのエラー吐いたんだけど、これってどう診断すればいいんだろう。
寿命と見るべき？

>>474
自分がくらった例としてpmakeでこういうコードがあった。
(インデントは変えちゃってる)

/*
* Skip the first two entries -- these will *always* be .
* and ..
*/
(void)readdir(d);
(void)readdir(d);

これコメントの意図通り動いてなくて悩んだYO。

ルートディレクトリならどうなるんだろ

>>479
お前素人?ルートディレクトリでも..はあるだろうが

>>477
ハードディスクは日常的に細かいエラーを起こし、
そのエラー回数を集計したものを表示しているに
過ぎず、問題があって表示しているわけでは無いから
心配するのはまだ。


数値的には、エラーはほとんど無いし、
「uncorrected error」が発生していないし、
心配はいらないと思うよ。

・121 回は無事に書き込みエラーが修正
・116Gバイト読み込み
・163Gバイト書き込み
・109Gバイト検査

Ext3でナノ秒タイムスタンプ対応ってどうなってる？

見た事のない smartctl の出力だと思ったら、SCSI なのね。
びんぼーのぼくは、ATA でつよ。

>>480
スマソ、MS-DOSのFSと混同してた
ちなみにDOSのルートには . .. 共無かった。

>>482
ext3のinodeにはdefaultではnanosecondなc/m/atimeを格納する余地がないので、
big inodeにしないといけなかったような気がする。

linux-2.6.11.10ではfs/ext3/inode.cでは
void ext3_read_inode(struct inode * inode)
{
...
inode->i_atime.tv_nsec = inode->i_ctime.tv_nsec = inode->i_mtime.tv_nsec = 0;

となっていてkernel側では知覚はできるけどfilesystemからは読み取らないようになってるね。

>>481
わかりやすい説明ありがとん。smartctl の導入ページはあっても、
情報の分析ページが無くてこまっていました。本当に３Qでふ。

>>483
6年前の PC で未だに Socket 7 だったり。
CPU が遅いからディスクで稼ごうとして FULL SCSI で組んだら
偉く高くついてしまった…orz

そういえばreiserfs4って頓挫したの？

した

>>487
reiser4ならあるけど、頓挫したのか？

頓挫だって？ 全てのpartitionがreiser4なオレのマシンはどうしたらいいんだ！！

>>487
ソース見せれ。

Linux って smart に関するチェックツールは標準でついていますか?

SUSEとかRedHatあたりを想定して質問しています．

smartctl
標準で付いてるかはしらね

>>492
FC3の場合、smartctlはkernel-utilsに入ってる。
標準と言ってもいいと思う。
FC-develの場合、smartmontoolsに入っている。
こちらは標準かはパッケージからは不明。
インストーラのスクリプトを読んでくれ。

>>492
SUSEだと、まんまsmartmontoolsというパッケージに入ってるな。

Novell SUSE LINX Enterprise Server 9 評価版
にlustreが入ってたので試してみました。

フルインストールでもlustreは選択されてないので、
検索→lustreで出てきたパッケージを入れてインスコ

で、time ddで性能計ってみた
ローカル性能、1spindle
ext2とext2上に作成したスピンドルに対してのI/O

read(time dd if=/fs of=/dev/null)
size___ext2_____lustre
__4KB__778M/s___200M/s
128KB__776M/s___580M/s
__4MB__777M/s___730M/s
128MB__777M/s___735M/s

write(time dd if=/dev/zero of=/fs)
size___ext2_____lustre
__4KB___42M/s____38M/s
128KB___42M/s____78M/s
__4MB___42M/s___122M/s
128MB___41M/s___121M/s

lustre。。ext2上に作成しているのにもかかわらず
ext2の3倍。。。syncしてるのか？？

あきらかにHD性能超えてて怖いのだが。。

Linuxのファイルシステムってなんでまともにsyncしないものが多いんだろ?

http://blog.livedoor.jp/shi3z/archives/23323373.html
また、パフォーマンス上も問題があって、実際にLinuxでサーバを組んで、
30万個のファイルを置いてみたら爆発的に遅くなった挙句、ハードディスク
が焼け死ぬという事態をひきおこしてしまい、以来なるべくWindowsサーバを
使っています。

ファイルシステムってハードディスクの物理的な破損を引き起こす事が可能なの？

寿命を縮めるぐらいならできそうだけど、
焼け死ぬかねぇ。

>>498
この人は
＞Linux関連のサーバを作って飯を食うようになってかれこれ6年経ちますが、
＞いまだに全貌が把握できていません
とか言ってWindowsサーバを使っているということは、
windowsの全貌を把握しているということなのか。

それはものすごくとんでもなくすごいことのように思われるのだが。。。

6年も使ってるのに把握できないなんてよっぽど...

>>501
こんなやつが、Linux 鯖で飯を食ってる当たりが エセエンジニアの
臭いがプンプン。だいたい fs と hd の物理的破損が関係あるわけない。

何の根拠もなく、こんなのことを平気で書くエンジニアがいるなんて
自分の無能をさらしているようなもんだろ。そういうやつがいるから
漏れに尻ぬぐいが回ってきて困るわけだが…。

誤　＞Linux関連のサーバを作って飯を食うようになってかれこれ6年経ちますが、
正　＞Linux関連のサーバールームを作って飯を食うようになってかれこれ6年経ちますが、

sambaが激遅なのは、認める。

自爆スイッチを押しちゃったんだよ、いろんな意味で。

>>498
ファイルシステムごとに特性があるので、
用途に合わせてファイルシステムを選ぶ
べきだと思いますよ。

ファイル数が多い用途ならxfsかな。
私は1500万ファイル作成の実績がある。

6年も何をやってたのでしょうかね。。

>>496
lustreってどういうモノ？

>>497
いつの話をしている？
- どうせマシンが落ちたらおしまいだから、と割り切っていた。
- Linusが遅いのが嫌いだから、速度稼ぐため。
というのが昔の認識だったが。

>>508
今の話。いまだにext3ですらまともにsyncしとらんのじゃないかという話すら
あるわけで。

http://www.lustre.org/

lustreは並列ファイルシステム、pvfsなども並列ファイルシステム
1台以上のPCでファイルシステムを構築する。

PC512台で1台当たり100GのHDを2個づつ持ってたら
100G×2個×512台＝
100TBの大容量ファイルシステムを組める

まぁ1台構成でもいいけど。

Lustreは1.2.4が無料公開
1.4系は有料です。
SuSEに入ってるのは1.2.1でした。

>509
まともにsyncしなければならない状況って
どこまでを対象(保証)するかというわけで、
lkmlで教祖様も、H.Reiserに「まぁ、頑張れや」
ってコメントを食らってたなぁ。

教祖様って何してる人なの？

要するに、どこまで保証するの？って話しになるときりがないから、
最初からsyncをしないって選択はありじゃない？
ぶっちゃけunmountの時だけsyncすればいい気がする。

流石513だ
そんなところに憧れるぜ

>>507
関係ないところでつっこんでわるいが、
細かい大量のファイルの処理なら ReiserFS、
大きなファイルの処理なら XFS が良いかと。

>>498
こ・・これは・・・。
こういう考えの人もいるから、
オープンソースとクローズソース論争が余計ねじれるのかな。

> ttp://blog.livedoor.jp/shi3z/archives/23323373.html
こいつは主にゲーハー板で有名な、MS営業にいそしむ電波なので関わらないのが吉かと。

>>515
今ならそうかもしれない
昔ならありえない時期もあった
そもそも「仕事で使うならReiserFSは選択肢に入れない」っていう人もこのスレには多いはず

なお>>570は細かいとは一言も言っていない

>>517
日本国内の場合、仕事でLinux OSを使うこということは
ほとんどRed Hat Enterprise Linuxを使うということになるので、
技術的には使えてもサポートされていないReiserFSは
選択肢からは外れるね。SuSEを使うならOKだけど。

>>570よ、「細かい」とは絶対書くなよ。

>>570
やらないか？

>>518 は「仕事でLinux OSを使う」イコール「ホストのお守り」という
思いこみの激しい香具師。

>>570
「大きな」と書いとけ

相変わらず要らない子なJFS

>>523
確かにねぇ...

HT-Treeでオールマイティーの ext3
小さいファイルなら reiserfs
大きいファイルなら XFS

ext3の代りにつかってみようか。でもユーザが少ないと
バグ出しも十分でないし。

うひひ
H-Treeだわさ。

reiser4も、そこはかとなく要らない子風味？

>>526
前使ってたけど、人柱は足りてない気はする。
特性とかがreiserfsと近いならそのうち置き換わるんじゃね？

小さいなら reiserfs って
アクセスが速いってこと？
それとも容量を食わないってこと？

niifs (New Implementation of a Log-Structured File System)
http://lc.linux.or.jp/lc2005/01.html
はどうなんかの

>>528
一応両方。

ファイル最後尾の小さな断片をまとめることで容量を節約する機構がある。
（Reiser ほどじゃないけど XFS にも節約機構有り。）

速度に関しては、ファイルの作成・削除が非常に高速なので、
結果小さいファイルを多く作るのが速い。


デフラグソフト PerfectDisk を使っていると分かるけど、
クライアント用途においては容量比で 90% 以上のファイルは一ヶ月以上
更新されない。ReiserFS はこれに着目してファイルを再配置する機構もある。

元々 Reiser 系は小さいファイルの扱いにフォーカスして設計されている。
Windows に比べて小さいファイルを作る傾向にある Linux の事情に
合わせた方針なわけだけど、結果、クライアント用途に抜群な FS となった。

JFSは使われてないねぇ。
SELinuxでつかえないから、FC/RedHat系で使われる事もないだろうし。

ReiserFSだと小さいファイルは、なんて言うか忘れたけど、
NTFSのMFTみたいに扱うから、それも高速化の一因だったはず。

いや、NTFSのMFTのようにinodeの直接収めるのはXFSの方だよ
Reiserfsのpackingは違うっしょ

×inodeの
○inodeに

JFSでシステム組んでるんですけど、、、orz.

でも、いまんとこクラッシュなくて（・∀・）ｲｲ!!よ。
ext3ではひどい目にあったけど、、、

なんでこんなに大勢で弄ってるわりにはLinuxのファイルシステムって
評判悪いの？

評判悪い？
そんなこときいたこともないよ

VxVMのおまけのVxFSでいいや。

OSF1のおまけのAFSでいいや。

本当かどうかはともかく、悪い評判をまいてるヤシはいるわな。ほれ、また奥山ネタだが。

ttp://slashdot.jp/journal.pl?op=display&uid=2487&id=300774
>Qu FuPing が LinusとFile System Maintainer に対し、障害時エラー出力の標準化を求めている。
>しかし、Linusは全く対応しようとしない。その態度には誠実さなどかけらも無い。
>
>背景を少し説明しよう。 Project DOUBT で、彼は 実に素晴らしいテスト を考え付いてくれた。
>対象はファイルシステム。調査内容はハードウェア障害をファイルシステムがいかに素早く
>アプリケーションに通達するか、だ。

>意図的にUPnP機能を持つデバイス上にファイルシステムを作ることで、
>デバイスドライバーまでは障害を確実に取得できるようにする。

>ファイルシステムにさまざまな形式のアクセスを行いながらUSBケーブルを引っこ抜き、
>ファイルシステムがどのタイミングで障害を報告するのかを調べると、

> * そもそもエラーとして障害を返さない。
> * エラー内容が明らかに間違っている(Storageは丸ごと存在しないのだ。
> Read Only File Systemって何事?読めるって言うのか?!)
> * 勝手にキャッシュが正しいことを仮定している
> (Cacheっていうのはオリジナルに対するデータのコピーで、
> 整合性がちゃんと制御されているものを言う。
> オリジナルへのアクセス能力を失ったら、整合性を制御できないのだ。
> デバイス障害を検出したら、速攻でキャッシュは破棄しなくてはいけない)
> * そして、ファイルシステム間でエラーがバラバラである
>
>はっきり言っていかなる用途であれ、このような信頼性の無さは許されるものではない。

>が、Linusは問題を指摘されても直そうとは考えないらしい。問題の存在自体をきっぱりと無視している。

>>539
Windowsなんかは、知識が足りないユーザーも使うから、
エラーはしっかり出すように気をつけてるんかね〜
OSごとに、ターゲットにしてる人に合わせた対応って感じなのかな。

WindowsでFAT32に4Gを超えるファイルを

途中で投稿しちまった

コピーしようとしたときのエラーメッセージとか、しっかりしてないよWindowsも

WindowsのUSBデバイスの場合は、デバイスがひっこぬかれた瞬間に
システム側のファイルシステムが強制アンマウントされた状態になるよね。
Unixで同じようにファイルシステム強制アンマウントってできるの?
普通はプロセスがさわってたらDevice busyとかなっちゃうけど、
あれの根本的解決ないのかな。

linux-2.4.30でUSB HDDひっこぬいて(device busyがない状態で)
存在しなくなったブロックデバイスをumountしようとすると
reiserfsなんかはfs driver内でSEGV起きてたりした気がする。

昔 USB フロッピードライブを USB 端子にさしたとき、
ディスクが入ってないせいで kernel がとまったことがあった。

これ言っちゃおしまいかもしれないけど、
Linuxは昔も今もこれからも、そういうモノでないかなあ。
それが嫌ならBSDなりSolarisなりWindowsなりを使えばいいわけで。
それを知らずにLinusの信者になる方が悪いっていうか…

Linus「patch書けば？」

でも、気に入らないって言われて、書いたパッチはキックされちゃうんでしょｗ

>>539
Qu FupingがLKMLで相談したのがこのスレ
ttp://lkml.org/lkml/2005/5/16/9
教祖様が参戦したスレは
「USBはホットプラグデバイスなんだから再接続した時にスムーズに再マウントできないとダメだろ」
とかめちゃめちゃな流れになっててワロス
長文のわりに議論が下手糞だなあ

ところでFreeBSDのFireWireディスクは切断-再接続した時再マウントなしに使えるんじゃなかったっけ

そこで fork ですよ。

　 　∩＿＿＿∩　　 　　　　　　｜
　　 | ノ＼　　　　 ヽ　 　　　　　　|
　　/　　●゛　　● |　　　　 　　　|
　 |　∪　　( _●_)　ミ　 　　　　　|
　彡､　　　|∪|　　 |　　　 　　 --+∈
/　　　　 ∩ノ ⊃　 ヽ
(　 ＼　／ ＿ノ　|　 |
.＼　“　　／＿＿|　 |
　　＼ ／＿＿＿ ／

そりゃ食えん

Linus「文句言う or 日記書く or 2chに書きこみする 暇があったら、*素晴らしい* patch 書け。以上、議論終了。」

あくまで、fsに関してのセンスが最悪なLinus的に素晴らしいパッチだけどな。

reiserはサイズの小さいファイルに適していると聞くけど、具体的にどれくらいのサイズまで適してるの?

>>550
コーヒー噴いた

>>553
素晴らしくないから拒否される。
本当に最悪と思うなら、>>553の言う最高にセンスのある fs に書き直してみせろよ。

Qu Fupingはfs/mpage.c(MLではmmap()の話だったような)について
同じ動機(デバイスのI/O error対処がなってない)でパッチを投稿して、
Mortonに査読されて、昨日Linusにとりこまれたみたいね。
http://grmso.net:8090/commit/854715be73b221596c7127d4042e1120d4539e19/

とりあえず、Qu Fupingにとっての第一段階の到達点はfsのセンスがどーのこーのではなく、
存在しなくなったデバイスへの書き込みは揃ってEIOを返せというあたりだろうから、
小出しにパッチ書いて投稿できるんじゃないかな。

reiserfsはpageサイズ以内であれば速いですね。
i386なら4Kbyte以内、x86_64とia64であれば16Kbyte以内

reiserfs_file_write
や
reiserfs_writepage
->reiserfs_write_full_page

のソースを追っていけばわかるが、書き込み領域が
1ページの場合だけ、特殊な動作でwrite処理を実現している。
特殊な動作ってのは説明しづらいが。。
小さいファイルをページに詰める処理があって、seekの負担を
減らしたりして、ディスク効率良＆速度を稼ぐ

複数ページのwriteは他のファイルシステム同様writeキューに
入れて非同期I/Oにつないで、pdflushのタイミングでwriteし
外見えの速度を稼ぐようにしている。

getmeta系はリスト構造が木構造で速い。。
としか、簡単に言えないな。。

reiserfsで1冊本書いても売れないだろうな。。。

>>558
詳解ファイルシステム とか出して
買うよ

>>558
洩れも買うぞ。
reiser4もよろ。

解説書の陳腐化速度予想

低速 高速
<--------------------------->
UFS JFS XFS EXT2 EXT3 ReiserFS(測定不能)

工夫はいろいろされていると思うが、小細工がかえってパフォーマンスを悪化させることもあって、
実際にどのサイズでどの程度速いかは測らないとわからないかもしれず。

>>539
ぶっちゃけた話、↓これに尽きるだろ。
http://pc8.2ch.net/test/read.cgi/linux/1100967722/I318
>Kyle> But you miss the point. Linux is *NOT* about "business", or "enterprise", or "mission-critical". Linux is (at least to many hackers) about hacking, having fun, and Good Design(TM).

reiserfs4の内部構造の解説はどこかにwikiがあったよ

>>563
そのレスの中で一番ウケたのは
Andi> Didnt review more.
だなｗｗｗｗｗｗｗｗｗ

ReiserFS のパッキングは確かに速度低下の原因になっているよ。
だから Reiser4 では改良の対象になっている。
ただ、他の工夫で速度をあげているけど。


>>532 にあるような、NTFS XFS の方法は
効果は極端に小さいファイルに限定される。
（NTFS の場合、約 700バイト以下）
ReiserFS の場合、中途半端に小さいファイルでも効果あり。


Reiser4 がなかなか登場しないからいっそのこと
ReiserFS (v3) で / を作る手を打つべきだろうか。
速度にこだわらないなら ext2 も意外に堅牢だと言うし迷うな。

>>566
Reiser4が登場しないってどゆこと？

>>567
書き方悪かった。

標準カーネルになかなか取り込まれないってことで。

こんな記事もあった。（１月頃の記事）
http://japan.linux.com/desktop/05/01/11/138258.shtml
>Reiser4は、Linuxカーネル開発者たちによって拒否されたため、
>正式なカーネルおよびインストーラの一部としてはサポートしていません

reiserfs って 3 のときもひと悶着あったね。

mmには入ってるんだっけ？ > Reiser4

Reiserって今や出来の悪いレガシー扱いされてるからなぁ・・・

>>570
はいっとる＞2.6.12-rc6-mm1

homeみてみたら、5M〜15Mあたりのファイルが多かったんだがReiser使うにはでかすぎるかな
普通にext3使っとくか…

そこでxfsですよ

Reiser4だね。

xfsって5〜15Mあたりの大きさに適してるんですか?
大きいサイズって言うから少なくとも100M超かと勝手に思ってた。

数Bytes〜4kBytes なら Reiserfs
5M〜 なら xfs って認識でOK?

xfsは細かいファイルだってかまわないで食っちまうファイルシステムなんだぜ

>>577
XFSってファイル消去がすげー遅かった記憶があるんだけど直ってる？
昔2.4カーネルにマージされる前に
# rm -rf /usr/src/linux
してえらく待たされた。

>>578
試してみたらHDD突然死した＿|￣|○

過労でつか？

そもそも「そこで○○ですよ」とか言ってる香具師に反応した時点で釣られてることに気付け。

昔のXFSにくらべたら今のXFSは
「サイズは小さいが大量のファイルの生成/消去くりかえし」
の速度がかなり改善されてるが、
ReiserFSがダンチに速い状況はかわらず。
しかしXFSがメタクソに遅かったのって2.4.0-testXXXとかその頃じゃねーの?
今の2.4.31とか別に死ぬほど遅いとは思わんがな。

らいざーって読むんだね
レーザーって読んでた

Linux界隈の人間は用途ごとに別のFile Systemを使おうとする件について

適材適所

適材適所っていうほど違うわけでもない。
ってことで、信頼性はおしなべて低い(w

それがLinuxｸｵﾘﾃｨ

OS自体を楽しむためのOSだから、それでいいんじゃない？

全部ext3(ext2)なんて耐えられない。

適材適所なのは分かるが、具体的にどんなときに適してるかまとめてある資料ってない?

reiserが小さいファイル、xfsが大きいファイルに適してるってのは知ってるんだが、
>>576が言うみたいな具体的なサイズまでは知らない。
どれくらいの大きさなら、ext3と同程度かそれ以上の性能が出せるのかが知りたいんだが。

速度しか見ようとしないから厨と言われるのだ

>>589
なんだかんだ言って、どのファイルシステムも
大きいファイルから小さいファイルまで考えて作ってある。

確かに、ファイルシステム自体の評価は余り見かけないね。
「 ext は断片化に強いからデフラグは不要 」 と
信じて疑わない人が大多数であるし。

結果は >>529 の一番下の資料を見る限り Windows と同様、
断片化の影響を大きく受けている。
疑わないことで Windows に遅れを取ったことになる。

サーバーマシンではデフラグの効果が余り無いのも事実だけど。

ext2のデフラグツールって90年代前半には既にあっただろ
Unixの「デフラグツールはありえない」っていう思い込みを
無批判にLinuxに適用していたアフォ評論家が多かっただけ

・fsckが早い
・使用環境のファイルサイズが大きいものが多い環境（1GB以上のファイル）
・そのファイルサイズが大きいファイルの削除が早い
・ランダムアクセスはほとんど発生しない
・MDデバイスやLVM上でもファイルシステムを構築できる
・ファイルシステムの拡張ができる（できれば縮小もできるとうれしいけど、その点は妥協）

といった感じで現在SuSE Linux 8.2 (Kernel 2.4系）で
XFSメインで使用しているのですが
最近（Kernel2.6環境）でも上記条件ではXFSにしておくのが無難ですかねぇ？

ログ見るとReiserFSがかなりよくなってるようですが・・・

>>593
>>・fsckが早い
XFSのfsckのソースのmain()の中身って
return 0;
だけじゃなかったっけ? 今は違ってる?

int
main(int argc, char **argv)
{
return 0;
}


先生！変わってませんでした！

> int
> main(int argc, char **argv)
> {
> return 0;
> }
Hello World よりも酷いね・・

早くLinuxででもUFS2を不自由なく使えるようになって欲しい。
UFS2は素晴しい。

>>596
何がうれしいの?

しかし、reiserfs や ntfs とメジャーなものばっかりですなぁ。話題は。
漏れとしてはそれよか、他のシステムで使われているファイルシステムが気になるのだが...hfsとかhpfsとか

まぁそっち側の趣味を持っている奴がいるのかいないのかぐらい確かめさせてくれ

>>596
Linuxのことだから、一から再実装してext2と大してと変わらんシロモノになるぞ(w

filesystemについて理解していないのならわざわざバカなこと書いて
無能を晒さなくてもいいのに。

600=真性包茎

真性包茎 = UFS
仮性包茎 = UFS + Softupdate
ズルムケ = XFS, Reiserfs

上の方がすぐれてるんだよな？

>>603
真ん中が地球上の動物として普通。

http://blog.livedoor.jp/shi3z/archives/24991969.html
Re:ひとつのディレクトリに数十万個のファイル？

そもそもXFSのfsckに何をさせようというのだろう。

>>593 が言ってるfsckってjournal replayのことだろ…

>>605
要約すると

「ぼくは情報処理のべんきょうをしたことがありません」
「ぼくは悪くありません」

てことですね。

まあ、普通に考えてDBでやるだろうな

>>609
んだな。

ところで今のサーバのメモリが2Gくらいって感覚はどうなの。
何のサーバかにもよるけど、最近なら8G位普通じゃない？

>>610
鯖でなくてもデスクトップなら普通2Gくらい載せてるだろ。
4GoverだとM/BのスロットとOSが64bit対応してるのがmustだな。

>>605のリンク先の言い訳を見てると首がもげるぐらい傾くな。
8ビット機の昔から、ゲームで大量に使わなきゃいけないデータは単純に結合した１つのファイル
にでもしておく手法が主流だったんじゃないか？
msec単位の処理時間を気にするなら、openよりseekの方が速いだろうに。

>>612
確かに。違う画像とって来るにもopen-read-closeよりseek-readの方が速い

>>611
デスクトップでは、まだ１Ｇでしょ。
熱心な人が２〜４Ｇにするくらいで。

ゲームする人は、結構2G多いかな。

VMWare でいっぱいつんでる

よし、物は試しだ。やってみようぜ。
安全のためUSB接続のHDDになると思うけどどのぐらい時間かかるんだろう・・・ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

男は度胸
なんでもやってみるのさ

ｶﾈあったらVxFS試したいね

>> レスポンスタイム(16.6ミリ秒)
ext2上に4Kのファイルを一つのディレクトリに30万個置いてみました。

※(creat + write) １ファイル当たり 8.90759 ms
$ time for (x=0;x<300000;x++) do cp test.gif /test/$x; done
real　　44m32.277s　user　　 2m15.260s　sys　　42m20.050s

※getmeta １ファイル当たり 0.006 ms
$ time ls /test | wc
300000 300000 1988897
real　　0m1.822s　user　　0m1.720s　sys　　 0m0.180s

※(open + read) １ファイル当たり 1.14239 ms
$ time for (x=0;x<300000;x++) do cat /test/$x > /dev/null ; done
real　　5m42.717s　user　　1m48.020s　sys　　 3m19.930s

open + read (/dev/nullへのwrite)で、1ファイル当たり1ミリ秒なんだが。。
ちなみにinode不足になるENOSPEのエラーが返ってくるまで
試しましたが、問題ありませんでした。(約160万個)
ｉアプリがどうのこうの言ってたので、4年前かな？以下の構成で行いました

OS : Red Hat Linux 7.3( kernel 2.4.18 )
CPU : Pentium3 600MHz
Memory : 128M
disk : Deskstar 75GXP DTLA-307030　30.0G
I/Oサイズ : 4096 byte(※iアプリ用だからこのくらいで十分？)
＃改行多いと怒られたので、一部改行削除してます

>>620
ﾊﾔｽｷﾞｽwwwww

あそこのblogのシャチョーのマシン、DMAがONになってなかったとかｗ

しょっぱい人も反応してたけど、そもそもが電波だからなぁ。

ext2でマウントされたブロックデバイスAから
同じくext2でマウントされたブロックデバイスBに
ファイル(ディレクトリ)をコピーするときに
ブロックデバイスAにあるファイルのiノードの情報を
ブロックデバイスBにコピーする際に利用することって
できますか？？
こうしたらできるはず等ありましたら、教えてください。

iノードの情報ってのがなんなのかよくわからんけど、
ext2ならext2fs.hあたりを利用すればいいんじゃない？

test

OSDL奥山氏の議論にもつながるんだろうが、
ReiserとかExt3とか、ジャーナリングありのFSって、
本当に、「絶対に」整合性を維持できるのだろうか。

たしかに、FSのメタデータの整合性は維持できるかもしれないが、
ジャーナルファイルのメタデータは？
そのデータが含まれるセクタを書き込んでいる最中に電源を落とされたら？

全自動電源オンオフマシーンとか作って、
ひたすら「コンセント引っこ抜きテスト」を100年間ぐらい続けたとする。
はたして、ファイルシステムの整合性は保たれるだろうか。

そんなテストになんの意味があるんだかｗ（ﾌﾟｹﾞﾗ

つながんねーよ

>ジャーナルファイルの
いかにも奥山のサイトを今朝発見しましたって感じ（ﾌﾟｹﾞﾗ

停電なら不整合は起こるに決まってるジャン。
確実なのはソフト的なアクシデントに対する耐性なんだから。

腐ってる vfs 上にのっかてる fs がまともなわけないじゃん.
おれは, Linux 客先にだすときはかならず xfs 使う.
# xfs が, もからある vfs 使い始めたら, 他の fs も考えてもいい.

>>630
> 確実なのはソフト的なアクシデントに対する耐性なんだから。
*BSD の softupdate は, 停電が発生しても, 更新(書き込み)中の
ファイルの更新部分が破棄されることはあっても, 更新前のファ
イルは生きてるよ.
disk が物理的に破壊されれば話はべつだが, 電源段で fs の整合
性が崩れることはない.
# background fsck が完了するまでゴミは残ってるけど.

>>631
echo # xfs が, もからある vfs 使い始めたら, 他の fs も考えてもいい. > \
sed 's/もから/もとから/'
# ちなみに, 教祖様とは何の関係もないっす.

>>631
それはxfsが元のvfsを認めたから他のfsも考慮するってことなのか、
そうなったら腐ったxfsを捨てるってことのどっちなのか？

xfsが提供してるvfsの上に現状のfsをのせるとかすりゃいいのかと思う。

>>632
>echo # xfs が, もからある vfs 使い始めたら, 他の fs も考えてもいい. > \
^^^^^
たしかに教祖様のレベルにすらいってねーな（ﾌﾟｹﾞ

reiser4ってこのまま永久に外様扱いでカーネルツリーに取り込まれないの?

>>632
それは、sed というファイルにリダイレクトしてるだけのように見える
んだが、s/foo/bar/ の意味はあるのか？

zsh: bad pattern: #

メタデータジャーナルは、停電後の fsck が
短縮される以外の効果は無いと思っても良い。

ジャーナルの無いファイルシステムでも
注意深く実装すれば同等の耐久性が実現できる。
fsck が時間かかることを除けば。


確実に保護できるフルジャーナルは速度が遅すぎて
実用的じゃないので、

UPS を使うことが唯一の解である。きっと。

ext2, reiserfsは壊れた事あるけど、
xfsは今のところ壊れてないな。
もちろんデータは飛ぶけど。

ext3に行く前にreiserfsいったから、ext3はわからん。
でも自分が管理してない仕事マシンは全部ext3。
自分が管理してるマシンはext2/xfsだけど。

ttp://japan.linux.com/desktop/05/06/20/0123202.shtml
で NetBSD の Christos Zoulas が

>NetBSDカーネルに感じる主な不満は、以下の点です。

> * ジャーナル・ファイル・システムまたは巨大なファイル・システムのサポートがない。

なんつっとるが、「巨大なファイルシステムサポート」ってのは
ファイルサイズがめちゃでかい時のアロケーションストラテジなのか
reiserとかxfsみたいなB-Tree系のファイル探索高速化なのか
どっちなんやろ

NetBSDにはufs2が移植されているのに。
あと、Solarisには大昔からufs loggingがあるから、OpenSolarisからその辺を
持ってこれないもんかな? ってライセンスの問題があるけど。
SolarisといえばZFSってあんまり噂を聞かないなぁ。

ZFSってリリース時には搭載されずアップデートリリースで実装予定とか聞いたけど結局どうなったん

WinFSの方も雑誌のインタビューでじっくりと時間をかけてちゃんとしたものを送り出したいとか答えておきながら、
同じ記事内でWinFSはリリースに間に合わないので（略）なんて答えてるし

solarisのufsで思い出した。
linuxの各種ファイルシステムはCPU（バイトオーダ）に依存しないの？

>>640
「ファイル・システムの安定性：Linuxにははるかに多くのファイル・システムがあり、
力を入れているファイル・システムがディストリビューションごとに異なる（たいていは
技術的な利点ではなく政治的な理由でそうされる）。ほとんどのディストリビューションは
大きなファイル・システムをサポートし、ジャーナリングが実行される。
残念なことに、一部のファイル・システムは安心して利用できるものではないのだが、
一般のユーザが選択するときの判断材料となるような本当の意味での負荷テストが存在しない。」
って本当に同意。テストすること自体を忌諱しているし、テスト結果をみせつけられると
趣味で作っているOSだからと逃げるし。

>>643
有名なのは大丈夫。

まあそういう悲劇に巻き込まれるのはbigendianと相場が決まっているので、
i386使ってれば心配する必要もなかろう。

>>644
仕事でファイルシステムに対する要件が厳しければ、
IBMの保守付きでJFSを利用するとか手はあるんじゃない？

見方にもよるけどLinuxカーネル自体は趣味そのもの。仕方ない。
実際は業務で書いてるコードが大半だけど、そこがまたおもしろい。

64bitで動かないfsもあるぜよ。
JFSは動くようになったんだっけか？

Solaris10 4/05が6/14に出たが
zfsは入ってなかったよ(´･ω･)

128bitファイルシステム。
KMGTPEZY。。。単位はなんだろ。。

詳解ファイルシステムの本書こうかな。
各ファイルシステムの諸元からsystem callの流れ。。

すぐ陳腐化しそうだから毎年出すとか必要だろうな。
大変かも。。。

>>646
いっそVxFSとか。

/.-jp みたいなノリだね。

>>648
よし、頑張れ。
出たら買う。

>>648
じゃあ洩れも買おう。
FSの基本とかアルゴリズムなど不変な部分は教科書的に書いて、
実践編をこまめに改訂できれば良書になりそう。

wiki に 1 日 1 ページ書いていけば？
報酬ならジャムおじさん方式で。

>>643
こんなの見つけた。　やっぱりネットワークバイトオーダーと同じでLittle Endianに
してるんだね。　

http://www.linux-m68k.org/ext2swap.html

一応。
ネットワークバイトオーダーはビッグエンディアン。

>>655
orz ｻﾝｸｽ。　何言ってんだｵﾚ。

>>620
すぐに試してみる心意気はすばらしいと思うんですが、
ファイルシステムよりforkが律速段階になっている気がする。

>>635
ttp://lkml.org/lkml/2005/6/21/98

詳解ファイルシステム

>>653
wikiでコツコツ作っていきます。(=ﾟωﾟ)ﾉ

本の出版はしたことがない素人なので、
wikiでも良いかなってことで
＃wikiも本格的に触ったことないんで、勉強しながらですけど。。

zfsが秋ぐらいに出るかもしれないので、
そのぐらいまでに形になっていければいいかな？

とりあえず、今日少しだけ書いてみた。
ファイルシステム諸言とvfsについて
ファイルシステム諸言は書いてないけどia-64の場合ですので
ia-32のほうが利用者多いのでのちほど書きます。

ttp://www.wikihouse.com/linuxfs
＃内容は期待しないでください。。。。

文章考えるのが大変。。
参考文献→linux-2.6.12.tar.bz2
一から作ってるので、オリジナルだと思うけど、どこかに
似た文章があったら教えてください。書き直します。。

おいおい
がんばっちゃってよ

体壊すなよ

諸言？諸元？

かなり期待。

もしミスや誤字その他で気になることがあっても
追い追いこのスレで話しながら直していけばよいでしょう。

>>662
諸言は誤字です。諸元です。。
直しました。ご指摘ありがとうございますm(__)m

vfsについて少し追加(各operations系[fs.h])しました。
＃絵も一部欠けてたり。。直さなきゃ。。。

ところで、今作ってる「詳解ファイルシステム」って
こんな感じで作成し続けて良いのかな？

細かいところはかなり省いているんだが。。。

doxygen した方が早いような

同じ指摘ばかりで申し訳ないですが,
「1ディレクトリに10000ファイルを置くテスト」のように,
10000回touchをforkしていると, 時間の大半はforkに
かかってしまい, ファイルシステムのテストにはならない気がします.
たとえば,
seq 1 10000 | xargs touch
だと, 私の環境では, 35倍速くなりました.
さらに, 専用の小さなプログラム書けば, もっと速くなって,
ファイルシステム自体の速度を見るのに役立つと思います.

参考までにforkが1回になるようにやってみました.
Cで以下のようなプログラムだと, さらに2倍(元の70倍)でした.
int main(int ac, char **av) {
char name[10];
int fd,i;
if (ac < 2) exit (1);
i = atoi(*(av+1));
while (i--) {
sprintf (name, "%d", i);
fd = creat(name, 00644);
close(fd);
}
}
./a.out 10000
perl だと, seq | xargs と同じくらい.
perl -e 'for($i=0;$i<10000;$i++){open $fh, ">$i";close $fh}'
xargs がお気楽という点で良いかもしれませんね.

各ファイルシステム間のファイルのコピーってどのように行われているのですか？
パーミッションやファイルサイズ、アクセス時間などをどうやって移動させているかわかりません。

できればkernel2.6、ファイルシステムはext2で具体的に教えてほしいです。お願いします。
参考HP、参考書籍などありましたら、リンクをお願いします。

GNU fileutilsに含まれるcp(1)のソースを見よ

>>668
学校の課題なら自分で調べましょうね

>>659
vfsの絵はreadからすぐにカーネルに入ってもいいような気がする。

Reiserﾀﾝ... ｶﾞﾝ(　ﾟдﾟ)ｶﾞﾚ

>>669

ありがとうございます。
解決しました。m(_ _)mペコリ

http://www.microsoft.com/japan/msdn/library/ja/jpdnw2k/htm/ntfs2.asp

NTFSはsparse fileをサポートしてます。

突然何を言うか

>>675

>>659 の内容についてだと思う。
Linux のカーネルを元に書いてるから、
Windows 関連について不正確な箇所がある。

そこらへんはゆっくり検証していくしかない。

FAT のファイル数制限の検証をしようとしてるけど
遅すぎてまだ終わっていない。

FATは仕様上ルート以外の制限ないんじゃない？
もちろんあるかもしれない実装上の制限を調べたいんなら別だけど。

FATは同一ディレクトリに多数のファイルを置くと
新規作成/削除が目に見えて遅くなるね。
１つ作るのに秒単位で時間がかかる。

もし、ファイルシステム全体での制限を調べているのであれば
今からでも、ディレクトリを細かく分けてテストすることを勧めたい。

詳解ファイルシステム？
つttp://www.namesys.com/benchmarks.html

指摘をしていただける皆様方ありがとうございますm(_ _)m
どんどん反映して良いものに作り上げたいです。

＃良いものが出来れば、ここのテンプレに載せてもらえるかな(￣ー￣)ﾆﾔﾘ

>>666
「1ディレクトリに10000ファイルを置くテスト」
ご指摘ありがとうです。m(_ _)m

1fileをcreateする速度は今のところ
速い　　　　　　　　　　　　　　　　　　　　遅い
reiserfs > jfs > ext2 > xfs > ext3 > vfat
と書いてます。

専用の測定プログラムを書けば、速度は速くなりますが
速いファイルシステム、遅いファイルシステムの順番は変わりますか？

目的はどのファイルシステムが速いのかを調べることです。
なので、測定プログラム(コマンド)は何でも良いかなと考えております。

1createで何milli secかかるか測定するものではありません。
環境や測定プログラムによってmilli secは変化しすぎるから。。

>> 674

>>676の言うとおり、Linuxのカーネルを元に書いてます。
windows上ではsparse fileをサポートしているが、linuxではまだ
サポートしきれておりません。

linux2.6.12.1/fs/ntfs/inode.cの中で、ntfs_truncateで検索してみてると
* ntfs_truncate - called when the i_size of an ntfs inode is changed
* @vi:inode for which the i_size was changed
*
* We do not support i_size changes yet.
とあるし。

詳解ntfsに記述しておきます。。

>680
>専用の測定プログラムを書けば、速度は速くなりますが
>速いファイルシステム、遅いファイルシステムの順番は変わりますか？

forkなどで律速になったら有意な差が検出できない可能性はある。
またドライバの癖が出る可能性もありそう。

>>680
> 専用の測定プログラムを書けば、速度は速くなりますが
> 速いファイルシステム、遅いファイルシステムの順番は変わりますか？
>
> 目的はどのファイルシステムが速いのかを調べることです。
> なので、測定プログラム(コマンド)は何でも良いかなと考えております。
>
> 1createで何milli secかかるか測定するものではありません。
> 環境や測定プログラムによってmilli secは変化しすぎるから。。
何がしたいのかよく分かりませんな。
君は各ファイルシステムが採用しているデータ構造をサーベイして*ステップ数*で
評価しようとしているのではなかったのか。厳密なステップ数ではなくて計算量オーダーでも別に構わないが。

>>680
元の測定だと99%以上の時間がファイルシステム以外で使われています.
順序を知るのが目的だとして, それら99%分の処理が常に同じ時間で
終えるものであれば, 元の測定方法でも問題ないと思います.
ただ, 現実にはforkの時間は結構幅があるような気がします.
後で実際に試してみます.

> ただ, 現実にはforkの時間は結構幅があるような気がします.
> 後で実際に試してみます.
やってみました:
(; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.38s user 9.96s system 101% cpu 11.137 total
(; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.37s user 10.02s system 103% cpu 11.044 total
(; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.36s user 10.01s system 102% cpu 11.044 total
(; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.39s user 9.97s system 102% cpu 11.041 total
(; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.36s user 9.99s system 102% cpu 11.034 total
(; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.43s user 9.93s system 102% cpu 11.048 total
(; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.38s user 9.95s system 102% cpu 11.040 total
(; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.38s user 9.97s system 101% cpu 11.140 total
(; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.36s user 10.01s system 101% cpu 11.150 total
(; for ((x=1; x<10000; x++)) do; touch /dev/null; done; ) 1.37s user 10.01s system 103% cpu 11.035 total
まあ, 無視できる誤差と言っても良いのかなあ…
# とはいえ釈然としないものはありますが.

>>677
ルート以外もあるよ
http://support.microsoft.com/default.aspx?scid=436213

65536 - 2(. & ..)ってとこか

http://support.microsoft.com/kb/161982/en
Linuxだと-o shortname= で挙動変えてSFN,LFNの場合も変わってくるんでない

FAT16 クラスタ数 <= 65526
FAT32 65526 < クラスタ数 < 4177918
1つのクラスタに2つ以上のファイルは入れられないって制限もあるから
これも関わってくるか？

ところでvfatって考え的には動的inodeじゃね？

users-jp(・∀・)ﾆﾔﾆﾔ

>>686
＞Windows では、長いファイル名、サブディレクトリ名、8.3 に短縮された
＞エイリアス毎に、それぞれディレクトリ エントリを使用します。
だから結局その半分。

昔1フォルダに3万強以上でファイルが作れなくなったことがあって「仕様と違う」
と思ってたことがあったのだが、これで理由がわかった。

よーく考えろ。作れる数に制限ないとFATの容量(メタデータ)が決まらないだろう。

>>689
FAT の容量はパーティションの容量とクラスタサイズで決まったはず。
ファイル数等の制限とは直接は関係は無かったはず。

１つのクラスタに１つまでのファイルしか入らないので、
その意味でファイル数が制限されることはある。

メタデータは FAT とは別に存在して一応柔軟に生成できる。
但しオンラインデフラグでは移動や削除はできない。

my $cow = 1;

while($cow < 65536*256){
my $we = "";
my $sd = $cow;
while($sd > 0){
$we = "\\".($sd & 7).$we;
$sd >>= 3;
};
$we = "H:".$we;
if(mkdir($we) == 0){
exit();
};
print($we."\t(".$cow.")\n");
#sleep(1);
$cow++;
};

こんなプログラム（Win用）で FAT32 上でフォルダ（ディレクトリ）を階層構造で作って見た。
DVD-RAM でテスト中、現在、８万以上のフォルダ生成に成功、速度低下も余りなし。

FAT16 と FAT32 の違いって、なぁに？

>>692
少し上に答えはあるぜ >>686



ついでに途中経過、４２万のフォルダを生成できた。
この調子だと容量を使い切るまで作れそうだ。

>>693
構造の違いについては記載されてないわけだが。

>>688
長いファイル名が長いと、1つのエントリでは納まらないのでさらに減ります。

/usr/src/linux/include/linux/msdos_fs.h にある構造体とかか。
msdos_dir_entry msdos_dir_slot

Windows95 になったとき、それまでの MS-DOS ようのプログラムが、
msdos_dir_slot を適正に処理できなくて、うんこな状態だった話とか
そんな昔話してもいい？

そういえば、FAT系って
・ルートディレクトリのエントリ数の制限(FAT32でルート移動可になって解消だっけ？)
・システム内ファイル数の制限(クラスタ数の制限だっけ？)
があった気がするけど、
ファイル数の制限には、「サイズ０のファイル以外で」という条件があったはず。
つまり、サイズ０のファイル(ディレクトリエントリのみ)は
容量が許す限り、幾つでも作れたはず。

つーことは、EOF_FAT を書くから消費されないということでつかね。

メタデータを使わないファイルシステムって
代表的な奴は何になるのかな

>>686 にあるようなディレクトリごとのファイル数制限について。

ttp://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx

ルートディレクトリのファイル数制限は FAT12・FAT16 の制限で一般に 512 まで
だけど、フォーマット時に決められる様で 65535 まで増やせそうだ。

サブディレクトリや FAT32 のルートディレクトリのファイル数制限は FAT の仕様ではなく
Win98 系の実装上の制限が原因の様だ。

Win2000 系においても互換性のためにあえて制限しているようだ。

マウントの概念がなかった時代に関しては、ルートディレクトリに
たくさんファイルをおける必要はないもんなぁ。

>>701
FDの時代だ

>>701
今更ながらすげー納得した

>>702
1Dなら160kb

階層ディレクトリの無い時代にも同じ制限があって、困っちゃったわけだが。

他のfsの歴史はちゃんと1.0公開とかあるのに
1997年6月23日　reiserfs のソースコードを web に置く
ってのがﾜﾛﾀ

>>699
ファイルサイズもメタデータなので
メタを持にないFSで代表的なのは
まずはテープデバイスだろう。

漢直ユーザですか？

wikihouse重杉

wikihouse重杉

ということで7/7 wiki.livedoor が出来たのでミラー作成
ttp://wiki.livedoor.jp/linuxfs

ソースをコピーしただけだから若干表が崩れてます。
＃livedoorは手動ミラーなので更新遅いかも。。

vfsをとりあえず、完成させてから
ext2,nfs,reiserfsの説明を充実していきます。
vfs部分はgoogleで調べても載ってないものが多いから
ソース調べて書いてるけど、間違いあったら指摘
よろしくお願いしますm(_ _)m

いろいろ書きたい。。(*´Д`)
kernel2.6.13のこととか脱線気味もたまにはあるけど
気長に完成目指してがんばるっすよ

>>710
乙。

> kernel2.6.13のこととか脱線気味もたまにはあるけど

むしろそれが面白い。
雑誌だとコラムとかに面白いネタ転がってたりするし。

>>710
おまけのところ s/XIM/XIP/

ramdiskなんかに置いてある実行ファイルを
そのまま実行してしまうという技でつ。

ttp://www-6.ibm.com/jp/developerworks/linux/050715/j_os-openafs.html
OpenAFSって使ったことある方いますか?

@it にて、
ttp://www.atmarkit.co.jp/flinux/rensai/linuxtips/763fsflag.html
の、記事を読む。

今まで、「Linuxでデフラグは、いりません。」と、読んだ本に書いてあったので、
「どういう仕組なんだろう。」と、不思議に思いつつも信じていた。

のに。

フラグメント化した状態は示されても、
フラグメント化したディスクへのアクセスがどれくらいパフォーマンスを劣化させるかは示されていないのだが、
それでよいのか?

なんか /bin/bash あたりがフラグメントしてるのを見て鬱になったぼくがきましたよ。

/bin/sh -> /bin/bash
な環境なら確実にキャッシュに入ってるだろうし、
そうでなければ逆にまったく問題ないであろう。

>715 ttp://lc.linux.or.jp/lc2005/01.html

>>718
それ中身を良く読むと、
・ iozoneを複数個並列に動かすような、実環境でありえない方法で激しいフラグメント化を起こし
・ にも関わらず、CPU占有時間は変化せず(スループットは低下せず)
・ シングルスレッドのパフォーマンスの低下も1/2程度
となってて、結局のところ
「実環境でext3fsのフラグメント化の影響を心配する必要はありません」というデータに
見えるのは、私だけかな。

> うはっｗ俺Al Viroのpatchみてねーや

リーナスあたり言ってそうだな

ext2で/から辿れなくなったファイルを救出しようと別領域から立ち上げて
dd skip=1300447 ibs=4096 count=1 if=...
でそのファイルがあるディレクトリらしき所を見付けました。
ところが、debugfs で cd <1300447> とやっても
Ext2 inode is not a directory
となります。
<>内に何をいれれば該当ディレクトリにcdできるのでしょうか

e2fsck -n の結果は
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1107584 inodes, 2212953 blocks
110647 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2269118464
68 block groups
32768 blocks per group, 32768 fragments per group
16288 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
です。

XFSをハードウェアのRAID上（3ware 9500Sシリーズ）で使用しています。
というか運用を始める前にいろいろ実験してます。

Filesystem タイプ サイズ 使用 残り 使用% マウント位置
/dev/sda1 xfs 466G 359G 108G 77% /work1

ハードウェアRAID上でディスク拡張（OCE）を実施して
/dev/sda 自身のサイズが増えているのですが
/dev/sda1　のパーティションサイズを拡張させなければ
xfs_growfs　できないことに気がつきました。

で、partedでなんとかなんものかと思ったのですが
partedはXFSのりサイズに対応していないようで・・・。
ここで知恵を拝借したいのですが

・XFSを使用することを貫き通す場合、パーティション拡張するにはどうすればいいか？
　（LVM上に乗っけることくらいしか思い浮かびませんでした）

・XFSにこだわらないとすれば、どのファイルシステムであれば
　パーティションサイズ拡張　→　ファイルシステム拡張　ができるか

使い始める前にこのことに気がついてよかった・・・
何か逃げ道知ってる方いましたらアドバイスお願いしますだ。

fdiskで削除、作り直し

LVMしかないだろ。

>>724
LVMの256GB制限って拡張されたのかな？

どこの話？
PV？VG？LV？

>>726
VGの話なんだけど、ちょっと誤解してたわ。
前に作った時に、エクステントサイズを変更するのを知らんで
256GB以上のVG作ろうとして失敗したもんでそこが制限かと思ってた。

調べてみたらエクステントサイズを拡張すれば、ペタまでいけるんだな。

http://nobumasa-web.hp.infoseek.co.jp/partition/parted/
libreiserfsをインストして
partedでパーティションのリサイズやったことある方いますか？

ttp://www.suse.de/~agruen/acl/linux-acls/online/
JFS意外だな

>>728
qtpertedだったら二週間くらい前にやった。

小さくしたらちょいと壊れた…

>730
qtperted使えばreiaserfsのパーティション拡張いけますか？
どんな感じのオペレーションしたか差し支えなければ。
KNOPPIXあたり使ったんでしょうか？

libreiserfsインストしても
reiserfsのパーティション拡張できなくて血迷った発言してしまいましたが
マシンリブートしたら普通に
partedでreiserfsのパーティション拡張できました。
ご迷惑おかけしますた。

<チラシの裏>
結局いろいろ調べてみたけど
データそのままでXFSのパーティション拡張する方法は見つけられませんでした。
xfs_growfsでファイルシステムの拡張は楽勝でできるのに・・・うぅ
LVMは管理がややこしいのでちと避けたいの都合があるので
とりあえずはパーティション拡張できるreiserfsで行くことにします。
</チラシの裏>

<チラシの裏>

6TBの外付けRAIDは1TBづつ論理ボリュームが
切られているから、LVMなしではありえない。

そろそろ16TBの壁が見えてきた...

</チラシの裏>

<トイレの壁>

http://www.asahi-net.or.jp/~AD8Y-HYS/rakugaki.htm

当たり前のような質問かもしれないのですが
/dev/hda （300GB)上に
dev/hda1 （200GB)を作成してデータを格納した後
fdiskで/dev/hda1 をいったん削除。
すぐに /dev/hda1 を300GBで作成しなおした場合
ファイルシステムが200GBのままだと思うのですが
中のデーターって読めない状態になっちゃうんですよね？

</トイレの壁>

先に閉じ忘れちまったよ・・・ orz

パーティションの開始位置が変わってなくて、終了位置がファイルシステムの末端より後ろならその作業をいくら繰り返そうが読める

Win9xのfdiskだと読めなくなるがね

Windowsのfdiskが、内部の情報までクリアしてしまうのは、↓こういうの
http://cocoa.2ch.net/unix/kako/964/964868780.html
を防ぐためだと思うよ。

端的にいうと、パーティションを小さくきりなおした時でも
内部(ファイルシステム)の持つサイズ等の情報が残っていると
パーティションを越えた領域にまで読み書きが及んでしまう可能性があるから。

windowsは初心者が多いから、
「fdiskで見えなくしたから大丈夫」
と思う人が多いんだろう。だから、部分的に削除する必要がある。
Linuxの場合、いざというときのために削除しない。みんな分かってるしね。

<チラシの裏>
ReiserDriverのrfsdfsd.regがExt2fsdのをそのまま持ってきててわらた
</チラシの裏>

シーケンシャル書き込みをしたときに
書き込みが分断されにくいファイルシステムってどれになるんでしょうか？

Win機でキャプチャした動画をそのまま
LinuxのSamba上に直接書き込みたいのですが。

mkfsした直後のファイルシステムならなんでも

tmpfsオススメ

tmpfs いいね

ramfsとは一味違うよな

ext2でいいんじゃね？
同時にいくつものファイルを扱ったり、小さい(ブロックサイズより)ファイルを大量に扱うのなら他を検討したほがよいと思うけど。
ストレージ容量やファイルサイズが馬鹿でかいときはxfs,jfsがいいって聞くけど、普通の動画ファイル鯖ぐらいならext2で十分かと。
まあジャーナリングぐらいつけておいたほうがよいかとは思うのでext3かな

<!--

UNIX USER 2004年9月号の51ページ に

「XFSは、小さなファイルをｉノードに格納する機能を持っており、
当然ながら格納したファイルのパフォーマンスは向上する。……」

って書いてあるんだけど、これ嘘じゃん！　だまされたーーー！！

-->

メモリ256MBしかなくても2TBのtmpfs作れるんだから。

XFSはその機能あったと思うけど。
デフォルトだと、inodeが256byteしかないから使われないだろうけど。

mkfs.xfs(8)より抜粋

The XFS inode contains a fixed-size part and a variable-size part.
The variable-size part, whose size is affected by this option, can contain:
directory data, for small directories;
attribute data, for small attribute sets;
symbolic link data, for small symbolic links;
the extent list for the file, for files with a small number of extents;
and the root of a tree describing the location of extents for the file,
for files with a large number of extents.

ファイル自体をinodeに格納する機能は無いと思われ。

directory data, for small directories;
symbolic link data, for small symbolic links;

工エェーーー！

Solaris10　　 3/05版 2005/02/01 ZFS無し
Solaris10　　 4/05版 2005/06/14 ZFS無し
Open Solaris 5/05版 2005/06/17 ZFS無し
Open Solaris 6/05版 2005/07/20 ZFS無し
Open Solaris 7/05版 2005/08/18 ZFS無し

ソース落として見たけど、まだ入ってない。。
zfsまだかぁ〜ヽ(`Д´)ﾉ

詳解ファイルシステムの進捗遅くてゴメンナサイm(_ _;)m

zfsは2006にならなかったっけ？

ext2/3の話だが、
あるディレクトリにファイルをどんどん追加していくと、
ディレクトリサイズって、増えていくけど、逆に
そのでかくなったディレクトリ内のファイルをどんどん消していくと、
ディレクトリサイズって小さくなる？

Ｗｅｂで調べた感じでは、ポインタのみの移動で片付けられている。
これって、ディレクトリサイズは小さくならないことを意味してる？

syslogって、HDDやRAM Diskが一杯一杯になって書き込めなくなったら自動的に止まってくれるんですか？

>>760
くだらねえ質問はここに書き込め！Part 110
http://pc8.2ch.net/test/read.cgi/linux/1125241920/

2.6.13がでたけど、reiser4は今回も見送り。
やっぱりいらない子か...

まあファイルシステムがぶっこわれていた場合、
阿鼻叫喚の坩堝になりますからなあ。

慎重になってもらった方がうれすい。

Remember 2.4.5!

devfsがぁー！


…、使ってなかった。

iozoneでの結果。
Writer：ext3<<XFS
Re-Writer：exit3<XFS
Reader：ext3=XFS
Re-Reader：ext3>XFS
だいたい、こんな感じ。

XFS(デフォルト)、XFS(inode size=512)、XFS(inode size=2048)は、ほとんど変わんない。

fs/ntfs/inode.c を気まぐれに読んでたら
/* Bye, bye... */
ってのがあってなんかほろりときた

iozoneでの結果つづき。

Writer：ext3<reiserfs<XFS
Re-Writer：exit3=reiserfs<XFS
Reader：reiserfs<ext3=XFS
Re-Reader：XFS<reiserfs<ext3

>>759
消したあとに作成するとtruncateされるそうな(BSD)
なぜでしょうね?

>>768
あれ？raiserが早いって話はどこいったんだorz

>>759
小さくならないわけ無いじゃん。

>>759,769,771
テストしたよ。
# uname -r
2.6.12-gentoo-r9
# df -Th .
Filesystem Type Size Used Avail Use% Mounted on
/dev/hda4 ext3 17G 15G 761M 96% /mnt/hoge
# mkdir test1 && cd test1
test1 # ls -ld .
drwxr-xr-x 2 root root 4096 Sep 6 17:21 .
test1 # touch {0..9999}
test1 # ls -ld .
drwxr-xr-x 2 root root 122880 Sep 6 17:21 .
test1 # rm *
test1 # ls -ld .
drwxr-xr-x 2 root root 122880 Sep 6 17:21 .
test1 # touch a.txt
test1 # ls -ld .
drwxr-xr-x 2 root root 122880 Sep 6 17:22 .
test1 # cd .. && mv test1 test2
# ls -dl test2/
drwxr-xr-x 2 root root 122880 Sep 6 17:22 test2/
#
ディレクトリを異なるファイルシステムに持っていくと、小さくなった。
ちなみに、reiserfs 上では、ファイルを削除した時点で、ディレクトリサイズは縮小された。

>>769
ファイルを消した時に同時にディレクトリもtruncateすると、
直後に作成されたファイルのためにまたディレクトリが伸びることになります。
そしてそれを消すとまたtruncateされる。
この繰り返してslashingが発生するので、
truncateされるのはファイルが増えた時だけなのです。

>>773
raiserfsは何で律儀にtruncateできるんだ?

あとUFS+softdependだとcreate/unlinkは非同期writeになるのでunlink時にtruncate出来ると思う。
ただcreate時までtruncateを遅らせるとCPU時間を節約できる利点はある。

>>774
slashingが起きても気にしないからでは。

UFSはCPU/diskの速さが今と100倍違う時代の設計ですから、
新しいfilesystemではでっかいcacheでなんでも吸収できてしまうと考えて
細かいことを気にしない設計であってもおかしくありませんよ。

冗談はさておき、
UFSはindirect blockが非常に高コストですからtruncate後に起きることに対して
神経質になる必要があります。対してreiserfsは小さなブロックをinodeに格納して
ブロックの手配を遅らせることができるのでslashingは起きません。

てな感じでしょうか。

スラッシングはthrashingじゃない?

ファイル操作ベンチマークテストツール作ってみました。
（ create、open、utime、stat、unlink )

ttp://www.wikihouse.com/linuxfs/index.php?tool
からどうぞ。

あと、おまけで、Cソースの整形スクリプトも置いてます。
不具合等の報告、改善案ありましたらよろしくです。

> あと、おまけで、Cソースの整形スクリプトも置いてます。

タブでインデントしている馬鹿専用？

タブ正規化している部分を省略して
spaceのままのほうが良いかな？
他の部分はどう？>>778

私はタブでインデントするので。。。
タブ派？space派？用に2つ用意しますか。

タブでインデントすることのデメリットが大して思い浮かばないのは俺だけですか？

タブ幅が違う環境だと、見え方が変になるとか……
でもスペースも手打ちだとやりにくい (手打ちするなよ、って話ですが)

エディターでいくらでも何とかなる時代にオールドタイプな話をしてんのね。

いちいちタブ幅を変えんの、めんどくさくないっすか?
まあ↑の方のやつの反応はどう考えても過剰と思うけど。

俺はタブ派ではあるが、基本的にはどっちでもいい。
が、多人数でメンテしているソースがタブとスペースが混在しているのは、激しく萎える。

expandでもつかっとけ。

GNU indent つかっとけ

778=リチャード・ストールマン

SELinux有効にしてあるマシンで、mkfs.xfsでi-nodeのサイズを指定しなかったんだけど、
具体的のどの程度パフォーマンス落ちるんですかね。ディスクを無駄に食うのはあんまり気にならないんですが。

160GBのディスク中の100GBのfsで既に90GB使ってるから、別のディスク持ってこないと待避出来ない状態。
まあsquidのキャッシュだから捨てても良いんだが。
そもそも、約200人ぐらいのユーザしかいないのに90Gも要らないし。なに考えてたんだろう。

インデントは基本4spaceで、8の倍数ならtab派。
面倒なときは全部tab。

>>788
>>729

reiser4って2.6.14でもスルーされそうなふいんき?
Hansタソに怨みでもあるのかな...

Remember 2.4.5!

NILFS
http://enterprise.watch.impress.co.jp/cda/software/2005/09/26/6239.html

NetBSDのLFSを移植したわけではなさそうだな。

Win機でXFS読む方法(出来れば書きも)ってないでしょうか？
VirtualPCでLinux入れるしかないのかな。

NILFSの不思議な旅

>>792
lkmlにアナウンスないよね。
彼らは自分達だけでメンテしていくつもりなのかね。
live-patchingの時みたいに。

>>796
live-patchingはlkmlに出てきたぞ。
実装がアホすぎて相手にされなかったが。

NILFSはどうすんのかね。
まずは教祖様の所で叩きまくっていただきたいなあと思いますな。

教祖様はLFS支持派じゃなかったっけ？

LFSってなんだよ。
Linux From Scratch？

Log-structured File Systemってことぐらい>>792の記事にも書いているというのに、
799の知能障害っぷりはすさまじいな…

>>797
live-patchingってなに?って聞こうと思ったが
>>800の用に罵倒されるだろうからlkml検索した。

jump突っ込んでリスタートしないでpatchを突っ込む機能?
なのは分かったが、実装のアホさをかげんを語ってほしい。>知ってる人
i386 と x86_64 でしか動かないところとか?

live-patchingは実装以前に、なぜその機能が必要なのかを
議論して説明できなかったことが問題ではないかな。

だって顧客が（いままでのやり方を変えたくないから）
必要だって言うから、なんて理由ではねぇ。

それにわざわざkernelいじってsyscall追加しなくても既存の仕組みだけで実装
できちゃったしね。

>>797
えっ、教祖様がNILFS書いたんじゃないの?

>>804
教祖様は別の研究所でつ。

tmpfsについての雑誌記事をよみ、
さっそくメモリ512MBなのに、
/tmpをtmpfsにしました。
かなり体感上高速化できたので、
調子こいて/usr/tmpと/var/tmpも/tmpのシンボリックリンクに貼り直し、
/usr/src/package/BUILDも/tmpのシンボリックリンクに貼り直しました。
さすがにここまでくると512じゃ足りません。
2GBまで増設しようと思います。

>>806
つ【i-RAM】

>>806
/usr/tmp や /var/tmp には、
再起動で消えちゃ困るファイルを置くから、
tmpfs にしてはいかんのでは？

そもそも /usr/tmp なんてもう使わんだろ。
ls -ld /usr/tmp してみ。

それでは/usr/tmpと/var/tmpはtmpfsやめます。
/var/tmpもう一回掘って、/usr/tmpはそのリンクにします。

i-RAMですか……。もう1GBのメモリを注文してしまいまそた。

symlinkはダサい
bind mount汁

>>810
落とす時にどっかに退避するとか。

>>811
bind mount がダサくないとする件について語ってもらおうか。

>>813
symlinkよりbind mountが後でできたらかじゃないかな？
古いものはダサいという。

新しいか否かだけで、優劣が決まるわけじゃないし、適材適所っつーのもあるし、
その辺を含めて >>811 に語っていただきたい。

symlinkはsimple is the bestって感じで好きだけどなぁ。お手軽な実装で最大の効果。

bind mountなんて使ってわざわざfstab増やさなくても、symlinkでええやん

symlinkすんのとbind mountすんのとどっちがコスト低いんよ？
教えてエロイ人

>>818
その前にコストとは何か定義しろ。話はそれからだ。
動作スピードか？手順の容易さか？管理の複雑さか？かかる時間か？必要な経費か？

NILFS 期待できる?
ttp://d.hatena.ne.jp/kazama/20050927/p1

http://www.nilfs.org/

FS-p?
nil

>>820
--
最大の問題は, まだクリーナ (GC) が未実装でディスクを使いきるとそこで
おしまいになってしまうことです. snapshot を維持した効率的 GC はなかなか
難しく, 公開には間に合いませんでした.
--
少なくともこれが解決するまでは、評価対象にもならん。

GCなしのLFSって何の冗談だよ…。評判の悪いNetBSDのLFSだってGCなしなら
そりゃとんでもなく安定して動くぞ。

write onceメディアで使えば無問題

げ、GC無しなのか。。。

9fs

たぶん、雨海さんはGCへの興味からLFSを実装し始めたのだから、
「効率的」のところで色々挑戦したいことがあるのでしょうね。

どうせそのち、みんなNILFSの事なんか忘れて、
GCも実装せずに済むのを待ってるんじゃまいか？

現状のファイルシステムのスタンダードって何？
いまだに ext3?

http://www.nilfs.org/ の TODO List に並んでいる項目を眺めてみりゃ
まだアルファ品質レベルなのは明らか。
それなのにバージョン1.0.0としてこのタイミングでリリースしたのは
NTT内部でいろいろ政治的な問題があったんだろうね。

>>828
未踏のプロジェクトだったら間違いなくそれだよなｗ

disk fullになったら落ちるのか
(((；ﾟДﾟ))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

Known Bugs
The system hangs on a disk full condition.

　　　　　　　 　 　 . ｨ
.._ .......､._　　　 _　／:/l!　　またまた、ご冗談を
　:~""''.>ﾞ' "~　,､､''‐'､|　　　　　　　　　_　　　　　　
ﾞ､'､::::::ﾉ:::::::_,.-=.　 _〜:、 　 　 　 　 ／_.}'':,
　``､/:::::::::__....,._ `ﾞ'Y' _.ｪ-､....._　／_ﾞ''iﾞﾉ､ﾉ
　,.--l‐''"~..-_'.x-='"ﾞｰ ､`'-､　,:'　　ﾉﾞﾉﾌﾞ　　　　　
"　　 .!-'",／　 `'-‐'') /＼　`/　てﾞノ-〈
　.-''~　>'ﾞ::　　　 ‐'"ﾞ./　　ヽ.,'　　 ~　／
　　 ／/:::::　　　　 　 ',　 　 /　　　 ,:'

NetBSDが苦労してたのが、サクっと出てきたのかと思ってｽｹﾞｰってって思ったのに、
肝心要の部分は、出来てないんですね(´･ω･`)

GC抜きのLinux用LFSを一から作るより、NetBSDのLFSのGCに手を入れて安定化を
目指すほうが、技術的には1万倍ぐらい有用だと思う。ってことでNILFSの目的って
NTT研でこんなことやってますよってアドバルーンを上げることだけなんだろうな…

>>833
　　　　/ノ 0ヽ
　 　＿|＿＿_|＿
　 　ヽ（ # ﾟДﾟ）ノ　　ゲイツのファットの方がまだ気合いが入ってる！
　 　　　|　个 |　　　　　
　 　　ノ|￣￣ヽ
　 　　　∪⌒∪

ttp://d.hatena.ne.jp/kazama/20050927/p1 を読むと、
開発側は、GCが出来てないのを問題と認識してるみたいだね。
重要なGCを未実装で出すなんて、成果を早く出せみたいにせっつかれたんだろうか。

>>837
なにかに間に合わせるためにとりあえず発表つー感じですな。

まあ発表した所で、時限爆弾を抱えているファイルシステムなんて物を、
評価以外で使う人はいないと思いまふが。

ここは白痴のスレか？それとも釣堀か？

トラックバック:http://d.hatena.ne.jp/kazama/20050927/p1

>>840
歳をとるとアレというよい例ですな。

自分は結構楽しみに待ってたりする。
気長にいこーよ。

つーか今は使い物になる前に公開するのが基本だろ？

>>843
jfsとか?

いやmergeはちょっと…

>>843
GCなしのLFSは使い物になるかどうか以前の問題なんだけど。
一番重要なところが実装されていないどころか、仕様すらできていない。

上半期末だったのでチャレンジシートに書く成果のために急いていたのかねえ。
もっともあと半年待ったところでどうにかなるものでもなさそうだが。

>>847
この成果でチャレンジシート書いても良い評価はもらえんような気もするが。

>>752 ：login:Penguin：2005/08/19(金) 01:12:20 ID:eyFrYcEH
>>メモリ256MBしかなくても2TBのtmpfs作れるんだから。

って有るんだけど　どういう意味？誰か教えて。

>>849
実メモリ以上の大きさの仮想メモリが確保できます という話

結局swapするんだけど。
プロセス用のメモリを圧迫してしまわないかが心配なのだけど、パフォーマンスはどうなのかな？

馬鹿の心配、するが問題

ファイルシステムの容量以上の sparse file 作って
全部埋めようとしたらどうなる？

おまえの馬鹿さ加減が知れる

>>851
何もかもスワップします
スワップするとパフォーマンスは落ちます

研究用にLinuxに新しいファイルシステム作る研究っていくつもあるけど、
やりかけで発表して、そのうちLinuxカーネルのファイルシステムや
バッファキャッシュに大工事が入って、内容を把握できていない第三者には
メンテできない状態になってそのまま放棄っていうパターンが多い気がする。
Linuxで昔LFS実装してGC前にやめた人がいたよな…論文書いてジ・エンド
だったような。

>>849
sudo mount -o size=2048g -t tmpfs /dev/shm /var/tmp
とかできるってことだろ。

>>851
1Gメモリのマシンでtmpfsで1G使い切ってもシステムは動くから問題なし。

tune2fsしてなかったext3で電源ぶち切れたら起動時にfsckにぶっ壊されてデータが全部消えてた
アッタマきたから全部reiserfsに入れ替えたよ

>>858
気になる。ぶっ壊れたext3のfilesystem featuresはどんなでしたか？

こういうのは、大概アホの操作ミスなので参考にならない。
おまえふだんからrootユーザで使ってるような奴だろう?

>>860
バカだな。アホの失敗こそが参考になるんだよ。

Reiser4は前途多難だな

reiserfsって大きなパーティションのマウントにやたら時間かからない?

nilfs 1.0.1 age
http://www.nilfs.org/

>>864
相変わらずGCが実装されていなくて、使い物にならない罠

LFSのGCはいくら彼等でも大変やろ

でも、GCのないLFSは完全に無意味でそ。一番重要な部分なんだから。

数年後に別のOSで別の実装が出てきた時に、
Related paperに名前が乗るだけでいいと
おもってるんだよ。

Gentoo Weekly Newsletterにこんなのがありました

ext2/3がReiser4に匹敵する速さを持てる
ttp://www.gentoo.org/news/ja/gwn/20051017-newsletter.xml#doc_chap5

最近のディストリビューションだとインストーラから作ったファイ
ルシステムは最初から dir_index 有効になってない?
とりあえず手元のFedoraCore3では既に有効だった.

Fedora使ってると世間の動きののろさに驚かされる

Fedoraの意味は失われていないと。

>>870
そんなんFedoraだけだよ〜。∴RHEL4でもそうなってるし。
"."と".."が真ん中らへんにあってめちゃうざいんで、速攻
# tune2fs -O ^dir_index /dev/hda1
してます(tarファイルを作るときなんかばばっちくなるから)。

意味不明

>>873
確かにそういう問題はありますな。理解できない人は、既存のtarファイルを
一旦展開して再度固める作業を、非dir_indexファイルシステムとdir_index
ファイルシステムで同様に行って、オリジナルのtarファイルと比較してみ。

それが問題だと言ってしまう脳に問題があるように思うがな

なんかさ、
FAT で育って FD とかでディレクトリエントリを
操作することのみに人生を捧げてきた香具師とか
そんな感じの痛さだぬ。

そういう人がいてもいいけどファイルシステムを
どうこう言うスレに来るのは場違いだな。

>>873
財布の中のお札が、製造番号順じゃないと気が済まない人もいると聞いたのですが、あなただったんですね。

Reiser4と激怒するLinuxカーネル開発者たち（1/2） − ＠IT
ttp://www.atmarkit.co.jp/flinux/rensai/watch2005/watch10a.html

DVD-RAMの書込速度がReiser4だとUDFとEXT3の倍、Reiserfs3の1.5倍速かった。

>>439の取引先が後臨されたようですねｗ

>>878
> 財布の中のお札が、製造番号
硬貨を製造年順に並べている香具師も居ますね。ｗ
でもこれって、単にソートすればいいんじゃない？
readdir(2)に関わる基本コマンドって、
ls
tar
find
他にあったっけ？

それ以前に ls をわざわざ -f 付で使う香具師なんているのか?

>>882
オレは額面順にソートしてるな
大量の1万円札の中に混じってる1000札ってすごい見つけづらい

俺の財布には千円札しか入ってないから、ソートする必要がない。

俺の財布には千円札すら入ってないから、ソートする必要がない。

1枚だけならソートしなくても良い

>>879
| Christoph Hellwigは、ReiserFSの中でLinuxのI/Oの機構が再実装されている
| 理由を説明するか、再実装を止める必要があるだろうと宣言しました。

ﾆﾔﾆﾔ

>>888
そりゃあ、OS標準のI/Oが腐っているからだ罠…

xfsもI/O自前とかって話なかったっけ？

なんかdebugreiserfs -q でオンラインバックアップみたいなことできる

http://www.atmarkit.co.jp/flinux/rensai/fs05/fs05b.html

って書いてあるけどほんとにこれでバックアップとして活用できるのかな？
だれか試した人いませんかぁ〜

RCU導入でファイルアクセスにロックが不要に？
ttp://www.atmarkit.co.jp/flinux/rensai/watch2005/watch10b.html

題名が変だぞw
この言い方だと全くロックしてないみたいじゃねーかよ。
ロック無しでどうやって整合性とるんだよ。

ごめん、debugreiserfs -p /dev/xxxn ね

>>892
>ロック無しでどうやって整合性とるんだよ。
リンク先の
>編注：RCUについては、「全貌を現したLinuxカーネル2.6［第1章］」も参照。
嫁

>>〜ロックが不要に？
ありえない。

おまえこそソース嫁 >>894

よくわかんないので誰か教えておくれ.
>>892の記事は端から間違いなの?
それとも「ロック」という一般名称が問題で,
「RCU導入でread(),write()のためのspinlock()が不要に」
なら問題ないの?

つーか、誰もRCUについて理解せずにレスしてるみたいな。

RCUってロックフリープロトコルの一種だったと記憶してるんだが。
ロック無しで整合性を保障する手法。ちょっと前のInterfaceに
載ってたけど、あれをそのまま応用しただけなんじゃね？

↓の組み込みプログラミング・ノウハウ入門ね
ttp://www.cqpub.co.jp/interface/contents/2004/200411.htm

おまえらって限りなく白痴に近いよな
http://en.wikipedia.org/wiki/RCU

つか、RCUを使ってる構造体ってのはどれなわけ？

　　　　　　　 lヽ ﾉ l　　　　　　　　ｌ l　ｌ ヽ　　 ヽ
　 )'ｰーノ(　 |　|　 | ､　　　　　 / l｜ ｌ　ハヽ　　|ｰ‐''"ｌ
　/　Ｒ　　|　|　|／| ﾊ　　/ / ,/ /|ﾉ /l /　ｌ l ｌ|　ｌ　 Ｒ ヽ
　l 　 ･　　i´ |　ヽ､| |ｒ|| |　//--‐'" 　 ｀'メ､_ｌﾉ| /　 ・　 /
　|　 Ｃ　　l　 トー-トヽ| |ノ　''"´｀　　　ｒｰ-/// |　 Ｃ　｜
　|　 ･　　 |／　　 　 | l ||､　''"""　 j　""''/ | |ヽｌ 　・　｜
　|　 Ｕ 　 |　　 　 　 | l |　ヽ,　 　― 　 ／　| |　ｌ　 Ｕ　 |
　| 　 !!　 |　　 　 /　| | |　　 ` ｰ-‐ ' ´||　,ﾉ| |　|　　!!　｜
ノｰ‐---､,|　 　 /　│ｌ､l　　　　　　 　 |ﾚ' ,ﾉﾉ　ﾉハ､_ノヽ
　/ 　　 　 　 ／　ノ⌒ヾ､　 ヽ　　　 ノハ,　　　 　 |
,/ 　 　　　,イーｆ'´ /´　　＼　| ,／´ ｜ヽl　　　 　 |
　　　　 ／-ト、|　┼―- ､_ヽﾒr'　, -=ｌ''"ハ　　　　|　 ｌ
　　 ,／　 　|　ヽ 　＼　　_,ノｰｆ' ´　　ﾉノ　 ヽ　 　｜　|
､_　　　 _ ‐''ｌ　　`ー‐―''" ⌒'ｰ--‐'´｀ヽ､_ 　　_,ノ　ノ
　 ￣￣　　 |　　　　　　　　　　 ／　 　　　　￣

> ttp://www.atmarkit.co.jp/flinux/rensai/watch2005/watch10b.html
> この影響により、CPU数が多いシステムで複数のCPUを利用したプログラムが大量に
> ファイルシステムI/Oを発行するような事態の改善が期待できるようです。

「改善が期待できるようです」ってよくわからん表現じゃなく、
実際のベンチマークの結果とかはないのかなあ。

おまいら、ソース嫁よw

RCU は、要は、
VRAM 裏画面で描画しつつ、
CRT に表示されるのは VRAM表画面、つーことか？
で、表画面を完全に表示し終わったら
裏画面の内容を垂直回帰期間中に表画面に転送すると、そういう感じ？

RTFS

>>903
頭悪いのに無理して理解したつもりにならなくてもいいから

>>903
ROTFL

Is it a PC98 machine, isn't it?
Wow, I feel very nostalgic.

DragonflyBSD では lock 排除を messaging でやろうとしてて
wikipedia によれば
| The serializing token code is evolving into something quite similar to
| the "Read-copy-update" feature now available in Linux. Unlike
| Linux's current RCU implementation, DragonFly's is being implemented such
| that only processors competing for the same token are affected rather than
| all processors in the computer.
ttp://en.wikipedia.org/wiki/DragonflyBSD

reiser4でのbadblockの扱いについてご存じの方いませんか？

reiserfs のときは、badblockを指定してファイルシステムを作成できたのに
reiser4だとダメみたいなんですが、これって自動ってうまいことやってくれるってことなんでしょうか・・・・・？
最近、LANDISKがカッチョンカッチョン言い始めて怖いのです・・・・

>>907
ぜってーうまくいかねー。ぜってーだ！

MS Officeを動作させる話題の"David"搭載、2年ぶりの待望のメジャーバージョンアップ
新製品「Turbolinux FUJI」発表

2005年11月25日より販売開始

ターボリナックス株式会社


同新製品は、2003年10月にリリースされ、リナックスOS分野で前人未踏の
52週（1年間）連続売上第一位（BCN調べ）を記録し、
数年来国内売上シェア第一位を誇るターボリナックスの
基幹デスクトップ製品「Turbolinux 10 Desktop」（以下10D）
の後継製品にあたり、 国産OSならではの完成された日本語環境はもちろん、
10Dで提唱したWindowsとの互換性をさらに強め、安全性、 安定性に優れた
デスクトップ環境を提供します。Windows環境との共存の強化により、Linux
とWindowsの優位性を融合した ハイブリッド・デスクトップリナックスOSとして、
企業、官公庁、自治体、教育機関などへの導入をより一層スムーズなものとします。
FUJIではOS本体とプラグインという新しいビジネスモデルを展開します。
これにより、ユーザーは基幹OSであるFUJIを入手すれば、
用途に応じてプラグインを足すだけで自分だけに特化したOSを利用することが可能となります。
現時点において、ビジネスユース向けプラグイン、 ホームユース向けプラグインやURLフィル
タリングソフトなど、セキュリティ関連プラグインの提供を予定していますが、都度ユーザー
ニーズを 市場から汲み取り、タイムリーに新しいプラグインを提供することがFUJIの価値を高
めるものと考えています。なお、FUJI発売と同時に プラグイン第一弾としてサイバーリンク社
の「PowerDVD for Linux」が決定しており、これら各種プラグインは新ツール"Turboプラス"経
由で提供し、 ユーザーは簡単に購入、ダウンロード、インストールができるようになります。

http://www.turbolinux.co.jp/cgi-bin/newsrelease/index.cgi?date2=20050920033408&mode=syosai

結局 UFS2+S に行き付く。

うひょー。
reiserfs(3.6)、FAQには最大ファイルシステムサイズ 16TB
とあるけど、実際には8TBに壁があるとわ。ハマッタぜ。

>>912
よく試せたね。情報サンクス

すげーな。8T越えか。
jfsとかxfsはどうよ？sunのzfs(だっけ)とかも気にある。
さすがにそれだけあると再フォーマットする気にもならんだろうけどさ・・・

>>912
それで壁の原因はなんだったんですか？

xfsにしました。jfsは自分ではほとんど使った事がないので。

原因というか、なんか動作が変なんでぐぐってたら
reiserfsのMLでこういう記事を見付けて、ああそれで、と。
ttp://marc.theaimsgroup.com/?l=reiserfs&m=112255940804474&w=2

ttp://namesys.com/mount-options.html
によると、reiserfsにも
data=ordered / journal / writeback
のマウントオプションが存在する。

全然知らなかったんだが、使い分けしてみたって人いる？


と、いうか知ってた？

とっくのとうに

常識

もっと早く言ってよヽ(`Д´)ﾉｳﾜｧｧﾝ!!

ttp://archives.free.net.ph/message/20050809.020823.21ffe4a1.en.html

>>920
ご利用は計画的に。

4G(32bit) x 512B(1block) = 2TB だしな

>>920
要するにxfs_repairはファイルシステムの中に書かれているファイルエントリが
多ければ多いほどメモリを食う仕掛けになっているが、ia32 (i386)環境では
プロセス毎に最大で4GBに制限されているため、いくらメモリを積んだところで
巨大なファイルシステムには対応できない、ということか。

8TBが、IA32 Systemでの xfs_repair を実行するには大きすぎる、
ということは分かったのですが、実際、IA32ならば何TBまでOKなのでしょうか。

4TBまでならばOKなのか、もっと小さいのか。

>923 を見る限り 8TB が大きいっつーよりは
ファイル・ディレクトリの数が問題なんじゃないの?

一つ辺り数GBな映像ファイルしか格納しないなら問題ないとか?

>>923
>いくらメモリを積んだところで...
Windowsのリソース64k制限を思い出したよ

ちんちんおっき

920のメールのスレであったけれど、
だいたい、1TBにつき1GBメモリが必要だそうです。

たしか、これ。
ttp://archives.free.net.ph/message/20050810.085849.54822be5.en.html

自動じゃなくユーザーによる手動GCを実装予定って本気かnilfs

>>930
それ、PostgreSQLのvacuumみたいだな…
まあ、PostgreSQLはlog structureだから似たような感じになるのは当然だけど。
PostgreSQLの場合8.1からはauto vacuumがデフォで入って、ユーザから
vacuumをあまり意識する必要なくなったけど、nilfsではまだ手動vacuumを実装すら
していない段階…

>>930
LKCの話を聞いてきたが、まともなGCが入るまで時間がかかりそうだのう。
当分は手動で頑張るしか。

まあお遊びレベルならcronあたりで使ってない時間帯にGC走らせればいいんでないかい。

>>930
いつGCするのが一番良いかは、たいてい管理者がしっているはずなので、
自動でするよりもいいんじゃないの?

だがそれは、平時は自動GCで かつ ユーザが緊急時に手動GC可能
というのが本来の動作のはずだ

zfsようやくｷﾀ Y⌒Y⌒Y⌒Y⌒Y⌒Y⌒(｡A｡)!!!

Solaris10発表から約1年。。

最大ファイルシステムサイズ : 1YB
最大ファイルサイズ　　　　　　: 8EB

OpenSolaris build 27 にて
zfs のソースコードがマージ

実際に使えるかどうかは別ですが・・・

●ダウンロード
ttp://www.opensolaris.org/os/

●ZFSコミュニティ(BUG報告等もコチラ)
ttp://www.opensolaris.org/os/community/zfs/

●リリースノート
ttp://www.opensolaris.org/os/downloads/releasenotes-20051116.txt

暇になったら詳解しまつ

>最大ファイルシステムサイズ : 1YB
>最大ファイルサイズ　　　　　　: 8EB
理論上はそうかもしれんが、実際のところどこまでチェックして
あるのだろう。

>>936
確かに気になるね。
最大○○はビット数さえ増やせばとりあえず実現できるし。

そんなことより、copy-on-write はマジメに動いてるのか、
snapshot がマジメに動いているのか気になるところ。
あと、storage pool とかで sds が不要になるのはいつ頃だろうか。

Linux2.4もしくは2.6環境で使えて、
オンラインのスナップショット機能がある
ファイルシステムってどんなのがありますか？

環境テスト用なのでVMwareでもいいんだけども。

>>938
LFSのやつがスナップショット使えなかったっけ？

>>938
FreeBSDなら5.x以降のUFS2使ってスナップショット作るけど、
LinuxだとfsでやらずにLVMでやれば?

ext2/ext3で、使われてないブロックをゼロクリアするようなツール・方法ありますか？
ddで取ったパーティションのダンプイメージを圧縮する時に、
圧縮率を高めたいというのが目的ですが。

とりあえず一度でかいファイルを /dev/zeroから生成して削除することで
ある程度の効果はあるようですが、もうちょっとスマートにやりたいのです。

使用率が少なければdump/restoreするほうが速いだろ

使われてないブロックがたくさんあるなら、
ファイルシステム上で圧縮したら？

レスありがとうございます。

>>942
dump/restoreですか。使えるかどうか検討してみます。

>>943
納品物件として、稼動するシステムのディスクイメージってのがあるんで
個々のファイルを圧縮するってのは無理なんですよ。

dd if=/dev/zero of=hogehoge bs=1024k count=てきとう
mkfs -text2 hogehoge
mount -o loop hogehoge /mnt
cp -ar 納品物 /mnt
umount /mnt

とか。

どうしても今ある物を吸い上げる必要があるなら、
でかいファイルを作るのがいちばん安全じゃないかと。

それをやるなら
touch hogehoge
mkfs -t ext2 -f hogehoge てきとう
のほうが早い。

>944
FreeBSD で UFS つかって ufscopy こそが正解

ダメですか…

>>946
うちのだと -f じゃなくて -F みたい。
でも mkfs だと sparse なファイルになっちゃわない?

>>948
あとで圧縮する予定なんだからsparseなファイルで問題ないだろ

945 のプロセスの一部を置き替えるだけだったのね。
既存ファイルシステムの空きを全部 zero fill する簡単な方法のつもりなのかと思った。

partimageでいいじゃん

デフラグのアルゴリズムってどんな？

単純にファイル長確保できたディスク領域に連続配置するだけだと
デフラグによる速度低下ってありそうなんですが．．．

詳しく載ってるHPがあれば教えて下さい


＃デフラグのオーダーってどのくらいだろう！？

>>952
デフラグのガイドライン２
http://ex13.2ch.net/test/read.cgi/gline/1132424555/

ここがわかりやすい

http://ex13.2ch.net/test/read.cgi/gline/1132801607/l50

∞

>>944
亀レスですが・・・
稼動してる状態でディスクイメージ作るなら
mondorescueなんてのもありますね。
ブータブルDVDなんかも作れるしなかなか便利ですよ。

ZFS突撃報告キボン

>>957
Linuxで使えるんかいな。

いやさすがに無理だろ
誰もポーティングしてねえよ

今現在UDFの書き込みってのはどの程度安定して使える物なんだろうか?
ちょっとDVD-RAMでも使ってみようかなと考えてるんだけど。

一応Windows XPにPanasonicのRAMドライバーを入れた物で
UDF2.0フォーマットのDVD-RAMディスクに書き込み、
それをLinuxマシンに入れて読み込めることを確認、
Linuxで小さなテキストファイルを書き込んでWinXPの方で読み込める事を確認した。
とりあえずは問題なく動いてるようだけど、
それなりに運用経験のある人の意見が聞きたいなあと思ったので。

いっぱいありすぎてﾜｶﾝﾈｰ奴は
ext3(とext2)をつかっとけってこと？

ま、そうかな。
有名どころならハズレってことは特にないだろう。

Google SoC 2005からFUSE for FreeBSDなど - 若者に与えられた活躍の場
http://pcweb.mycom.co.jp/articles/2005/11/15/googlesoc/

環境を再構築したのでext3からRaiserにしたんだけど、システムの起動やアプリケーションの起動が早くなった気がする。
Raiserの方がパフォーマンスいいの？

>>965
その質問の回答は、「得手不得手がある」としか言いようがない。
どっかでベンチマークみたことあるんだけど…どこだったか忘れた。

>>966

俺も書いた後でそう思った。スマン。

デスクトップ用途で使っているんだけど、どっかにベンチマーク資料ないかな

2.6.15が出たね。

2.6の正式バージョンが出てからもう2年になるけど、
そろそろ安定した？真面目に使い始めようかな・・・迷う。

無停止稼動し続けなきゃいけないとか2.6では今のシステムが動かないとかならともかく

>>967
ずいぶん昔の資料なら見た覚えがあるけど
最近のカーネルだと結果変わってくるんじゃない？
自分でベンチ取るのが早いかもよ

もはや2.6じゃないとなんだか不安です。セキュリティ観点だと。

そういえば，カーネル2.6のNFSってページキャッシュ使うんだっけ？

記憶では2.6になってからページキャッシュに渡さずに
直接ネットワークプロトコルに渡すよーになった気がするんだが，，，

分かる人居たらレス　キボンヌ

　 ∧＿∧ 　+
　（0ﾟ・∀・）　ﾂﾔﾂﾔ ﾃｶﾃｶ
　（0ﾟ∪ ∪ +
　と＿_）__）　+

OCFS2 キタ━(゜∀゜)━!

2.6.16-rc1から使用可能になりまつ。
楽しみです。

Oracleの作った並列ファイルシステム。
ところどころにxfsのソースを参考にしてますというコメントが。。。

>972

CONFIG_NFS_DIRECTIOでカーネルmakeしていてなおかつ
ファイルのopenmodeがO_DIRECTならデータをキャッシュに
乗せない

と思う。。
サーバ側とクライアント側、NFSv3とNFSv4共通なのかな？
気になってきたけど、 (つ∀-)ｵﾔｽﾐｰ

Benchmarking Filesystems Part II
http://linuxgazette.net/122/piszcz.html

やっぱりreiserfsのmountは時間がかかるのか

reiserfs使ってるやつは彼女にマウントするのにも時間がかかる

俺にはマウントポイントが見つかりません。

つshared mount

ループバックがあるじゃないか

reiser4は、マウントした後は早いらしいぞ

NFSで遠距離

遠くにいる彼女と VPN で接続したいのですがどうしたらいいですか？