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

過去スレ

01 http://pc.2ch.net/test/read.cgi/linux/1006743807/
02 http://pc5.2ch.net/test/read.cgi/linux/1063025258/
03 http://pc8.2ch.net/test/read.cgi/linux/1101495293/
04 http://pc8.2ch.net/test/read.cgi/linux/1136695633/
05 http://pc8.2ch.net/test/read.cgi/linux/1152348695/
06 http://pc11.2ch.net/test/read.cgi/linux/1164457481/

ext4
http://www.bullopensource.org/ext4/

reiserfs/reiser4
http://www.namesys.com/

xfs
http://oss.sgi.com/projects/xfs/

jfs
http://jfs.sourceforge.net/

zfs
http://www.sun.com/2004-0914/feature/

nfs
http://nfs.sourceforge.net/

ntfs
http://linux-ntfs.sourceforge.net/

fuse
http://fuse.sourceforge.net/

[次世代] ZFS [ﾌｧｲﾙｼｽﾃﾑ]
http://pc11.2ch.net/test/read.cgi/unix/1146631270/

ジャーナリングファイルシステム
http://pc11.2ch.net/test/read.cgi/linux/1173530292/

スマソｏｒｚ．．．
ジャーナリングファイルシステム
http://pc11.2ch.net/test/read.cgi/unix/979408065/

FS関連スレ
http://pc11.2ch.net/test/read.cgi/os/1137387538/

# 一応リンクね。

煽り
荒らし
人格を中傷するような発言
UPSを使えばFSを守れる等、FSにとって無意味な発言

このような事はスレが荒れるのでしないように

>>1-8
乙です

女性は働きたければ働いて､働きたくなきゃ働かない､辛くなったらやめていい｡
そもそも女性に辛い仕事を押し付けないこと｡かといって雑用やらせるのもﾀﾞﾒ｡
それで給与も昇進も平等にね｡ただし残業､転勤､深夜当直させたら女性差別だよ｡
間接差別禁止規定って知ってるでしょ｡なんでも平等にね｡髪形と服装は女性の自由だけど｡
それからｱﾌｧｰﾏﾃｨﾌﾞｱｸｼｮﾝと管理職30%目標もね｡産休育休もね｡当然給与40%保障で｡
主婦と言っても､家事を強制される言われはないし､出産するかどうかは女が決めること｡
でも産まれたら育児を女性に押し付けないでね｡二人の子供なんだから当然でしょ｡
ただし離婚したら親権は母親のものだよ｡育児は女性のほうが向いてるんだし｡

それから働く夫を妻が支えるなんて時代遅れの女性差別｡
これからは働く妻を夫が支えなきゃ｡
あ､もちろん収入は夫の方が多くて当然だけどね｡妻には扶養請求権だってあるんだから｡
それと夫は妻に優しくね｡妻が望まないｾｯｸｽは家庭内ﾚｲﾌﾟだよ｡
夫が妻のｾｯｸｽの求めに応じないと離婚事由になるけどね｡
離婚したら慰謝料とか財産分与とかまあ当然だけど｡
女性はか弱いから母子手当ても生活保護も税金控除も当然だよね｡足りないぐらい｡

それと女性に女らしさを押し付けないでよ｡
そんなの窮屈で面倒だし､いまさら男尊女卑ですかって感じ｡
でも男はやっぱ男らしくないとね｡
いつになったらﾚﾃﾞｨｰﾌｧｰｽﾄ覚えるの?ﾜﾘｶﾝなんてありえないし｡
少子化だって男のせいでしょ｡男がだらしないから女性が結婚できないんだよ｡
え?ﾚﾃﾞｨｰｽﾃﾞｰ?あれはいいの｡
別に私たちが頼んだ訳じゃないし｡店が勝手にやってるんでしょ｡

圧縮ファイルシステムってcompr-ext2とjffs2だけ？

readonlyでいいならsquashfsも

JFFS2のイメージつくってmount -o loopしようとしたら、MTDじゃなきゃ普通にダメーって言われてがっかりした(笑)
まぁそりゃそうか。
でもちょっと欲しいよねー汎用的な圧縮FSというか圧縮ファイルをloopできる仕組みみたいなもの。

Ninaの実家ってロシアの内務省に勤めてる家系だよね。
子どもがすでにロシアの市民権を取ってるのもなぁ。

>>12
ZLIBC

サスペンスなスレになったな

前々スレ、前スレにつづいて、だれか映画 Reiser Code のコピーつくってよ。
なんなら、映画用のストーリーもつくってくれるといいかも。
って、何のスレだ、ここ(w

- Reiser Code -
忽然と姿を消した妻、疑惑の目を向けられる夫
混沌とした人間関係が巻き起こす、驚愕のミステリー
秘密はReiser4のソースコードの中に隠されているのか・・・
ライザーコード 近日公開
(前々スレ_474)
////
ある日突然，姿を消したHansの妻．
殺人容疑をかけられるHans．果たして，Hansは妻を殺したのか??
見つからない妻の死体． 果たして妻の行方は??
Hansの開発したFS　[Reiser4]のソースコードの中には，何が隠されているのか．
Hansを追う警察，秘密を探る怪しい男の影，混沌とした人間関係の中で起こったミステリー．

Reiser Code

おすぎです

平凡な夫婦に
突然降りかかる不可解な事件

妻の失踪

死体の無い殺人事件

某国の陰謀か？

カーネルにマージされない本当の理由とは？

ソースコードに隠された秘密が解き明かされるとき
その真実が証される

全米を震撼させた実在の殺人事件が
ついに映画化！

『REISER』〜血塗られたソースコード〜

高度情報化社会が生んだ悲劇を
その目で確かめください！！

面白いと思ってんのか?

まぁこのスレのレベルではこんなもんだろう。

Reiserfsみたいなのがフリーで普及してしまうと、それで飯くってる人がお手上げだもんな

>>2
追加。

ntfs-3g
http://www.ntfs-3g.org/

糞ファイルシステムを持ち上げようとする秘密結社を潰そうとした某国政府の陰謀だな。確実。

今、ファイルシステムで一番アツい話題がこの事件なんだよな

Reiserfsは基本構造にB+treeを使っているのかと思っていたのだが、
ドキュメントをみるとハッシュ空間がファイル数上限を規定していると書かれてるんだが
これってどういうことなんだろう？
でファイル数上限はディレクトリあたりなのかファイルシステムあたりなのかよくわからないのだが、一千万程度だった。
ディレクトリあたりなら十分だがファイルシステムあたりなら微妙。
容量はEiバイトのオーダーだったから当面無問題なのだが。
詳しい人解説お願いします。

このスレに詳しい人はいないとみた

>>26は時間とか平日とか関係の無い職業・・・自宅警備員とみた！

このスレに詳しい人はいないに一票

>>25
どこのドキュメントのことを言ってるのかわかんないけど、
ハッシュいうたら、コリジョンをおこさない間はうまく
動くけど、数が増えてきたらそらあかんわ。

ファイルシステムはまるで詳しくなく興味もないのだけど、
B木を使っていてinode相当のものを固定サイズで管理しないなら、
ファイル/ディレクトリ数上限は使い方次第なのでは？

どう使ってもこれ以上は入らないという上限はありそうだけど
多分実用上ははるかに低い値になる気がする。

以下ちらっと見たページ(よく理解できてません)
ttp://www.atmarkit.co.jp/flinux/rensai/fs02/fs02c.html
ttp://www.namesys.com/X0reiserfs.html

>>29-30
>25の発言以上の内容がない件について

きっと見当違いな回答だったんだと思います。
↓で詳しい人が解説してくれるに違いない。

>>31
理解できないなら黙ってたら?

>>33
>29は全然回答になってないんだが．．．

>これってどういうことなんだろう？
ファイル名のハッシュ使っているr5は、実質1000万ほどで
コリジョンが発生するので、これ以上はファイルは作れないということ。

>ファイル名のハッシュ使っているr5
ファイル名のハッシュで使っているr5

>>35
>　ファイル名のハッシュ使っているr5は、実質1000万ほどで
>　コリジョンが発生するので、これ以上はファイルは作れないということ。

当然確認とってるんだよな？

コリジョン発生はハッシュの実装に依存するはずだが、
ReiserFSで約1000万で発生するんだな？

ReiserFSのハッシュ実装はr5、rupasov、teaの３つあるがrupasov、teaの場合は？

>>25です
詳しい人ありがとう。
つまり、データ構造にはB+Treeを使っているけれど、
ファイル名管理にはハッシュを使っているということでいいですか？
なんか、腑に落ちないけど、そういうもんだといわれるなら、引き下がります。

1000万、マジにとらないように。
公式ページにちゃんと書いてあるから。

35 名前：login:Penguin[sage] 投稿日：2007/03/12(月) 21:54:28 ID:Y3icS7v7
>これってどういうことなんだろう？
ファイル名のハッシュ使っているr5は、実質1000万ほどで
コリジョンが発生するので、これ以上はファイルは作れないということ。

41 名前：login:Penguin[sage] 投稿日：2007/03/12(月) 23:16:49 ID:Y3icS7v7
1000万、マジにとらないように。
公式ページにちゃんと書いてあるから。

調べた後で意見変わるのカコワルイ

素で間違えたから、わざわざ同じIDで書いたのに...

普段はいろんなID使ってる方ですか？

ちゃかさんでも...それより間違いというなら
どこが間違いだったのか教えて。
1. ファイル名のハッシュ使っているr5は、実質1000万ほど
2. コリジョンが発生するので、これ以上はファイルは作れない

>>45
ID:Y3icS7v7が
>　1000万、マジにとらないように。
>　公式ページにちゃんと書いてあるから。

と自分でカキコしてるから1.なんだろ

そもそも、アルゴリズムにおけるハッシュ法がどういうものか調べた方がいい。
MD5で出てくるだけのものとはちょっと違うぞ。

ハッシュ関数
http://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5

wikiでも読んでろよ。
スレ違い。

あいたた。そこまで叩かんでも。
コリジョンがあったら元のキーで照合すればいいのではないかと思っただけ。
十分一意で現実的にそうする必要がないということならそう言ってくれれば
いいのに...って力不足でごめんね。

>>48
http://ja.wikipedia.org/wiki/Wiki

wikipediaをwikiと呼ぶヴぉけ

>>51
日本語でOK

Don't call wiki wikipedia (の日本語訳)

>>53
おまえ・・・。

>>53
そりゃまwikiのことをwikipediaと呼ぶ人はほとんどいないだろ。

>>55
おまえは世間を甘く見すぎている。いつか手痛いしっぺ返しを食らうだろう。

>>45 自己レスです。
ttp://homes.cerias.purdue.edu/~florian/reiser/reiserfs.php
を見たところ、確かにファイル名のハッシュ値を使っているようですが
2.6.20.2のfs/reiserfs/namei.c:1575
を見るに少なくとも指定ディレクトリ(エントリ)の指定ファイル名の
ファイルを探すときはこの値を探索した後線形探索するように
読めました(無論細部は追ってないし動かしてもいない)。

で、コリジョン＝エラーではないと思う。それだけ。

ごめん1575行じゃなくて311行だった。

新ネタ投下
http://journal.mycom.co.jp/articles/2007/03/13/puffs/
http://journal.mycom.co.jp/articles/2007/03/13/bluffs/

LinuxというよりBSD筋になるのかな？どうだろう？

>>57
コリジョンが起こったファイル名で書き込みに行った場合、
衝突されたファイルを上書きしてしまうと思うが？
これを避けようとすると、毎回コリジョンの有無を調べなければならず、
ハッシュの優位性はなくなってしまわないか？

>>57
レスがかみ合ってなくてスマソ。
ハッシュで探索後に、線形探索。
これではハッシュの意味が無い上にもの凄く遅くない？

>>57
連投スマソ。
これは俺の無知だね．．．
>57はコリジョンが起こった際の処理方法についてカキコしてたわけだ。
申し訳ない。

だとすると>35の意見は果たしてどうなんだろうか？

ハッシュを使っているのは文字列の代わりに固定サイズの短い数字を使った方が
B木のキー(の一部)として優秀なだけだと思います。ただハッシュなので、B木を
降りていった後にハッシュの元の文字列かどうかは確認する必要があり、B木の
キーで同じ値になっている部分を走査したり探索したりする必要があるのかなぁ
と思いました。

元の文字列に対してハッシュ値が現実的に十分1:1になっている(一意になって
いる)なら最後に走査したり探索したりする必要はないんだけど、B木まで使う
(レコード数が大きいことを想定している)ファイルシステム(手堅い印象)で
ハッシュが重ならないことを前提にしたりするの？と疑問が残ったので、資料と
ソースを探してみました。で、>>57 というわけ。

でも、仮に調べたことが想定通りだったとしても、取得側のロジックで単に同一
ハッシュを線形探索しているということまでしか突き止めていないので、挿入側
のロジックでエラーとしていないかどうかまでは確認できていません。ただ、
取得時に線形探索までしておいて、挿入時に同一ハッシュをエラーにするのも
あれだし、ハッシュも絶対一意とするには短いような気がしたので載せちゃい
ました。

最後に、、こう思うという意見を言っただけで>>35 に回答を求めているわけ
ではないので、間違い指摘は歓迎ですが、煽ったりしないでね。適当に流して
くれて構いません。(長くてゴメン)

>>63
俺は>60のレスの後調べてみてわかったんだが、
>　取得側のロジックで単に同一ハッシュを線形探索している
これってコリジョンが発生した場合の対応法だよ。

検索アルゴリズム
http://www2.starcat.ne.jp/~fussy/algo/algo7-1.htm
さて、ハッシュ表が衝突した場合の処理方法ですが、大きく分けて2種類存在します。
．．．
もうひとつの方法は、同一のハッシュ値をとるデータを線形リストの形で保持し、

あくまで個人的な意見だけれども、>25の
>　ドキュメントをみるとハッシュ空間がファイル数上限を規定していると書かれてるんだが
>　これってどういうことなんだろう？

これは、ハッシュテーブルの大きさに制限される、という意味じゃないかな？

いやそうなんだけど、挿入時に何かの理由でエラーとしても、
線形探索がない場合と同様に動くでしょ？(もう寝ます)

あ、>>66 は >>64 へのレスです。

>>66
その通りなんだけど、
取得時に線形探索をしていて、挿入時に線形リストを作っていない
これは考えにくいよね。

俺も寝ます．．．

いろいろ調べていただきありがとう。
結局、最初の疑問にもどるのだけど、コリジョン処理をきちんとしているなら
効率的なファイル管理のできる上限は限られるものの、ファイル数は制限されないよね？
とすると…と思っているうちに動作の説明図を思い出した。
バージョン3では3段、バージョン4では4段のハッシュを作ってるということのような気がする（数値はうろ覚えなので4と5だったかも）。
B+（B*かも）Treeのはずなのに子ノードがたくさんあるような図だったので
なんでだろうなと不思議に思っていたけどやっとつながった感じです。
ありがとう。

>>69
>　バージョン3では3段、バージョン4では4段のハッシュを作ってるということのような気がする

それは違うと思うよ。
>63の意見が正しいと思う。

>>69
今更悪いけど、
ハッシュ値のBTreeを３−４段作っているという意味なら、
それは正しいかも。

ディレクトリってどういう仕組みでできてるんですか？
ディレクトリマークのついたファイルに
ファイル名と対応するinodeが羅列してあるとかですか？

大昔のSysVはそうだったな

linuxはext4がデフォになったんだって？（ｗｋｔｋ

わくつき？わかたけ？なに？

わくてか

>>75
若貴(わかたか)。
昔一世を風靡した兄弟横綱だよ。

とかち・・・つくちて・・・

Reiserfs以外盛り上がらないスレだね

Linux板だしね

普段、/ をroでマウントしており、特定の変更をするときにスクリプト内で
# mount -o remount,rw /
# <何か変更をする>
# mount -o remount, ro /

しかし時々気がつくと/がrwのままになっており,　roにしようとすると
mount: / is busy
と帰ってきます。

しかし
# lsof +D / | grep [0-9][ru]
としても何も出力されないので/ファイルシステム上で書き込み、更新のためにオープンされているファイルが
あるようには見えません。他にbusyになる条件というのはなにがあるのでしょうか？

>>81
実行している

じっこうしている
ジッコウシテイル

>>82
具体的に「実行」とはどういう状態を言うのでしょうか？　実際に/から実行されているプログラムは常に多数あるのですが、
普段の状態でしたらremount,roは問題なく出来てます。　

>>83
cd しているプロセスがある

>>84
82さんの回答と同様、それは恐らく"umount"すると時にひっかかる条件だと思います。　
「正常に」機能している時には以下のようなことしても無問題です。

# mount -o remount,rw /
# cd /
# pwd
/
# mount -o remount,ro /
# echo $?
0

>>78
tkttktt?

>>85
cdのあとtouch .1 しても？

find / -exec fuser {} ';'も調べたい

rwでremountしてからroでremountするまでの間に、何かのプログラムが実行されたんじゃね？

スクリプト内でremountに失敗
↓
mountコマンドがデバイスをつかんだまま
↓
remountに再び失敗

違うかな？

>>87
無問題です。以下のようにしてあからさまにwriteでファイルを開かないと"busy"とはなりません。

# mount -o remount,rw /
# cd /
# cat > hoge
^Z
[1]+ Stopped cat >hoge
# mount -o remount,ro /
mount; / is busy
# kill %1
# mount -o remount,ro /
[1]+ Terminated cat >hoge
# echo $?
0

てす

てす

>>88
シリアルコンソールごしにネットワーク、全てのサービスを停止。40弱しかプロセスが走ってない状態
（けどremount,roはやっぱりbusy)でやってみました。
/dev, /procと他パーティションの/var以下を除いた結果が以下です。

/: 1r 1c 2r 2c 3r 3c 4r 4c 5r 5c c
/bin/bash: 5924e 6938e
/bin/sh: 5924e 6938e
/bin/login: 26670e
/bin/su: 6937e
/lib/ld-linux.so.2: 1m 2739m 4649m 5924m 6937m 6938m 26670m
/lib/libaudit.so.0: 6937m 26670m
/lib/libpam.so.0: 6937m 26670m
/lib/libpam.so.0.77: 6937m 26670m
/lib/libtermcap.so.2.0.8: 5924m 6938m
/lib/libnss_files-2.3.4.so: 2389m 2476m 5924m 6937m 6938m 26670m
/lib/libnsl-2.3.4.so: 6937m 26670m
/lib/libcrypt-2.3.4.so: 6937m 26670m
/lib/tls/libc.so.6: 1m 2739m 5924m 6840m 6937m 6938m 26670m
/lib/tls/libc-2.3.4.so: 1m 2739m 5924m 6847m 6937m 6938m 26670m
/lib/libsepol.so.1: 1m
/lib/libcrypt.so.1: 6937m 26670m

続き

/lib/security/pam_rootok.so: 6937m
/lib/security/pam_unix.so: 6937m 26670m
/lib/security/pam_limits.so: 6937m 26670m
/lib/security/pam_deny.so: 6937m 26670m
/lib/security/pam_unix_auth.so: 6937m 26670m
/lib/security/pam_unix_passwd.so: 6937m 26670m
/lib/security/pam_unix_acct.so: 6937m 26670m
/lib/security/pam_env.so: 6937m 26670m
/lib/security/pam_unix_session.so: 6937m 26670m
/lib/security/pam_cracklib.so: 6937m 26670m
/lib/security/pam_xauth.so: 6937m
/lib/security/pam_loginuid.so: 26670m
/lib/security/pam_securetty.so: 26670m
/lib/security/pam_console.so: 26670m
/lib/security/pam_stack.so: 6937m 26670m
/lib/security/pam_nologin.so: 26670m
/lib/security/pam_selinux.so: 6937m 26670m
/lib/libdl.so.2: 5924m 6937m 6938m 26670m
/lib/ld-2.3.4.so: 1m 2739m 5924m 6906m 6937m 6938m 26670m
/lib/libpam_misc.so.0: 6937m 26670m
/lib/libpam_misc.so.0.77: 6937m 26670m
/lib/libdl-2.3.4.so: 5924m 6937m 6938m 26670m
/lib/libtermcap.so.2: 5924m 6938m
/lib/libnsl.so.1: 6937m 26670m
/lib/libselinux.so.1: 1m 2739m 6937m 7003m 26670m
/lib/libaudit.so.0.0.0: 6937m 26670m
/lib/libnss_files.so.2: 2389m 2476m 5924m 6937m 6938m 26670m

最後
/sbin/init: 1e
/sbin/klogd: 2393e
/sbin/syslogd: 2389e
/sbin/fuser: 7154e
/sbin/telinit: 1e
/usr/bin/find: 2739e
/usr/lib/libcrack.so.2: 6937m 26670m
/usr/lib/libglib-2.0.so.0: 26670m
/usr/lib/locale/locale-archive: 2476m 2739m 5924m 6938m 17391m
/usr/lib/libglib-2.0.so.0.400.7: 26670m
/usr/lib/gconv/gconv-modules.cache: 5924m 6938m
/usr/lib/libcrack.so.2.7: 6937m 26670m
/usr/lib/libcrack.so: 6937m 26670m
/usr/sbin/crond: 2476e

全然あやしそうなのを見かけません。

>>94
あれ、/:の出力が切れてますね。如何が全てです。

/: 1r 1c 2r 2c 3r 3c 4r 4c
5r 5c 6r 6c 44r 44c 47r 47c 48r 48c 49r
49c 50r 50c 196r 196c 292r 292c 294r 294c 295r 295c
312r 312c 1341r 1341c 1757r 1757c 1902r 1902c 1903r 1903c 1905r
1905c 2389r 2389c 2393r 2393c 2476r 2567r 2567c 2568r 2568c 2569r
2569c 2570r 2570c 2571r 2571c 2572r 2572c 2739r 2739c 2740r 5924r
6937r 6938r 26670r 27648r 27648c

>>89 可能性としてはありそうです。しかしその結果、なぜ今の状態になってしまったのかが謎です。
>>90どう見てもmountコマンド自体は終了してますが、カーネル内部的に「つかんだ」ままになっている
のでしょうか？

さて、そろそろソースを読まねばという感じです。ちなみにCentOS4.4の2.6.9カーネルです。

>>97
> 無問題です。以下のようにしてあからさまにwriteでファイルを開かないと"busy"とはなりません。

あー、それならwriteで書き込まれたデータがまだディスクに書かれてない状態ですな。
まずはremount前にsyncを実行しましょう。
それでもダメな場合は、数秒待ってから再度sync->remountしてみてください。

私のところはFreeBSDだけど、shellスクリプト内でumountする時に以下のようにしています。

echo " unmount"
/bin/sync

/bin/sleep 60
/sbin/umount ${MNT}
for n in 0 1 2 3 4 5 6 7 8 9; do
　if /sbin/mount | /usr/bin/grep /dev/ad0s1e > /dev/null; then
　　/bin/sleep 60; /sbin/umount /mnt
　else
　　break
　fi
done

http://linuxfs.pbwiki.com/LSF07-Workshop-Notes

>>99
これだけ長時間バッファがフラッシュされないなんてありかな？

>>99
syncもだめでした。それにしてもこの状態(busy)で安定したまま一日以上過ぎてますので。

ちょっとコードを読んで見ました。mountコールのエラーパスはこうなるようです。

|sys_mount (fs/namespace.c)
|-do_mount
|--path_lookup(fs/namei.c)
|---link_path_walk
|----__link_path_walk
| ごちょごちょして良く分からんがたぶんEBUSYは返さない？
|--security_sb_mount(include/linux/security.h)
|---security_ops->sb_mount
| 良く分からないけどSELinuxはdisableしてるから恐らく
| dummy.cのdummy_sb_mountでreturn 0
|--do_remount_sb
|
| if ((flags & MS_RDONLY) && !(sb->s_flags & MS_RDONLY)) {
| if (force)
| mark_files_ro(sb);
| else if (!fs_may_remount_ro(sb)) (fs/file_table.c)
| return -EBUSY;
| }
続く

続き。ここで跳ねられてる？　"pending delete"のファイルってlsofとかでも見れませんでしたっけ？

|----fs_may_remount_ro(struct super_block *sb) (fs/file_table.c)
|{
| struct list_head *p;
|
| /* Check that no files are currently opened for writing. */
| file_list_lock();
| list_for_each(p, &sb->s_files) {
| struct file *file = list_entry(p, struct file, f_list);
| struct inode *inode = file->f_dentry->d_inode;
|
| /* File with pending delete? */
| if (inode->i_nlink == 0)
| goto too_bad;
|
| /* Writeable file? */
| if (S_ISREG(inode->i_mode) && (file->f_mode & FMODE_WRITE))
| goto too_bad;
| }
| file_list_unlock();
| return 1; /* Tis' cool bro. */
|too_bad:
| file_list_unlock();
| return 0;
|}

>>98
別に根拠は無いです。
ファイルはつかまれてなさそうなので、デバイスをつかまれてないかなと思った。

rwでremountしてもやはりbusyになるんだろうか？

dmesgの結果や/var/log/messagesの内容も知りたい。

>>105
いえ、それはOKです。けどrwをrwにremountしてもスルーされてるだけかもしれませんね。
>>106
mountコマンドを入力したときにはとくにどちらにも新たな出力は見られません。先ほど見た
エラーパスにも特にその周辺で何かを吐き出すコードは見られませんでした。また両方とも
デバイス名sdaでgrepして見ましたが、起動時の普通のメッセージ以外に特に最近異常を示す
メッセージは見受けられません。他に何か探すべきものがありましたらご指摘キボンヌ。

そろそろ上に挙げたコードにデバッグコードを埋め込んでカーネル再構築を試みます。

>>103
> "pending delete"のファイルってlsofとかでも見れませんでしたっけ？

自己レス。普通は見えますね。
# mount -o remount,rw /
# cat > hogehoge
^Z
[1]+ Stopped cat >hogehoge
# rm -f hogehoge
# lsof | grep hogehoge
cat 9979 root 1w REG 3,8 0 983060 /hogehoge (deleted)
#

inodeの中身をダンプするデバッグ用のルーチンなんかありませんかね？
出来るだけ情報を書き出したいけど、中身が全然分かってないから下手したら
そこでクラッシュしそう。

>>107
>　そろそろ上に挙げたコードにデバッグコードを埋め込んでカーネル再構築を試みます。

障害の発生を再現するのは手間だから待った方がいいと思う。

試して欲しいのは、
mount -v -o remount, ro /
で詳細情報を表示させてみることと、
mount -f -o remount, ro /
で強制した場合にremountできるかということです。

mount -f -o remount, ro /
これをやってもらいたいのは、
>103の
fs_may_remount_ro(struct super_block *sb)
を通らず、
mark_files_ro(struct super_block *sb)
(fs/super.c 567)
に分岐すると思うからです。

mount -f -o remount, ro /
は
mount -v -f -o remount, ro /
の方が情報が得られてよいかも。

いくつか気になった。
・80と書いている人は81?
・うちのdebian(sarge)だと-vつけてもなんか変わらない
・ファイルシステムの種類は関係ない話なの？
何の役にも立たんと思うが。

うえの方でfind ... fuserしてほしいと書いた者だが、PID並べられてもしょうがないんだよね。
psで対応するコマンド調べてくらはい。
そのくらいはできる人と思ってたんだが、もしやド素人じゃないよね？
もしド素人なら、これでうまくいっても他で障害がでるだろうから、あまりごちゃごちゃやらんほうがいいと思うよ。
ド素人でないなら、、、もうちょっと独力でも頑張ってほしかった。
いずれにせよ、結果まってるよ〜。

>>86
tkt tktt

げげ、誰かリブートしやがったorz　すみません。また障害発生を待たないと...

>>113
間違えてました　orz
ちなみにext3です。

>>111
-fは(fake)であって-forceではありません。103の"force"は内部のemergency_remount()から呼ばれたときに
だけ立てられるフラグでこれは探したところdriver/char/sysrq.cのsysrq_handle_mountroからしか
呼ばれないので普通に使うものではないようです。

>>114
意図を汲まずに申し訳ございませんでしたが、何を探しているのかが良く分かってませんでした。
しかしあの出力で出てきたファイルのリストはlsofで出てきたものと同じようなものと見受けられましたし、
書き込み状態にあるpidも１つもありませんでしたのでどのpidに注目すればいいのかが分かりませんでした。
全部を列挙するのは長すぎると思いましたし。

fsは全くド素人でSMARTを見て、あ、ディスク壊れてるっていて交換したこと以上のことを
考えたことはありませんのでファイル周りの検証のテクニックはlsofぐらいしか知りませんでした。
fuserは初耳でしたので勉強になりました。カーネルの中をまじめに問題解決のために読み始めたのも
ここ１ヶ月ほどの事ですので。

さて、それではカーネル仕掛けてまた再現するのを待って報告させて頂きます。

>>116
lsofで結果見てたんだね。失礼。
閉じられているはずのファイルがなぜか開きっぱなしの問題はよくあることです。
解決方法がなかなか見つからないので、ぜひがんばってください。
報告待ってます。

閉じられてるファイルが〜なぜか開いているのな〜ら〜
sync！sync！sync！

って歌があったね

だめよだめだめデッドローックー

ext4はｻｲｽﾞ変更に対応してる？対応してればLVMと組み合わせて使い易いのだけど。
性能的にはどうなんだろう？

そういやオンラインデフラグの件はどうなったんだ？

Reiserはその後どうなってんの？

WInの焼きミスはほんとひどいよなw
焼いてるときは、他の作業しないほうがいい

>>123
お前はバブルの崩壊直後の時代の人か？

>>123
スレ違いだ。帰れ。

>>124
またキミか

3 名前：login:Penguin ：2007/03/24(土) 22:37:58 ID:1ZNqfG35
うざいなぁ・・・・

913 ：login:Penguin：2007/03/24(土) 22:34:12 ID:1ZNqfG35
>>911
＞Windowsじゃあるまいし、ブートローダごときで再インストールする必要はない。

fixmbrもしらんWindows道程であることが判明しましたｗ

前スレで言われてたけど、nautilus+xfsでファイルのコピー等がすごく遅くなるってあったでしょ？
俺もあれで悩まされてたんだけど、LVM使ったらあのバグ発生しないんだね。
なんとなくLVM+xfsで新たにシステム構築し直したらnautilusでも速度が落ちなくなった。

LVMは便利なのだが、コマンドいっぱいでめんどいよね

>>128
というか報告せいや
xfsなのかnautilusなのか知らんが

nautilus＝糞
昔からの定説だろ。いまさら報告する必要もなし。

だったら、使うなw

>>131
またキミか。

ﾗｲｻﾞｰと供に寂れてしまった

とりあえずXFSとext4のどっちが残るかだな。
ext4かな。

ext3はext4にコンバートできるんですか

ext3をext4としてマウントできる。そのまま書き込めばext4になる。

すげぇ
＆
トンクス

>>137
いやextent使うまではext3のまんまだろ。

extentとはなんですか？

xfsはトラブった時に全然レスキューできなかったからトラウマ
チキンな俺はext4

>>140
The answer is in your ID.

r+t? 2J ggl .. ggl! ｸﾞｸﾞﾚ！？

ｱﾘﾏｼﾀ
ttp://www.sophia-it.com/content/extent

でも意味がわかりません。

>>144
http://www.google.co.jp/search?hl=en&q=ext4+extent

�d
つまりﾌｧｲﾙが断片化しないよう、余分に場所を確保しとくっていうﾗｲｻﾞｰ4の真似をした仕組みだね。

ところで将来のﾌｧｲﾙｻｲｽﾞなんて予測できないと思うのだけど、
ｴｸｽﾃﾝﾄの大きさはどうやって決めるのだろう？
むかしｸﾗｽﾀと呼んでいたものとは違うの？

エクステントって昔からエクステントと呼んでいたような。
VxFS とか。

>>147
XFSのオンラインデフラグがext4についてくれれば、とりあえず最強なんだがな。
年に数回はデフラグしたい。

MSDOSは複数のセクターをまとめた｢クラスタ｣という連続領域単位でファイルを管理してた。
インデックスを少なく押さえることと、断片化を少なくするのが目的。
低速媒体のフロッピーが主体だったため、断片化を避けるのは非常に重要だったせいもあるが
当時の大型機からの借用だったと理解してる。
エクステントの説明をみると同じものにみえるのだけど、何かちがうのだろうか？

>>149
クラスタサイズが可変なんじゃね？

それをどうやって決めてるかが肝

エクステントサイズが固定の方が断片化は起こり肉印とちゃう？

>>149
ブロック管理だと
ファイルが巨大になると
インデックスを引くのに時間がかかるようになるが
エクステント管理だとうまく連続ブロックに配置できれば時間が節約できる。

インデックスってエクステント単位で振られるんじゃないの？

ブロック＝IO最小単位
エクステント＝領域割当最小単位
っていう理解で基本的にはいいんだよね？

違う。

エクステントってのは連続したブロックのこと。

あるファイルが1〜10、15〜20のブロックからなっている時、ブロックベースの
ファイルシステムでは (1 2 3 4 5 6 7 8 9 10 15 16 17 18 19 20) という
インデックスで表現するのに対し、エクステントベースのファイルシステムでは
((1 10) (15 5)) のように表現する。

>>155
inodeが圧縮できる？よくわかってませんが。

で、最初の疑問ですが、
断片化が起こるのは、ファイル更新時のサイズ変化が要因だとすれば、
あらかじめ変化量を予測してエクステントを確保する必要があるわけだけど
どうやるのですか？

extentの仕組みについて人に聞く前にまずググってみました。

ズバリというページがありません！

http://www.spa.is.uec.ac.jp/~kinuko/survey/body/extent-like-fs.html
http://www.kyoto-sr.co.jp/products/fugue/techinfo/fs-gc.html
http://www.atmarkit.co.jp/flinux/rensai/oracle04/oracle04.html
http://www.simosimo.info/know/oracle/extent.htm

いったいエクステントについてよく理解するためにはどうしたらいいのか！
参考書とか専門書とか買わないとわからんかな。

>>158
くっつく？ひっつけばチャクラエクステントが発動します。

>>157
ジャーナルから commit するまで割り当てを遅延する
ディスクの空き容量が少なくなるまでファイルを密に配置しない
その他色々

ありがとうございます！
しかしジャーナルに書き込むのは更新時が主ですよね？
とすれば、新規作成時に将来サイズの予測ができることがエクステントの考え方としては最重要という気がします。
ファイルを密に配置しないという方針は有効ですが、エクステントとは別の考え方ではないでしょうか？

自己レスです。
エクステントの大きさは使用者が決めるようです。
しかも初期と伸張分をべつの大きさにする方法もあるようです。
したがって、設計段階でのサイズ予測はいらないということのようです。

XSFフォーマットのディスクに入れたファイルとかを
NTFSフォーマットのWINDOWSへコピーした場合普通に開けるのですか？

>>163
なぜ、自分で試さない？

パソコンすら持ってないんです
うぅ・・

そんな人が聞いてどうすんだろ。

流行りのエアギターならぬエアLinuxってやつだな。

俺の若い頃は藁半紙に書いたキーボードとライオン本でカーネルハックの練習をしたもんだよ

エアオナニー

牛乳石鹸をマウスに見立てて、X Windowへの思いをはせたもんだ

mount -o mount,ro / がbusy で帰ってきて困ってた81(80と間違えてた)です。

２週間ほどたってやっと再現されました。　しかもラッキーに2台。追加したprintk
から以下のような出力。　

fs_may_remount_ro found pending delete: 0xe6feac80
do_remount_sb: failed fs_may_remount_ro: -138124224
do_mount: failed do_remount: -16

大切なのは最初の１行で以下のprintkから出力されました。

　fs/file_table.c:
　int fs_may_remount_ro(struct super_block *sb)
　{
　 struct list_head *p;
　...
　
　 /* File with pending delete? */
　 if (inode->i_nlink == 0) {
　 printk(KERN_NOTICE "fs_may_remount_ro found pending delete: 0x%x¥n",
　 (unsigned long)file);
　 goto too_bad;
　 }

続く

さて、まずどのファイルか？　gdbを/proc/kcoreに繋いで除きました。

(gdb) p ((struct file*)0xe6feac80)->f_dentry->d_iname
$12 = "libz.so.1.2.1.2", '¥0' <repeats 20 times>
gdb) p ((struct file*)0xe6feac80)->f_dentry->d_parent->d_iname
$14 = "lib¥000t", '¥0' <repeats 30 times>
(gdb) p ((struct file*)0xe6feac80)->f_dentry->d_parent->d_parent->d_iname
$16 = "usr¥000]", '¥0' <repeats 30 times>
(gdb) p ((struct file*)0xe6feac80)->f_dentry->d_parent->d_parent->d_parent->d_iname
$18 = "/¥000dline", '¥0' <repeats 28 times>

というわけで問題のファイルは"/usr/lib/libz.so.1.2.1.2"

もうここで　は〜〜〜あ〜〜〜〜？？？？？？？　です。なんでライブラリー
ファイルがpending delete なの？？？？

もうちょっと掘り下げる。

(gdb) p ((struct file*)0xe6feac80)->f_dentry->d_inode.i_ino
$24 = 230991

iノード番号は230991。

# ls -li /usr/lib/libz.so.1.2.1.2
231021 -rwxr-xr-x 1 root root 63624 Jul 21 2005 /usr/lib/libz.so.1.2.1.2

？？？　食い違うぞ ？？？

誰がこのファイルを開いてる？

# lsof | grep libz.so.1.2.1.2　　# ちょっと冗長な行は省いてます
postmaste 5377 initrfx mem REG 3,3 63624 231021 /usr/lib/libz.so.1.2.1.2
snmpd 5580 root mem REG 3,3 63624 231021 /usr/lib/libz.so.1.2.1.2
ntpd 21393 ntp mem REG 3,3 　　230991 /usr/lib/libz.so.1.2.1.2 (path inode=231021)
sshd 26062 root mem REG 3,3 63624 231021 /usr/lib/libz.so.1.2.1.2
sshd 26066 admin mem REG 3,3 63624 231021 /usr/lib/libz.so.1.2.1.2
sshd 26135 root mem REG 3,3 63624 231021 /usr/lib/libz.so.1.2.1.2
sshd 26153 support mem REG 3,3 63624 231021 /usr/lib/libz.so.1.2.1.2

ここでntpdに注目、他のプロセスは正しいinodeで開いているのにntpdだけがこの問題の
230991番のinodeを通して開いてます。

それでもってntpがどういうファイルを開いているか見ると、なんか怪しげな状態。

# lsof | grep ntp
ntpd 21393 ntp cwd DIR 3,3 4096 2 /
ntpd 21393 ntp rtd DIR 3,3 4096 2 /
ntpd 21393 ntp txt REG 3,3 431016 227728 /usr/sbin/ntpd
ntpd 21393 ntp mem REG 3,3 230494 /usr/lib/libkrb5.so.3.2 (path inode=231028)
ntpd 21393 ntp mem REG 3,3 194104 /lib/libdl-2.3.4.so (path inode=195480)
ntpd 21393 ntp mem REG 3,3 47468 194100 /lib/libnss_files-2.3.4.so
ntpd 21393 ntp mem REG 3,3 210587 /lib/tls/libc-2.3.4.so (path inode=210651)
ntpd 21393 ntp mem REG 3,3 194115 /lib/libcom_err.so.2.1 (path inode=195486)
ntpd 21393 ntp mem REG 3,3 195438 /lib/libcap.so.1.10 (path inode=194186)
ntpd 21393 ntp mem REG 3,3 230991 /usr/lib/libz.so.1.2.1.2 (path inode=231021)
ntpd 21393 ntp mem REG 3,3 194184 /lib/libresolv-2.3.4.so (path inode=195487)
ntpd 21393 ntp DEL REG 3,3 230821 /usr/lib/libgssapi_krb5.so.2.2.#prelink#.k1YsQi
ntpd 21393 ntp mem REG 3,3 195446 /lib/ld-2.3.4.so (path inode=195478)
ntpd 21393 ntp mem REG 3,3 230734 /usr/lib/libk5crypto.so.3.0 (path inode=230968)
ntpd 21393 ntp mem REG 3,3 210597 /lib/tls/libm-2.3.4.so (path inode=210654)
ntpd 21393 ntp DEL REG 3,3 195456 /lib/libcrypto.so.0.9.7a.#prelink#.7KiFJi
以下略。

続く

ちなみに正常（？）な状態のntpはこんな感じ。

proto5# lsof | grep ntp
ntpd 2101 ntp cwd DIR 3,2 4096 2 /
ntpd 2101 ntp rtd DIR 3,2 4096 2 /
ntpd 2101 ntp txt REG 3,2 431016 241991 /usr/sbin/ntpd
ntpd 2101 ntp mem REG 3,2 941024 260982 /lib/libcrypto.so.0.9.7a
ntpd 2101 ntp mem REG 3,2 11776 260970 /lib/libcap.so.1.10
ntpd 2101 ntp mem REG 3,2 1525004 177572 /lib/tls/libc-2.3.4.so
ntpd 2101 ntp mem REG 3,2 16800 294968 /lib/libdl-2.3.4.so
ntpd 2101 ntp mem REG 3,2 415188 247066 /usr/lib/libkrb5.so.3.2
ntpd 2101 ntp mem REG 3,2 47468 258705 /lib/libnss_files-2.3.4.so
ntpd 2101 ntp mem REG 3,2 112236 294966 /lib/ld-2.3.4.so
ntpd 2101 ntp mem REG 3,2 63624 247059 /usr/lib/libz.so.1.2.1.2
ntpd 2101 ntp mem REG 3,2 213992 260979 /lib/tls/libm-2.3.4.so
ntpd 2101 ntp mem REG 3,2 136016 242425 /usr/lib/libk5crypto.so.3.0
ntpd 2101 ntp mem REG 3,2 81184 260981 /lib/libresolv-2.3.4.so
ntpd 2101 ntp mem REG 3,2 7004 260980 /lib/libcom_err.so.2.1
ntpd 2101 ntp mem REG 3,2 82944 247067 /usr/lib/libgssapi_krb5.so.2.2
以下略。

ちなみにこの症状は問題のおこった２つのシステムでまったく同じ。　
おなじlibz.soでひっかかり、やはりntpが同じような状態になってます。

さて、この"path inode"というのがキモのようですが、なんの事か
全然分からないからどこかで調べてきます。　

ここまでの情報で何か助言があればよろしくおねがいします。　

なお、問題のあるシステムでは問題のあるのはntpだけでありません。

# lsof | grep "path inode" | cut -d" " -f1 | sort | uniq
agetty
crond
ifplugd
klogd
mingetty
ntpd
portmap
syslogd
udevd
xinetd

問題のないシステムではこの"path inode"は全く見受けられません。　それから
これらのシステムではライブラリーのアップデートは全く行われてません。

prelinkによってロード中の共有ライブラリが置き換えられているのかな？

prelinkを止めてみるとか。

>>178
そっ、それだ〜〜〜〜〜〜〜〜〜〜〜〜。

こんなもの見つけました。

/etc/cron.daily/prelink

一発で再現出来ました。

正常状態：

# touch /hoge
touch: cannot touch `/hoge': Read-only file system
# lsof | grep "path inode" | wc -l
0

再現：
# mount -o remount,rw /
# /etc/cron.daily/prelink
# mount -o remount,ro /
mount: / is busy
# lsof | grep "path inode" | wc -l
337

よーするにこれが滅多に起きなかったのは、普段はr/oなのでprelinkは水面下でエラーを起こして
たのでしょうが、たまにr/wに変わる短い時間がcron.dailyとぶつかることがあるのでしょう。
その時に書き換えられてこうなると。　しかしprelinkって乱暴ですね。

オープン中のファイルは移動したり削除しても影響を受けないから、prelink の
動作自体は乱暴でもないような。

lsof の出力に path inode が出ているのは、オープン中に置き換えられたファイルで
ある事を示しているのを初めて知ったから俺も勉強になったよ。

問題が解決して良かったね。

>>180
ありがとうございます。

> lsof の出力に path inode が出ているのは、オープン中に置き換えられたファイル
普通のファイルのように素直に"deleted"とか書いてくれればもっと早く解決したかもしれないんですけどね。
ちょっとその場合とは意味が違うのでしょう。　後で勉強したいと思います。

# cat > hoge.txt &
[1] 9317
# lsof | grep hoge.txt
cat 9317 root 1w REG 253,0 0 15 /hoge.txt
# rm hoge.txt
# lsof | grep hoge.txt
cat 9317 root 1w REG 253,0 0 15 /hoge.txt (deleted)

よくそこまで調べたなー

/proc/kcoreをgdbに繋ぐなんてテクニック初めて知った
すげぇわ

>>182
/proc/kcoreはgdbで使うための仮想ファイルだろ？

http://www.gentoo.org/doc/ja/prelink-howto.xml
4. 既知の問題と解決策

怠け者な俺は、locateとかprelinkなんて余計なものは真っ先に外しちゃうからなぁ。

>>185
locateの便利さがわからんか。
デスクトップ検索の先駆けだぞ。

ファイルシステムってハマる時はハマるのだな…。
自分ならとても解決できなかったように思う。
locateは入っていたがprelinkは入れてなかったので入れようかと思っていたが、
こんな理解不能の事態が発生するのでは、いれていいかどうか不安に感じてしまう…。

>>186
だって全然使わない、デスクトップ検索自体しないし・・・
GoogleDesktop入れて気付いたが
広大なwebならともかく自分の管理してる所なんだから
情報はちゃんと整理してる、というかしていないときもちわるい
Spotlightも使わない
なのでlocateのありがたみもよく解らんです

>>188
/home以下じゃなくて、使ったこと無いコマンドとかインストールされているか
調べるために、 locate hoge とか実行する。

というか、「お前は自分の管理してるマシンのファイル名を全部覚えているのか？」
もしやっているならご苦労なことだ。

コマンドなら、whichでいいだろ。
locateなんてわざわざ使わん。

>>190
パス通してない無い場合は？

コマンドは例だったが適用例は設定ファイルとかファイル全般。

俺はwhichもlocateも使うよ。
locateはかなり良く使うけどなぁ。

cronでslocate走った後って、メモリ消費量増えない？

>>187
いや、自分の場合はrootをr/oにするというハックをしている状況なのでハマっただけです。　
組み込み系のアプライアンスのための要求なので普通のホストシステムならたぶん問題はないでしょう。

しかし今回の経験で学んだのは、Linuxホストのrootをr/oにするっていうノウハウがあまり
確立されてないという事。漠然とセキュリティーのためにそうする事もあるという事を
見聞きしてましたが、今回のことも含め、ハマる穴は沢山ありそうです。

>>194
BSDに比べて/をroにすることを考えていないといえば考えて無いとはいえると思う。

prelinkとかは止めりゃいいだけだが、
/usr のパーティション分けたら動かないものとかあったりするし。

というか、cronでprelinkなんか動かしているその組込み系の
ディストリを明記してくれた方が有益だと思う。
あるいは、PC向けのディストリをベースに自力で構築している
ならそう書くべきだな。

>>193
>　cronでslocate走った後って、メモリ消費量増えない？

ファイルキャッシュが増えるからだよ。

>>196
失礼しました。　単にCentOSをアプライアンスとしてカスタムインストールしているだけです。　
「組み込み」とはいっても中身はPCマザボの普通のサーバーですので。　面白いのは色々とごちょごちょ
いじっている時に/etc/rc.d/rc.sysinitにこんなコードを見つけた事：

　if [ -f /etc/sysconfig/readonly-root ]; then
　 . /etc/sysconfig/readonly-root

　 if [ "$READONLY" = "yes" ]; then
　 # Call rc.readonly to set up magic stuff needed for readonly root
　 . /etc/rc.readonly
　 fi
　fi

これ見たとき、お、ちゃんと考えてるじゃんとか思ったのですが、肝心の/etc/rc.readonlyがないんですよね。
"magic stuff"は自分で書いてくれとのことのようです。

>>194
ひとりでこつこつとやっててもむずかしいよ。
組込み系は組込み系のコミュニティーで
ノウハウが貯ってるからねぇ。

システム全体に全文検索のindexを作るのは現実的じゃないからファイル名検索は現役だけど、
slocateはupdatedbを実行するまでindexが更新されないのが困る。updatedbの実行中は負荷高いし
モジュールの追加に抵抗が無ければ、ディレクトリツリーを変更するシステムコールをフックして、
インデックスを即時変更するrlocateの方がスマート

updatedb重いよなぁ。
デュアルコアとかマルチプロセッサなら多少は軽減されるだろうか？
ま、どっちにしてもサーバ向けの機能ではないし、いらないっちゃいらない。

重いと感じない私は使い方間違ってる？
動作中は確かにディスクアクセスが増えるけど、CPUそんなに使わないし
五分もしないうちに終わるし。
ディスク合計1テラ弱を八割程度しか使ってないから？
ｼｽﾃﾑはP4HT2.8G SATAディスク500GB+400GBです

updatedb って中身は主として find を呼び出している
シェルスクリプトとして実装されていることが多いですよね。
nice したらそんなに邪魔にならないし、
そんなに邪険にしてやらなくてもいいんじゃないだろうか。

>>201
サーバとデスクトップで区別する理由が分からん。
どっちでも有用だろ。

手動実行しても重たいとは思わないが、
普通はcronでniceつきで回すだろうから全く問題ない。

>>200
rlocateって標準装備してるdist.ってある?

ちょっと前にさ、locateが速いのはホントにupdatedbのおかげなのか？と思って

・普通にupdatedb + locate
・単なるfind | gzip > list.gz + zgrep

で比較してみた。

そしたら、なんとfind + zgrepの方が、というかlocateよりも
zgrepでリストファイル検索した方が速かった。リスト作るのも
当然findのみの方が速い。updatedbは内部でデータベース作ってる
わけだけど、スペース削減の意味がほとんどない今、もう過去の
遺物かも知れんと思ったよ。

過去の遺物だろうね。
fedoraではFC3あたりからlocateのサービスが切られてるよ。
それ以前はデフォルトでcronで走るようになってたけど。

makewhatisも切ってほしい

>>205
なんかオレが調べた結果と違うなあ。(ただしFreeBSD上)

手元のPCはディレクトリとか込みで200万ぐらいファイルがあるんだけど、
zgrepで調べたほうが遅くなる。
アルゴリズム的にファイル数が増えるにしたがって差が開くはず。

locateのデータベースはファイルリストをソートし、一つ前のファイルパスと
異なる部分からしか記録してないのでファイルサイズが小さい。
しかも、検索する際にスキャンするデータの大きさはlocatedbのサイズ分だけ
ですむ。
gzipしたファイルを検索する場合は元のファイルの大きさ分スキャンしないと
いけなくなる。

ちなみにファイルサイズはlocatedbだと17MB弱、gzipものは18M強、
bzip2だと15MB強でどれもほとんど変わらんかった。
元のファイルリストは200MBぐらい。

検索時間はlocateだと0.19s、zgrep, zfgrepだと1.45sぐらい、
bzgrep, bzfgrepだと12s弱ってところ。
ためしに元のファイルでgrepかけてみると0.26sぐらい。
(Pentium4 2.8GHz, FreeBSD 6.1)

もちろん、rlocateみたいにファイルの名前が変更されたときにデータベースを
更新するのが一番いいけど。

みんなそんなにファイル調べる事あるの？
>>189
コマンドインストールしてるかなら、パッケージ管理用のコマンド使うし
自分がパスを通している所以外にコマンドが入っていることなんてまず無いし・・・

で、動的なファイル検索ならfindを使う。
色々調べ方を指定できるfindの方が便利だし。

つまり、偶にしか使わない機能だから、ちょっと位速くなっても・・・という気分。

>>209
一般ユーザで find / するとパーミッションで読めないファイルあるでしょ。
(これはlocateも同じ問題が発生するが)

わざわざ毎回 find / することを防ぐために locatedb 作ってるんだからさ。
locatedb 更新後に追加したら、updatedb 実行すればいいだけだし。

>>208
こっちはLinux。規模はやっぱり200万ちょっとくらい。

updatedbのデータはもう作らなくなってしまったので今追試は
できないけど、データ構造的にはupdatedbの方が高速になるはずと
いうのは同意。でも、結果はそうでなかったので「？」だった。
「.」で探して全スキャンとかしてみるとどう？

>>209
大抵のファイルのありかは頭に入っているわけなので、
調べる必要がある時は「わからーん」という状況のことが多い。
そういう時にfindではターンアラウンド大きすぎて試行錯誤できず
不便なことがある。locate,locate,locate。。。あった、位に高速でないと。
でも、最近はファイルシステム構成やパッケージ構造が標準化されて
あまり出番はなくなった＞locate

ソースとか溜め込んでるとlocateは便利だよ。
例えば前にコンパイルしたバージョンほげほげのtarballはどこいったって感じで。

あとconfigureでライブラリとかヘッダーファイルがないって言われたときも結構使うね。
Perlのモジュール使ってるときにも元の.pmファイルが見たいときがあるんで使うなあ。

なんとなくだけど、自分でコンパイルしない人はlocate使わないのかも。

>>212
findだと大変だもんね。

自分でコンパイルするときはどこに何が置かれるのかおよそ把握するし。
ログを残しておけば、それを見ることも出来るし。
コンパイル専用ユーザとか作るのも普通でしょ？

>>211
% time locate / > /dev/null
1.058u 0.014s 0:01.07 99.0% 16+227k 0+0io 0pf+0w

% time zgrep / filelist.sort.gz > /dev/null
2.449u 0.067s 0:02.57 97.2% 97+388k 0+0io 0pf+0w

やっぱzgrepのほうが遅いみたい。

% time zfgrep / filelist.sort.gz > /dev/null
8.372u 0.044s 0:08.45 99.5% 96+379k 0+0io 0pf+0w
% time zegrep / filelist.sort.gz > /dev/null
2.485u 0.029s 0:02.52 99.2% 96+387k 0+0io 0pf+0w

しかもfgrepのほうが遅い。
(fgrepが遅い理由はググれば出てくるはず)

>>214
小規模かつ一人でやってんならそうでしょうね。

>>214
tarball内のファイル名全部を記憶してるわけ？
log取ったあとに移したりすると意味無いから、
ログより新しい情報で無いと使えないことがある。

locateは使った時に便利さが実感できるけど
使わない時は本当に使わないね。
半年くらい前にサウンドデバイスのテストしようとして
locate "*wav" したのが最後だ。
cronで毎日更新してるけどなんかもったいないな。

>>218
まぁ、いいんじゃない？

あー、locateバリバリ使わないとどうにもならなかった事例思い出した。

前任者が勝手コンパイルで入れたsenmdmailの入れ替え。
インストールログが一切なくて、そこらじゅうのマシンのいろんなディレクトリに展開されてる
sendmailの内、どれを使ってコンパイルしたのか分からない。
仕方ないからマシン全てでlocateを実行しましたよ。
findだと日が暮れてたと思う。

結局、コンパイルに使ったソースファイルはどこにもなかったけど。

locate 使うかどうかなんて議論するほどのことか?
便利だと思うなら使えばいいし、
必要ないと思うなら使わなきゃいい。
どうしてもやりたいなら雑談スレでやってくれ。

>>221
うっせぇよ。どんだけ偉いんだお前？

自分で管理もしてないPCの locate の結果が信用できるのかね。
しかもそんな状態の。

>>223
＞自分で管理もしてないPCの locate の結果が信用できるのかね。

言い出したら1日前のファイルリストなんぞなんの信頼性もない。
その正当性は人が確認すればいい話。
何もlocate hoge | xargs rm -rfなんてことがしたいわけじゃないし。
ファイルが今もその辺にあることを「知りたい」だけなんだよ。

locateの機能をファイルシステム側で提供してくれるとうれしいと思わないかい？

rlocateのやり方だとリモートディスクが変更された場合に検索できなくなるから、
ファイルシステムの機能として取り込んでくれないかなあ。

ぶっちゃけ頓挫したWinFSみたいにDBにメタデータつっこんでくれれば、
なんでもし放題でいいんだけどなあ。

beagleとか大して使われなかったな

単純圧縮だと時間が線形に増えるのに対し、
木検索だとlog2になるので、数が増えれるほど差が開く。

線形検索だと処理が単純な分オーバーヘッドが少ないので、
数が少ない場合は線形の方が速いし、数が多くなれば木の方が速くなるだろ。

更に、パイプでつなげて複数のプロセッサを同時に使えるケースだと単純2倍になるとか、
条件変数をいじれば閾値が変わる。


比較するなら条件付けないと意味なさげ

reiser,reiser騒ぐヤツはどこでも疎まがられてますな。
(Reiser4. BEST FILESYSTEM EVER.)

彼らが亡き者にされないことを祈ります

>REISER4 FOR INCLUSION IN THE LINUX KERNEL.
危な臭くなってきますた。

どこに書かれていますか

Reiserの事件が起きたのが不思議だったが
このスレの速度見てたら納得した。

Linuxに於いてファイルシステムは重要な位置にある。

Reiser裁判の続報マダー？

SCO裁判と合流いたします。

4/6からreiser4のお話でLKMLが荒れてます。
お話はベンチマークでreiser4最強説から始まる。。。


BEST FILESYSTEM EVER.
ttp://marc.info/?t=117582320300003&r=1&w=2
ttp://marc.info/?t=117606890500003&r=1&w=2

REISER4 FOR INCLUSION IN THE LINUX KERNEL.
ttp://marc.info/?t=117609196200002&r=1&w=2

Troll Of The Year (Was: REISER4 FOR INCLUSION IN THE
ttp://marc.info/?t=117611593400001&r=1&w=2

mmカーネルには入ってるのだから、
メインストリームに入れられない理由が技術的問題なんてありえない。

>>235
ここまで大きくなると、政治も技術なんだよね。

単にコミュニケーション能力だろ？

メインストリームに入れたとして誰がメンテナになるの？
一緒に変更されるIO周りのメンテナンスは？
入れて終わり、じゃないから難しい

>>238
俺だけど？

>>239
お前じゃぁ、やっぱり見込み無いな・・・。

akpmなら、akpmならやってくれる！！

mm＝マジ ムカツク

>>242
-mm は、マゾ・マニア用。

Reiser4の最強性能を使いたくないとは
判り易すぎる工作員だよな。

きなくさいどころか大炎上ものだろ。
反対するやつら尋問して黒幕吐かせろよ。

>>244
ちょいと聞きますが「Reiser4の最強性能」って具体的にどんなもんですか
新規インストールするノートPCにどのFS使おうか迷ってるもので参考の為お伺いします

とりあえずチキンな俺は ext3 だな。

>>244
ここで工作活動して、なんの意味が・・・?
皆ext3のダメなところを十分知ってて使ってるだろうよ。

jfsはチキンな俺でも時々使ってる

ルートはext3だがデータフォルダはjfsだぜ。
特にいいところも問題もないから話題にならなくて困る＝情報が少ない。

ﾗｲｻﾞｰをﾊﾞﾆﾗに入れるとだれもext*を使わなくなるから。

>>250

ディストリビューションが公式にサポートしない限り、バニラカーネルに入っても
あまり使われないような気がする

ディスク使用効率を比べたらJFSが一番良かったので動画保存用に使ってる。
NFSサーバにもしてるが性能は気にならない。
SquidのキャッシュはXFS。
データベースもXFS。
この二つは以前reiserfsだったが、システムが不安定になったのでやめた。
その他はext3で何ら問題ない。reiserfs以外はクラッシュした事も無い。

FTPサーバがまだreiserfsだった。
そういやこいつも何ヶ月に一度か固まるんだよなぁ。
reiserfsやめようかな。

FreeBSD 7が出たら、ファイルサーバはLinux ext3からFreeBSD ZFSに移行する予定。
OpenSolaris ZFSのほうがいいんだけど、ヲレはいいにせよ、いつか管理を引き継ぐときに
後任の人間が管理できなさそうなので。

それは勇者だな。止めはせぬ。止めはせぬぞぉ。

smpatch update叩いて
svcadmin 叩くだけでいいんじゃないっすか？

FreeBSDもSolarisもLinuxしか知らない人間にとったら同じなのでは？

そういう意味じゃないだろ

Sun、次世代ファイルシステム「ZFS」の技術をOpenSolarisへ寄贈
http://journal.mycom.co.jp/news/2007/04/11/015/index.html

これでLinuxへの移植も弾みが付くかな？

>>258
VFS (ぼそっ)

GPLか、となると、もう、ごそっと根こそぎ色々買えちゃいましょうよ。

・・・いや、それならSolarisカーネル使ったほうが早いか・・・

じゃあGNU/Solarisで握ってください

結局VFSの何が問題か誰も説明できてないんだよね。

説明できるくらいならなおせるからでしょ。
一言でいうなら｢遅い=効率悪い｣ってことじゃ？

>>262
煽る以外に芸のない、いつもの人乙。まあ、恥垢臭全開の悪臭公害っぷりは
芸に入るのかもしれないけどな。

遅い？
なにが？

エラーを伝えて上流の処理を変える機構が無い　んじゃ？
エラーといってもリトライでどうにかなるものもあれば、別のセクタに再割り当てしなきゃならないものもあるし、
FS内の格納情報まで遡って変更をしなければならないものもあるだろう。

Ｃ言語が「戻り値を複数持つように設計されていない」のと同じで、設計から抜け落ちているんだと思うが。


SCSIは、それに対する解決法の一つとして、まずエラーが発生した事を伝え、
詳細情報は別途参照するようになってるけどな。

>>262
そういえば、ソースコードで指摘してるのいないな

>>266
そんな抽象論をされても困るのですが。

抽象論でも具体的に反論できる人ならできる話に見えるけど。
それができずにVFSが駄目という定説を覆そうなんて思ってるの?

じゃ、libataのFUAとかDPOのサポート状況を見れとかそういう話をすればいいのかな？
>>266はATAとSCSIの一般論をいっているような気がするので。

>>ID:8G0xdNdm
こいつを相手にするだけ無駄だって

ソースコードの指摘まだ出てこないですねえ
ソースコード指摘したら、相手してやってもいいけどなあ

ソースが欲しいんだって

このスレにそんな高等なやつおらへん
ソースコード、gitでとってきて読んでるやつすらいないと思われる

>>274
そうなの？ちょと幻滅
簡単なんだけどなあ
でも、俺のカーネルレポジトリのディレクトリに移動したから、もうちょっと待ってみる

gitの使いかたすら知らない奴がいたりしてw

知りません教えてください
でもそういう技術的なことと設計の問題は別ではないのですか

git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
とか。
さあ語れ。

えーと、ソース落としたことない奴いるのかよw

ソースを落とすのがそんなに高等なことですか

じゃねえw
ソース落としたからには、読むってことはするんだろうしw

みんな逃げちゃったの？
暇だから、linux-2.6/fs配下適当に読んでる

暇なら働けばいいじゃん

OpenBSDがぱくったソースでも見るかな

なんの技術論もせずに煽るだけ煽って消えたか。さすがはいつもの人。

git使いがいるっぽいのでスレ違いだが質問
ファイルのタイムスタンプそのままでcloneするにはどうすればいいのん？

>>286
gitレポジトリにはタイムスタンプ情報は無い気がする。

>>287
あんがとう

man読んでも見当たらなかったと思ったら、やっぱりそうなのかー
その点は好きになれんなー

>>245 です
アク禁で今まで書けませんでしたが、皆さんありがとうございました
ところで昔々言われてたJFSの日本語問題ってどうなったんでしょう?
(クグったんてすが解決したという完全な記述が見付からなかった)
あとSELinux使うにあたってはJFSやReiser4でも問題なさそうなので良かったです

漏れ、XFSの性能がいい理由とVFSがダメっつー話が実際のところコード的に
何が違うのか知りたくてコード追っかけたことある。ところが、ext*だろうが
XFSだろうが、結局カーネルの共通ルーチンに途中で処理が委譲されていってしまい、
結局なんであんなにXFSがいい結果を出せるのか正直理解できなかった。
その過程に何かあるんだろうけど。

シンポジウムでmmがext4に関連して「ext4設計するためにXFSが
あれだけいいのはなぜか、時間ができる度にソースを読むのだが、
わからない」と話したそうでログがxfs-mlに出てたけど、レベルは
違うだろうがまさにそんな感じ。

ただ、XFS on Linuxのソフトウェア的な構造は他のfsとは異質で、
同様に移植されていたJFSが普通のfsなのと比べても異彩を放ってる。
VFSスタックと別にXFSだけが内部的に別のVFSレイヤが存在してる
みたいな２重構造になってる。遅くなる要因の様に思えるのだが、
特に遅いわけでもなく、逆にハイロードでも遅くならないというのは不思議だ。

s/mm/akpm/

ロリコン

XFSがそんなに速いなんてしらなかった。
マウントが妙に速いとは思っていたけど、使ってみて速さを特には感じなかったから。
ちょっと見直そうかな

実際に製品で使われているものだから
sgiも気合い入れてるんでしょ

ところでJFSて製品で使われてるの？
IBMの

AIXだとデフォルトでjfsじゃ無かったっけ？

>>293
速くはないよ。遅くもないけど。
重く（なら）ないというのがより正確だと思う。

速度だけなら揉めてる最中のreiser4が侮れない。「お前ホントに
書いてるのか」と思うくらいブッチギリの時がある。ちなみにJFSが亀。
あまりにも差が付いてるので再測定してる所だけどな。

ただ、読み書きサイズを増やすと優劣の順位はしっかりあるものの、
数割の範囲内に収まってくるので、通常利用（＝小ファイル
アクセスで体感しているもの）は結局はバッファリング性能とか
ディレクトリエントリのスキャン性能を体感しているだけと
言えるんじゃないかな。

>>296
reiser4はベンチ上での速度？
圧縮してるから、ベンチとかでよく使うファイルは0ばっかのファイルで
書き込み量も少なくなるし、速くなるのは道理、とか言ってたな。

>>296
> 「お前ホントに書いてるのか」と思うくらいブッチギリの時がある。

cacheに書いてACK返しているとかいうオチは無いよな?

>cacheに書いてACK返しているとかいうオチは無いよな?
XFSもそうだ。

>>298
そういう状態も含めて各種条件でデータ取ってます。結局実使用条件は
様々なので、全部デフォルト、sync、O_SYNC、stdio使う、syscall直、
ログサイズ、コミット間隔など、mkfs/mount/benchmark方法の３条件を
パラメータとして変えていってfsによってどう挙動が変わるかなと。
組み合わせ爆発が起きるのでかなり絞ってるんですが、１巡させるだけで
１週間とか、馬鹿みたいに時間かかってます。

>>297
です。postmarkでやってます。これはランダムデータ書くので、
たぶんバッファリングと小ファイルの持ち方が強烈に効いたのかなと推測。

>>297
圧縮の意味まちがえてるんだぜ?

winから読める、winを読む、の互換性重視で言ったらまだext3のほうがいいの？

ｻﾝﾊﾞつかえばFSは何でもよいのでは？

>>301
もしかして単に小ファイルの持ち方（パッキング）のこといってる？
圧縮プラグインって完成してたっけと思いつつ返事してたけど。

通常の自宅鯖として使っている俺としては、
うん1000通あるMaildirの処理さえ早くなってくれれれば、
あとは正直どうでもいい。

1000通くらいならtmpfsで

そんなあなたにはﾗｲｻﾞ4が最適でしょう

Reiser4のメインストリームのLinuxカーネルへマージまだー？
マージ阻むのもいい加減にして欲しい。

hansを排除して満足したと思ったら大間違いだった。

>>308
なんか実装がすげえ汚いんだっけ？

hans氏を隔離して開発を滞らせて信者のほとぼりが冷めるのを待ってるんだよ

汚いというか、Linuxっぽくないコードなものだからいちいち手直しするのに時間がかかっているとかいう話を聞いた。ITmediaだったか@ITだったか。

>>311
実はWindowsドライバだったとかなｗ

Linuxっぽいコードって何？
Linuxのコードって闇ナベみたいなものじゃなかったっけ？

>>313
その程度の知識では話にならん。

>>313
まず、GNUのコーディング規約の紙を100部印刷しろ。それからそれを全部破いて捨てろ。
話はそれからだ。

地球にやさしくないスローガンだよな

>>314-315
そんなあなたには

「伽藍とバザール」

バザール開発＝闇鍋と言いたいわけか

闇ナベは言葉が悪かったかもな
統制を重視しない手法で成功しているっていうこと

>>313
Reiser4のコード読めば分かるよ。
reiserfsの時も少し読んだけど、字面的にはかなり気持ち悪かった。

いやいや、Reiser4のコードはどうでもいいんだ

Linuxっぽいコードってあるの？

assert使うコードが(ﾟДﾟ)ｳｾﾞｪｪｪ って他の開発者に言われて、Hansたんが
assert使うのが当たり前だろって言ったってエピソード聞いた気がする

ってことは、reser4はassertバリバリ入りまくりなんだろうな

>>321
Reiserfs以外のコードはだいたいそれっぽいが？

assertの何が悪いの？
ま、一通りデバッグおわってるなら削除しても良さそうなものではあるけど。

最適化にも使えるのに>assert

ポイントポイントのassertについては入れとく方がまっとうな
より厳格・安全なので基盤系ソフトとしてはやってて欲しいけどな。

あってはならないデータがそのままコードの奥にまで到達して
誤データにより悪さされるより、意図的に入れたassertのポイントで
トラップして死んでもらった方が被害が少ない。

Hans が逮捕されて Namesys の存続も危ういのにマージしろっつー方が無茶だろ。
メンテナがいなくなれば結局外すことになるんだから、今となっては難癖つけて
マージしなくてよかったと思えるよ。

なにいってんだ。
HansがReiser4の開発から抜けるだけの公算が高いだろ。
Reiseer4はNamesys社が引き続き行うのにその言い草は無い。

だいたい、>>327もいってるように「難癖」なのだから
マージしない方がおかしい。

誰が考えても一連の流れはおかしいのに収束に向かわないという事は
それほどの大物が黒幕だという事？

>>328
Namesysってそんなに開発力あるのか？
ほとんどHansだけだと思ってた。

Reiser4から5も6も権利一切を誰かに譲りますみたいな話が出てなかったっけ。

>>326
Q.冗長なassertが多くないですか？
A.お前はセキュリティの素人か？これが最強なんだよ？わかってる？

みたいな感じだったはず。

>>326
基盤系はなにがあっても死んだらまずいのでは？
むかし坂村健氏が講義でいってたよ。通常のアプリケーションならともかく
OSなどの基盤系では死んでしまうわけには行かないから使えないと。
FSがどちらに属するかは微妙だけどDBMSなどとは違い、基盤系とするのが普通じゃなかろうか。

>>332
基盤系って括りがそもそもおかしいのでどうでもいいです。
その昔の変な先生が間違ったことを言っていたのでは。

カーネルの挙動が変なと死ぬのは同じくらい辛いとおもうよ

>>331
原文読んだけど、そんなニュアンスではなかった。

・消せと言う意見には反対
・なぜから、セキュリティの専門家の意見ではないから
・漏れ（=Hans）もかつてはassertゲェッと思っていた
・が、reiser4の開発でDOD（出資者だな）の専門家から学ばされた
・彼らの安全性に関するスタンダードに従う価値は高いよ

という内容だった。ただ、それ以前から関係が悪化していたことを
踏まえると、読んだ側には冒頭の「they are not security experts」とか
書いてるところでカチカチカッチーンって感じだったんだろうね。

とある系列会社のプロジェクトの火消しに行かされた事がある。
まったく assert を使っていない自前のライブラリを使っていたので、
仕様にそってアサーションするようにしたら、
「あんたが来てからエラー表示が増えた。バグが増えた。」
って怒られた。唖然とした。

>>334
変な先生ってｱﾅﾀ、滅亡しかけているとはいえトロンの創始者だょ

>>336
エラー表示が増えたのは確かだろうね。
バグは増えたのではなく、かかれていたものが露呈しただけなワケだけど
同じコードでもassertいれないときはなんとなくうまく動くこともあるんだよね。
もしかして、見えざる神の手によるコンバイル時最適化じゃなかろうか（嘘）

>>338
どっかのスタックが壊れてたりしそうっすねｗ

この文脈で坂村先生の話を持ち出すのはおかしいと思う。
どっちかというと、FSのエラーでディスクに誤データが書き込まれる方が「死んだらまずい」に相当するのではあるまいか。

>>332 死ねない、それは一理ある。
しかしそれは assertion とは無関係の話。
だって実稼動するバイナリはくときには assert() なんて消えてるでしょ。

多くの実装ではリリースビルドの際に assert() はバイナリ吐かないように
なってるし、プロジェクトによってはログにメッセージを吐いて
何事も無かったかのように通過するような assert() に置き換えられている
ものもある。

>>341
一般的な理想論は敢えてしまいませんか？

消せと言った側の理屈は、コーディングスタンダードに従えってことでしょ
assertが良いか悪いかとは別の次元の要求
オレ流正義を貫きたいだけの人のコードはマージしないから他所で好きに作って
っていうのは難癖じゃなく真っ当な対応かと

>　消せと言った側の理屈は、コーディングスタンダードに従えってことでしょ

実際と違う
原文読もうよな

LKML
http://lkml.org/lkml/2005/9/9/218
8. Remove all assertions because they clutter the code and make it hard to read

>>340-341
実働ｼｽﾃﾑではテスト時にうまく動いても、ユーザの予期できない使用でバグが露呈することがある。
しかしいかなる状況であっても制御不能になることは避けなければならない
という言い方をしていたと記憶している。
その意味でassertは使えない、という話だったと思う。

>>345
コード読みにくいから消せってのでは、言い掛かり以外の何者でもないように見えるけど
それほど多くのassertいれてたんだろうか。

>>346
手元の奴でこんな感じだな

% zcat ./reiser4-for-2.6.11-3.patch.gz |grep assert |wc
3847 18265 212260
% zcat ./reiser4-for-2.6.17-3.patch.gz |grep assert |wc
3538 15552 179184

もとのパッチが8万行ぐらい

しまった、>>347コメント行排除し忘れた
200行ぐらい減るなあ

xfsも山ほどassert入ってるがこれは問題にならんのかね

しーっ!

必要なパラメタチェックは必ずしなきゃ駄目だし、冗長なチェックは意味が無いから消すべきだ。
オレは坂村信者じゃないが、突き詰めていくとassertを使うべきところって実は殆ど無い。
assertなんて曖昧な事するのはプログラマの怠慢だと思う。
ドライバならたとえハードウェアが壊れようと、それが原因で不正な挙動をするようなコードを許すべきじゃないだろう。

>>351
なんていうか、NULLなfpをreadしたりしそうな人ですね。

>>352
ポインタのNULLチェックは必要なチェックの代表格ですよ？

http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.6/ManagementStyle.htmlでも読んでおちけつ

ぬるぽ

assertが入ってるとその関数がどういうパラメータを許すのかが
一目で分るからいいな、というのが初心者の考えなんだけど

ほとんどの人はバカです。そして、マネージャであるということは、あなたが
その事実を受け入れなければならないということです。そしておそらくさらに
重要なことは、彼らの方もあなたを受け入れなければならないということです。

技術的な過ちは簡単に取り消せますが、壊れた人間関係を取り消すことは簡単
ではありません。あなたは彼らの過ち（そしてあなたの過ち）をただ受け入れ
なくてはなりません。

しかしながら、カーネルマネージャとしてうまくやるために、あまり多くのカ
ーネル開発者と絶交したり、無実の罪をきせたり、疎遠にしたりしないように
した方が良いでしょう。疎遠になるのはとても簡単ですが、逆は難しいのです。
したがって「疎遠になる」と、すぐに「取り返しがつかない」ことになってし
まい、Chapter 1 によるところのやってはいけない事になります。

Linux カーネル コーディング規約
http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.6/CodingStyle.html

Linuxの規約はこの程度だよ

まず最初に、「GNU コーディング規約」(GNU coding standards)を入手して印刷してみてください。
でも、読むために印刷するのではありません。
印刷した物を燃やすのです。
この儀式は晴れがましい意思表示なのです。

原著作者: Linus Torvalds

まぁ、あまりに多くなりすぎると、ログが流れて余計にわけわからないってのはあるな

自分がデバッグの為に入れておく物と、公開後のレポートで期待するものは別にしておくべきだと思うし。

int
hoge()
{
}

CodaとかAFSとか使ってる人いる？

メリットあるの？

伽藍とバザール
http://cruel.org/freeware/cathedral.html

>>363
オフライン運用ができる・・・はず。
CodaはWindowsでもマウントできる・・・はず。

>>364
ひとりよがりな訳の典型。
｢伽藍とバザール｣なんていわれてもまったく意味がわからない。伽藍ってなに？
本文読むと対比関係として提示されているけど、なんで？って感じ。

>>366
いまさらな話だなぁ。
http://www.ruitomo.com/~hiroo/bbs/kohobu0045.html

伽藍(←読めない)

>>367
とりまきがキモイ

なんでfsスレでカビの生えた伽藍とバザールが出てくるんだよ。

脳の能力が弱い人はいつまでたっても脳の性能を向上させられないから

>>370
>>317

>>372
>>317 は的外れだろ。伽藍とバザール読んだだって
>>313には分からないだろうし。

>>370
>317の発言の発端は>311

311 名前：login:Penguin[sage] 投稿日：2007/04/14(土) 19:45:50 ID:rJ7PlvJe
汚いというか、Linuxっぽくないコードなものだからいちいち手直しするのに時間がかかっているとかいう話を聞いた。ITmediaだったか@ITだったか。

この真偽はどうなんだろうな？

>>374
Linuxってなんか変な人に無理やりGNUファミリーにされちゃったんじゃなかったっけ？

俺は俺と友のために闘ってたつもりが、気がついたらレジスタンスのリーダーに祭り上げられてた的な。

>>375
LinuxカーネルはGNUファミリーとはただの知人だったが、
GNUのコマンドが必要なのでディストリが親戚になってしまった。
*BSD系はどうなんだという反論はあるかと思うが、基本的にはこれで間違ってないはず。

がんばってBopenOfficeとかB.orgとかbnomeとか作ってくれたら拍手ものだったが。

>>373
>317は>319のレスもしているのであながち解ってないとは言えないと思う。

>>374
>>311の言っているITmediaや@ITの記事ってのはこれのことかな。

http://www.itmedia.co.jp/enterprise/articles/0608/25/news023.html
>Reiser関係者はパッチを誰に送付すべきかやコーディングスタイルなど、パッチの送付についての「ドキュメントやマニュアルを読んでいない」とクローハートマン氏は語った
>おそらく近いうちにReiser 4はLinuxカーネルに採り入れられるだろう、とも彼は話していた。

http://www.atmarkit.co.jp/flinux/rensai/watch2006/watch08b.html
>Andrew Mortonから「ゆっくりではあるが、Reiser4のコードをレビューしている」というせりふが出てきました。

まぁ、実際の内容はちょっと>>311の覚えている内容とは違う雰囲気のようだったがな。

Reiser4のカーネル取込の本当の理由は何だろう？

・ext4がいけてなさそうな感じだから
・ZFSの脅威にLinuxとして手っ取り宣伝的に早く対応したかった
・Hansの手を離れてコード変更が入ってないからじっくり見てみるかという人が増えた

>>380
そもそもreiser4取り込んだのか？

>>380
Linuxのキラーファイルシステムにしようというわけだな。

あきらかに優れているものを取り入れない理由があるとすれば
政治的か個人感情以外の理由があるか？

そもそもReiser4が本当に優れているのかどうかという疑問はあるけど…
技術的な問題はやっぱりあると思う。
コード可読性とかメンテナンス体制とか

それが解決されているのであれば…
やっぱり政治的か個人感情なのかな？
私にはそれぐらいしか思いつかん

reiser3ですら不安定なのに4なんてとんでもない

reiser4を怖がっているのは、reiser3はバージョン上がったときに
痛い目あった香具師がなますを吹いているだけに思える。

癖はあるが、自分では痛い目にあったことないから。
ただし今のところは。

注意はすべきだと思う。
ミッションクリティカルな分野には信頼性が確認されたものを使うべきだし。

2.6.19 (Debianでは2.6.18でも起きていた) mmap()のトラブルでは
ext3でのみ問題が顕在化してファイル破壊が起きていたけどな

正直、Linuxで信頼性の確認云々なんて求めるほうが間違っていると思うぞ

>>388
それ、sidじゃなくて安定版で？
fedoraもよくトラブルは起こるけど…

>>389
正式リリース前のetch用のlinux-image-2.6.18。もちろんsidもだけど。
問題が顕在化する2.6.19向けのパッチを当ててbuildしたkernelを配布して
いたんで、世間では2.6.19だけで起こるといわれていた問題が、Debianでは
2.6.18でも発生するということで、LKMLでは大騒動に。この辺の話は
http://www.atmarkit.co.jp/flinux/rensai/watch2007/watch01b.html 参照。

んで、Debianでは確か2月末頃に問題になるパッチを捨てたパッケージを
出して解決。逆にいえば、12月末に問題が解決されたというのに二ヶ月程度
それを放置して、mmap()でファイルをぶち壊す問題のあるkernelを配布し続けた

>>390
これはまずい…
でも検証に時間かけるとそれだけ開発は遅くなるしな…
なんかいいテスト法はないものか

余談だけど、mmap()のバグというとGCのないLFSで有名なNILFSもかなりすごい。
なんせチェンジログを見ると、1.0.9まではまではmmap()したファイルの書き出しが
出来なかったとか、1.0.13まではkernel 2.6.17以降で使用するとやはりmmap()した
ファイルの書き出しが出来なかったとか。

あと、
・NILFS 1.0.15 をリリースしました．
Kernel 2.6.20 に対応しました. チェックサム計算のバグを修正しました.
これにより, これまでbig-endianのマシンで作られたNILFSディスクはマウント
できなくなります.
というのも凄まじい

>>391
Linux kernel的には2.6.19をリリースしてから問題が報告されるまで約1週間、
それから原因追求してパッチが出るまで約3週間ってことで、がんばっては
いると思う。もちろん、他のOSではWin2kのNTFSの圧縮を利用していると
ファイルが壊れるなんていう例はあったものの、変なオプションを適用していない
plain状態でファイルを壊す例は少ないんで、なんでこんなトラブルを
起こすのかいなとは思ってしまうけど。

Debianに関してだと、すでにetchのインストーラのRCを出していて、
みなさんどうかテストしてくださいって状態だったのに、重大な問題を
2ヶ月放置したのはいただけない。問題が解決されたkernelがexperimentalに
出たのは1月末で、それからetchに降りてくるまで1ヶ月もかかった。
他に問題のあるパッケージがあったから、そのせいでなかなかetchに
降りてこなかったとのことだけど…

NILFSはネタだろ
存在自体

バザーモデルではReiser4が早々に取り込まれていいはずなのにそうならないのは
結局個人感情に過ぎないのだよね。
ま、オープンソースなんだから誰でも自由に取り込みゃいいんだけどさ、
それはそれで技術的問題があるのだが。

技術を理解できないヤツはすぐ感情論を出す。
まぁreiser4のどこがマージの障害になっているか
解説した「日本語の記事」がない状況ではしかたないか。

まーた始まった

>>395
いつもの人、例のごとくの煽り乙。

キチガイのスレでは正気な人は荒し扱いされるんだな

可哀想に>>398、酸素欠乏症にかかって…

>>394
バザールモデルなら、reiserが勝手にフォークするのが普通だろ。
無理して一本化する必要がない。

で、どこがﾏｰｼﾞの障害なわけ？
assertか？

mmにはどうやって取り込んだんだろうね？

バザールモデルといいつつ、実はバザールでもなんでもないのがLinux kernelの
開発モデルだからなぁ。

*BSDの開発モデルのとてつもない誤解もあって、発表された当初から「伽藍とバザール」は腐れ文書。

過去スレを漁ってたら出てきたので貼っておく。

ttp://kernelnewbies.org/WhyReiser4IsNotIn
と上の日本語訳
ttp://www.linux.or.jp/JF/JFdocs/WhyReiser4IsNotIn.txt

>>402
＞バザールモデルといいつつ

言ってたっけ？

>>404
ESRがね

>>403
> 彼らが一部の Reiser4 の先進的な機能を無効化するよう要求したからと言って、
> それが Linux メンテナー達がどれだけ思慮が浅いかを述べる助けにはなりません
> (これらの機能は VFS の不和を招き、Reiser4 は結局これらを無効化しました)。

結局ここが一番大きいんでない？

感情論と言うのは簡単だけど、
ライセンス的にもクリアで、期待されていて、
マージが技術的にクリアなことが立証されれば、拒否する事はできないだろう。

論理的理由無しに拒絶するとこの規模のコミュニティは成立しない。

キチガイが作っただけで信用できないし、
そんなのがつくったのをレビューする酔狂な奴もいないからマージされないんだろ？

このスレにキチガイが居るのは事実だが、
reiserfsの作者は過剰にアグレッシブなだけでキチガイではない。

mmカーネルではうまく動いているようにみえるので
技術的問題といっても言い訳にしか見えないわけだよ。

>>410
動けばよいというものではないぞキチガイ

実際、言い訳なんだろうな。
でVFSとぶつかるのはなぜなんだ？

>>411
問題なく動作してるのに、どこに問題が？

408=411=いつもの人か。なんでこいつは粘着し続けるんだろう?

ここに来ればかまってもらえるからじゃね。

reiser4の性能がホントに良いなら、早くmainに入れて、皆でバグ出ししたほうがいいのにな。
少なくとも、reiser3は安定してきたし、reiser4も-mmでアルファテストは終わったようなもんだ品。

>>409
過剰にアグレッシブなのとキチガイの境目はかなり曖昧だと思う。

reiser4は悪くないと思う。

Linuxをビジネスで使おうというやつらは、ベンダーのサポートのある
ファイルシステムしか使わんよ。
RiserFSの方がext3よりも早いというテスト結果が出た場合でも、
最終判断はベンダーのサポートする方を選ぶって事だったもんな。
SUSEがReiserFSから手を引いた今、Reiser4をメインラインに入れても
対した影響力は無いだろよ。
使いたいマニアは使うだけだ。

>>416
それが本当なら、さっさとレビューしてマージされるようにしたら？
だが、そんなことをすると reiserfs がクソであることが露呈するので reiserfs 信者はやらない。
ファイルシステム破壊ごっこするのが安定というのならもう何も言えないけど。

ここに-mmを知ってるやついなそうw

またいつもの人が湧いて出てきたか…

>>420
ってか-mmが何の略かすら知らないだろうな。

また恒例の自作自演ですか

かわいそうな人なんです

>>416
>　でVFSとぶつかるのはなぜなんだ？

http://www.tac.tsukuba.ac.jp/~yamato/samba/11000/msg00478.html
>　ReiserFS,XFS は vfs が持っている「user data が意地で
>　も async でしか書き出されない」というバグを回避するために、自前のルー
>　チンを登録しています

奥山氏ものでかつ古いのはすまそ。

>>422
マッハムカつく の略だろ。 もう死語だけどな。

ext3を使ってはいけないことがよくわかりました。
ext4も似たり寄ったりでしょうね。
そしてなによりVFSのバグが諸悪の根源なのですね。
ありがとうございました。

>>427
ホント分かってるのか?
使っていいfs言ってみ?

>>428
えっと…CIFS、ですか？

>>428
FAT12

>>428
tmpfs

>>427
ext3が一番無難なので、イマイチ面白くないよな。
reiserfsだのXFSだの良いながら、業務ではext3使っちゃうな。

LFS

寺捨てｼｮﾝはXFS採用してた

Linuxで何が面白いかといったら、いろんなFSが使えることだろ？
*BSDはそうはいかない。
その意味ではReiser4も入れて欲しいな。
*BSDがZFSちゃんと使えるようになったらちょっとなあ。

いろんなFSが使えるというのはデメリットでもあるよね

○○にはこんな不具合が！ ⇒ △△使っとけ
△△でファイル消えた！ ⇒ □□使えバカ
□□だと遅いんだけど… ⇒ ○○使って首吊って氏ね

結局、エンドユーザにとってはFSの多様性なんて鬱陶しいだけで
デフォルトとして、安定して速いFSがひとつだけあればよくて
それに物足りないときにだけ ほかのFSに手を伸ばしたい。

extXが安定して速ければこんな状況にはならなかったんだけどね

そうだね

でもZFS上でUFS作るお間抜けさんも・・・・

mmカーネルではﾗｲｻﾞｰ4の先進機能はオフになってるのか？
VFSのasyncでしか書かせないというバグをなんとかできれば、すべてが丸いんじゃないの？

>>440
default config そのまま使う気か?
それならパッチくらい調べろ。

NetBSDのLFSも安定してきたきがする

softupdate（だっけ？）は電源断耐性が強いという点で評判がいいな

>>442
Linuxにはいろいろなfsがあるといわれているけど、LFSほどの実験性と実用性を持った
fsはないんだよなぁ。実用性無視ならNILFSがあることはあるけど…

詳しくお願いしていいですか

extのほうがはるかに実績あるからな

>>437
ext以上にとろいFS使ってるやつらに失礼だぞ

>>445
Log-Structured File Systemについてか?
とりあえずは ttp://www.atmarkit.co.jp/flinux/rensai/fs03/fs03a.html
でも読めば?

ちなみに、そこで挙げられているLinux LFSやLinLogFSは長いこと開発停止状態。

>>448
NetBSDのLFSの話じゃないのか?
実用性って部分が良く分からんが。

>>449
実用性がある=普通に使える。NetBSDではLFSで生活している人もいる。
LinuxのLFSは、どれも普通に使えるようなシロモノではなかった。
あ、NILFSはいちおう現在進行形だから、過去形でいうのはアレか。

NetBSDなんlかどうでもよくねw

ひょっとして、BSDのsoftupdateって、LFSのGC処理？

>>452
それはまったく関係ないです。
古い資料ですが、↓読むべし
http://groups.google.com/group/fj.os.bsd.misc/browse_thread/thread/549e97c89705ad19/b0d7a80a3a3c41a1

Linux: ZFS, Licenses and Patents
http://kerneltrap.org/node/8066

>>446
> extのほうがはるかに実績あるからな

それだけがext*の強みなんだよな
大きな強みではあるんだが．．．

extの存在があるから、安心して今はJFSをデスクトップで試している。
でも問題がないのでextの出番がない。

>>456
JFSを使いながらextの存在で安心する状況ってどんな使用法だろう。
毎日使っているファイルシステムでもし仮りにデータ破損が起きたら、そのデータは取り戻せないのに。
extのファイルシステムにたいして毎日データのバックアップをとっているから安心だというならわかるが
（私も似たようなことしている）
そうだったら「extの出番はない」なんてことないだろうし。

Reiser4を使おうとしたらmmカーネルのビルドからはじめなきゃならなくて、
やってみたら別な問題で動かないカーネルになってしまった。
めんどくさすぎる。
はやくﾊﾞﾆﾗカーネルに取り込んでほしい。

Reiser4よりxfsの方が速度面とﾃﾞｰﾀ保全性では高性能じゃないか、という意見をみたことがあるのですが
比較した結果をみたことがありません。
実際のところどうなんでしょうか？
速度面でJFSは劣り、EXT3は速度も電源切断時の安全性もダメなようです。

ﾌｧｲﾙｼｽﾃﾑの安定性という意味では、Reiserfs(v.3,4)は評判が悪いようですが
過去のバージョンアップの際、きちんとドキュメントを読まなかったユーザが
痛い目をみただけで、本質的に問題があったようにはみえません。

結局、安定性では比較できないようです。

ドキュメントを読まなかったぐらいで安定性が消えるファイルシステムを
使いたくないな。ファイルシステムにまで神経つかってたら
鯖運営なんてしたくなくなるよ。

>>461
お前、ものすごく頭が悪いな

>>461
ファイルシステムの互換性の不備と管理者の怠慢は別問題。

回避できる問題は不備とは言わんと思うけどな。
怠慢な管理者には難しいのかな。

だから不備とはいってないでしょ。
セキュリティーホールが見付かった時とか、
他の不具合が出てカーネルのバージョンアップする際に
fsのChangeLog読まなきゃいけないんなら、やってられん。
素直に不具合がでにくい他のfsを使うよ。
自宅鯖だからそんなに手間かけたくないんでね。
そんなのただの俺の管理ポリシーなのになんでそんなに食いつくの?

>>464
自分からトンデモを言っておいて「なんでそんなに食いつくの」かよ。
お前の頭の悪さは手のつけようが無いってことは理解してやったから、消えろ。

近頃、 Reiser4 が最強ってことにしたい人達が積極的に活動してるみたいだね。

どこがトンデモなのかを具体的に指摘せずに
人をトンデモ扱いする奴は大抵トンデモな訳だが。
「アインシュタインはトンデモだ!」みたいな奴。

apt等でパッケージ管理してるのにわざわざドキュメントの
パッケージを落としてきてfsのChangeLog読まないと
地雷踏む可能性があるのは嫌だという
ロジックのどこがトンデモなのかを指摘してくれよ。

正当な指摘だったら素直にあやまるからさ。

ID出る板で数字コテハンつかうヤシは往々にしてバカという法則がまた成り立ったな。

これは酷い

バカでいいからさ、指摘まだ?

FilerとNFSつかってろ

地雷踏んだのはaptユーザじゃないだろう。
すくなくとも、お手軽アップデートのひとが困る仕掛けにはなってないはず。

なんか、各所でこういうキチガイが湧いて出ているけど、春だからなのかな?

さっさとSolarisにすればいいのに。今ならおまいらの好きな"タダ"だよ？

むしろWindows Server 2003にすりゃいいのに。奥山先生も認めたマトモ設計ですよと。

やっぱりNetBSDだな
史上最強のファイルシステムLFS

>>461
説明書に書いてある通りにやってファイルが消えちゃうなら
不具合だと思うけど、説明書に「こうやったらファイル消えるから注意」
ってあるのにそれを読まずに操作してファイルが消えたと叫ぶのは
おかしい。

>>472
つまり自前でコンパイルしてる人は犠牲になってるんだろ。
パッケージメンテナがraiserfsのことをちゃんと気にしてる保証もないし。
自己責任とはいえrobustな運用には耐えないってことだよね。
自己責任だからこそ自分の運用で責任が持てない
fsは使いたくないんだよ。大切なデータがけっこう一杯あるからね。

>>473
キチガイはキチガイのまわりに湧くんだよ。
人をトンデモとかキチガイとか言うことしかできない
君と関わってしまったということは俺もキチガイだねw

>>477
俺は一度も不具合だと言った覚えはないし、
ファイルが消えたことを騒いでるんでもない。
いちいちChangeLogを読まなきゃいけない運用を強いられるfsを
使いたくないと言ってるだけなんだが。

>いちいちChangeLogを読まなきゃいけない運用を強いられるfsを
たぶんChangeLogを読んでたら、どのFS(に限らないが)も
運用してると胃が痛くなると思うよ。
>>478は何も知らないのが一番。

>>478
> いちいちChangeLogを読まなきゃいけない運用を強いられるfsを
> 使いたくないと言ってるだけなんだが。

自分がapt-getで終らせられればそれでいいんでしょ？

> つまり自前でコンパイルしてる人は犠牲になってるんだろ。

だから、この部分は考える必要ないし、考えても無駄。
多大な労力を割くメンテナを信頼しろ。
いやなら自分で文書かコード嫁。

>>461
お前、ものすごく頭が悪いな

>>461がreiser4のkernel inclusionを求めていないことはよくわかった。
キミは使うことはないだろうし、必要もないのだろう。それでいいじゃないか。
しかし、使いたがってる人が大勢いるのは確かだし、その人たちが
痛い目を見るかどうかなんて、キミには関係のないことじゃないのか？
なぜそういう人たちの代弁をしたがるのだ？

>>482
あいつは普段から
「J-POPなんて聞かねぇっすよ。
あんなの何でみんな買うのかわからない。」
とか言ってるんだよ。

Linuxの場合は、カーネルのメインストリームに入った後、
RedHatかSuSEがデフォルトで採用してちゃんとバグ出ししてくれないと
ホントの意味では使えないからなぁ。

それはまず、メインストリームに入れてくれないと。
使ってみてダメだと分かれば、外せば良いだけだしね。

>>483
メインストリームに入れるのはいいけど、それを入れる為に
VFSやら根っこの部分にまで手を入れられるのはカンベン。

ってのがreiserがハブられてる理由じゃないの？

でも、VFSどうにかしないとねっていう話はLKMLで出ているんじゃなかった?

ソース

出てたね。

今までxfsを使ってました。今はext3に戻してます。
ext3,reiserFS,xfsを使ってみて思ったのがreiserとxfsはCPUのリソースを変に掴んで離さない感じが
あったのですが、皆さんの所はどうなのでしょう？
例えば10Gくらいのファイルをコピー中に他のアプリを立ち上げようとするとやたらもっさりします。
通常1秒ほどで立ち上がるfirefoxでさえ起動に１５秒ほど掛かったりしました。
よって今はext3にしたのですが、ext3だとコピー中でもそれほど影響が出ません。
また大量のアップデートなどでシステムを更新する時もxfsよりext3が早かったです。
コピーやファイルの移動だけを見るならreiserやxfsは確かに早かったですが、全体のスムースさが
失われた気がしました。そんなもんなのでしょうか？

体感速度じゃなく、数値でだしてもらえるとわかりやすいのだが。
あと、ﾌｧｲﾙｼｽﾃﾑの選択によってｶｰﾈﾙｺﾝﾊﾞｲﾙｵﾌﾟｼｮﾝを変えたがいいのかも。

まぁ、個人差がある筈の経験でいえば、

ext2 電源落ちたら覚悟するべし
ext3 壊れた事がある
reiserfs 壊れた事がある
xfs 壊れた事がある
jfs 今のところ壊れた事が無い。

一度壊れたらその時点で横一線だろうけど。

>>490
壊れるというのはfsckかけてもmountできなくなる状態？
それとも直前に書いたデータが消えること？

羹に懲りて何年も膾を吹くのは間違った態度とは思わないですが、
開発者は辛いでしょうね。

>>489
そうですね、数値データーでも取ればいいのでしょうが。。
それとカーネルオプションでファイルシステムの部分は設定項目がそう多くなくほとんどチェックが入っている
のですが（モジュールとして組み込み、それにぶら下がるオプションはチェック）他に何か変更するような
部分などあるのでしょうか？

>>490
jfsは壊れにくいってよく聞きますね。ext3のdata=journalモードなどはどうなのでしょう。噂ではこのモードは
アクセスが集中した時のデーターの詠みだしにかなりのパフォーマンスを発揮するとか聞きましたが。

このスレ的には面白くないんだけども、
ext3は、速度も安全性もそこそこ良いんだよ。

>>493
速度はともかく、壊れにくさはあくまでLinuxのfsの中ではという注がつくでそ。

>>493
なんだかんだで今はext3に落ち着きました。
トラブル時の対処の情報の多さや、例えばLVMにした時にLVのリサイズなど比較的簡単に出来て、
PC可動上での処理能力時間だけでなく、管理や運用上にかけなければならない時間（情報収集や
お勉強の時間ですねw）も含めた上での速度としてみると自分の環境ではext3がベストかなと思いましたよ。

>>495
LVM使うってことはファイルサーバ用途? なら、Solaris + ZFS + RAID-Zマヂお薦め。
NFSの速度、安定性もLinuxとは比べ物にならんし。

現状NFSv4をACLまでしっかり使えるのは、SolarisとNetAppくらいか。

Linux: Reiser4's Future
http://kerneltrap.org/node/8102

>>493-494
ext3より遅いLinux用FSって何？
現役FSで最も遅いのがext3ではねぇの？

iso9660

reiserfs とか jfs とか xfs は ext3 より遅いね。

またまたご冗談を

>>496
レスどうもです。今はこのLinuxではサーバーにしている訳ではないです。デスクトップ+実験用w

確かにSolarisにした方がいいのではって言う方もいますね。安定性、安全性はLinuxより全然いいし
もしユーザーフレンドリーやGUIの操作性を考えたらWINDOWSの方が全然いいし、なんでLinux
にしたのって言われたことが＾＾；
オープンソースな環境も覚えたかったし、Solarisの敷居が高そうだったし＾＾；；；
なるほどNFSの速度も早いんですね、言われている組み合わせも頭の隅に置いておきます。

もう忘れたのか

397 ：login:Penguin：2006/09/12(火) 22:57:38 ID:nKd1xEVn
>>367
先月に各ファイルシステムの状況知識のリフレッシュを兼ねて
jfs/xfs/ext3/reiserfs/reiser4で各状況をpostmarkで試験してみたよ。
バッチで回してまる4日かかった。

そしたら、スモールファイル・フォルダ内大量ファイル、の条件では

　reiserfs>xfs>>jfs>reiser4>>>>ext3

となった。ただし、reiserfs...jfsまでで速度が一割も
変わらないので、たしかに差はあるが、reiserfs/xfsはほぼ同格。
ちょっと離れてjfs/reiser4が団子。大差でext3。なお、writeに
重点を置くとxfs>reiserfsとひっくり返る。また、ext3はbtreeで
mkfsしてないことに注意。

ちなみに、フォルダ内大量ファイルの条件を外すと、ext3がrd/wr/wrの
どの条件でも大差でトップになった。

まだ処理速度しか集計してないので、処理中のプロセッサ使用率とかに
差があったか（負荷高くて速くても意味なし）はまだ不明。他にも
スペース利用効率も比較の予定だけど、まだしてない。

398 ：login:Penguin：2006/09/12(火) 22:58:24 ID:nKd1xEVn
誤：ただし、reiserfs...jfsまでで速度が一割も変わらない
正：ただし、reiserfs...reiser4までで速度が一割も変わらない

オラクル通信 ファイルシステムの選択
http://www.oracle.co.jp/2shin/ora67/31.html

> 小規模なシステムでは、ReiserFSより高速なため多く採用されています。
> ところが、EXT3は構造が単純なEXT2を拡張したため、大規模システムには向きません。
> ディスク容量が大きくなったり、ファイル数が多くなると、前述のような問題が発生する可能性があるのです。

>>505
まともに障害対策も出来ないミラクルの恥曝し記事ですね。

>>506

今となっては古い話だ。大目に見てやれよ。
もはや、Oracle on Linuxでファイルシステムを使うことは
あまりないんだし（OCFS2は別として）。

巨大ファイルを一括で作って、自分で中身管理するとかに向いてるのはext、
単純なのでシーケンシャルが速い、巨大エロ動画はこれに決まり。
ファイル名が違う細々とした捜査が速いのがreiser、
システム、コンパイルその他一般的用途はこっちだろ。

DBで使えるだけの安定性あるんかな＞＞reiserfs


というか、FSによって、SJISファイル名使える使えないの差があることを初めて知った。
文字コード依存してたら、UTF8どうなんとか、アラビア文字どうなるんだとか、大変な事になりそう・・・・

>>508
extは巨大ファイルを複数作るとフラグメントが激しくなってくるから
それを何とかしてもらいたいなぁ、とエロ動画を大量に置いて管理している時思った

そんな今は、jfsをメインの環境に据えて使ってます。
使い始めて2ヶ月程だけど困ってはいない。が、ちょっとパフォーマンスには不満がある

俺は巨大ファイルを扱うのはxfsがいいって聞いてたけどなあ。
>エロ動画を大量に置いて管理している時思った
シリコングラフィックスが動画とか画像とか大量に置いて管理できるためのファイルシステムとして設計したからだとか何とか聞いた覚えがある。

# ただしソースは（ry

>>511
DVDのリップした物とか4Gくらいのファイルなどを一度にまとめてコピーや移動させた時のパフォーマンスは
xfsは高かったですよ。ext3と時間を計って比べた時に1.5倍早かった時もあった。
ただそのコピー中に色々なアプリを使ったりしたらアプリの動作がどうも遅くなってしまって結局ext3に
したけど、サーバーなどは通常その様な使い方はしないから、ファイルアクセスのパフォーマンスという
事で考えれば確かにxfsはいいのかな。

通常のデスクトップだと>>504に書いてある「フォルダ内大量ファイルの条件を外すと、ext3がrd/wr/wrの
どの条件でも大差でトップになった」ってのが当てはまるのかなと思った。

>>512
>スモールファイル・フォルダ内大量ファイル、の条件では
>reiserfs>xfs>>jfs>reiser4>>>>ext3
>
>また、ext3はbtreeでmkfsしてないことに注意。
始めに結論ありきのベンチマーク。

小さいファイルはreiserfs>xfs>ext3
大きいファイルはxfs>reiserfs>ext3
でしょ。

>>513
その条件だとbtreeもってる方が圧倒的に有利でしょってことかな？
一応あくまで各fsのスペックは標準で作成されたと見なした試験だったのでしょうね。
欲を言えばbtree入れたext3の比較とかもやってほしかった。しかし4日間とは。。すごいね
でもext3+btreeで使用ってあまり聞かないよう気がするのですが。。効くのかな

dir_indexのハカー曰く、
フォルダ内大量ファイルという条件では200倍速になります。
>Creating 100,000 files in a single directory took 38 minutes
>without directory indexing... and 11 seconds with the directory indexing
>turned on.

ext3でbtreeとか言ってる時点でもう

浦島確定だな

わりとでかめなサイズのファイルが結構多いとこにxfs使ってるんだが
遅いような気がしてならないんだなぁ。。
そこでbittorrent動かしてるかなぁ。

総合力でNTFSに勝てるLinuxのFSはない？
やっぱりLinuxはFSがネック．．．

>>520
まずは、NTFSの勝っている所から説明おながいします
それがないと話が進まなくて・・・・・
総合的に勝ってる負けてるでいうと主観合戦になります

何だよ総合力って

ただの燃料に何マジんなってんの。キモい。

う〜ん、そういえば以前の会社で2000serverをいじってたけどHDDの物理破損以外で壊れたことが
無かったなw

少なくとも耐久性に関してはNTFSすごいらしいよ。
さすが電源ブッチ上等のユーザを相手にしてきた百戦錬磨のMS…というくらい。

性能に関しては知らん
比較データ見かけんからね
NTFS-3Gがリリースされた今ならあったりするのかな？

やべーすごそう(棒読み)

NTFSも条件次第で壊れるんだが。
まぁ、それは某国人のようなガラの悪いアプリを使っている方が悪いとも言えるが。

耐久性については確かにUFSみたいなFSとは比較にならないね。
もっともLinux用のFSと比べればそれほど抜きん出ているかはどうだろう。

NTFSはやはりフラグメンテーションのアレが問題だね。
ディスク配置を最適化する機能をもったサードパーティ製品を入れて改善できればいけるのだが。

性能面ではどうだろうね。OSと切り離して性能を語れないから…。
NTFS-3Gは開発筋曰くまだまだ性能が出ていないので単純比較することはできないし。

ファイルがおおくなるとテキメンに性能落ちるからなぁ

>>525
NTFSの最初の設計者、Tom MillerとGary KimuraはDECでVMSをやってた人たち。

ファイル名の制限ってファイルシステム自体にあるのはやだなぁ。
システムコールとかライブラリまわりで制限があるのはわかるが。
でもそんなこと言ったらISO9660なんて制限ありまくりか

>　ファイルがおおくなるとテキメンに性能落ちるからなぁ
特にext3はひどい

後、前スレにもあるがNTFSはsyncで書き出すよ

書き込みキャッシュが有効な場合、ディスク パフォーマンスが低下する
http://support.microsoft.com/kb/332023/ja

>　仕様上、これらのコマンドでは、重要なデータの安全性のために、ある程度のパフォーマンスが犠牲になります。
>　これらのコマンドでは、重要なデータが即座にディスクに書き込まれます。

>NTFSはsync
それはファイルシステムの特徴というよりファイルシステムドライバの特徴ではないかと…。
fuseで実装しているntfs-3gなんかは、syncにならないと思っていたんだけど（どうだっけ？

>>533
>>532のリンク先に書いてあるのは、
「本来サポートされているはずの強制書き込みが、一時的にバグのためにサポートされてなかった。」
という意味でしょう。
NTFSの仕様も暗に示してるでしょう。

「fuseで実装している．．．」のくだりはLinux空間での実装の話でしょう。
MSのNTFS実装とはまた別の話。

つまりLinuxで実装するドライバがsyncになっていなかったらそれは仕様外の動作で、
つまりバグってことか。
NTFSの仕様がもっと明示されていたら仕様も実装しやすいのに、これは困るなあ（とかゆ

>>535
sync するべき部分を sync していない Linux の VFS の＊仕様バグ＊
と言えばいいのかな?
NTFS の仕様とは関係ないと思う.

ファイルが多いとテキメンに性能落ちるのって、NTFS？
Windowsで使ってるとそう感じる。
実際はExplorerがお馬鹿な情報の集め方してるんだろうけど・・・

というか、誰も定番のdir_indexツッコミをしていないのに関心したｗ

>>537
以前はdir_index付けてたけど体感できる効果無しだったので付けるの面倒くさくなって今はやってないw
それだったらジャーナルをdata=writebackにする方が体感できた。
当たり前だけどdata=writebackはいきなりの電源断があって再起動時にfsckが掛かるとほぼ間違いなく
電源断の5分前くらいにタイムスリップできます。直前に消したはずのファイルが綺麗に復活していて
作ったはずのファイルが無い┐(゜〜゜)┌

どこからツッコんでいいものやら・・・

>>539
一通り全部突っ込んでおけば？

馬鹿の相手するのも飽きた

dir_index の副作用ってあるの？

>>542
read aheadが効き難くなる。

結局XFSとReiserFSの直接対決した結果ってないの？

>>544
直接対決って何だ？ 代理戦争みたいなものがあるのか。

連休ですなぁ。

>>545
KARAT!か。

xfs使うとき、fdiskでlvm(8e)で領域を確保しなければだめですか？
linux(83)でも同等でしょうか。

lvmである必要は全くない。
LVMであれば、xfsの伸縮がし易いというだけ。

Linuxのファイルシステムなんてext3で十分だろ。
本当に他のファイルシステムがext3より大きく優れてれば今ある鳥の半分はそれに移行してるんじゃないの。
ext3以外を使うなんて趣味の世界か物好きだろ。

自分のこころが決める

http://kerneltrap.org/node/8102
5/7に裁判があるのか。

>>549
ありがとうございます。
スナップショットも同様と考えればよろしいでしょうか。
気になるのが、lvcreate -s したときに、xfs_freeze -f を実行しなくても
ちゃんと、ロックされるかが気になります。

lvm2+xfsでスナップショットしてみたらなぜかうまく行かなかった。
ロックは関係ないと思う。

ext4人柱patchset
ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/ext4-patches/2.6.21-ext4-1

ところで上のベンチ結果とか、キャッシュのオプションはどうなのかな？
read aheadやらwrite backの閾値だの結構あるよね＞/devや/procとかにも
流石にHDDの設定値はデフォってことなんだろうけど、そのへんどうなん、と。
総合で効いてくるの前提として、NCQあると劇的に速くなるFSだの、/procのチューンで(ry
だのって話も、スレ的には有りかと思うんだが、ほとんど変わらないというオチ？

vxfsとは

>>553
ロックされないと思う。
LVMとファイルシステムは基本的に違う層の話だから。
LVMはその上に載るファイルシステムを選ばないし、ファイルシステムもその下がLVMのLVOLであるか実ボリュームであるかを選ばない。
つまり、ファイルシステム側でumountやsyncで静的な状態にしたうえで、LVMでスナップショットを取る必要があるんじゃないかと。

>>557
Veritasの製造販売しているファイルシステム。
もともとは商用Unixのファイルシステムだったけど、最近はLinux版もあるらしい。

>>556
それは絶対性能には効いてくるだろうけど、同じ環境の上での
FS比較という点ではあまり焦点ではないんでないの？性能が
十分出せてるかどうかのためにddでの読み書き速度と比較したりは
するけどさ。

>>559
同じ環境上の比較といいつつ、ベンチで測ってるのは
FSの特性の極一部。

xfsdumpでもやはり、umountやsyncを行う必要がありますか？

フリーズ→LVMでスナップショット作成→フリーズ解除→スナップショットをxfsdump

VxFS & VxVMはZFSの登場で一気に陳腐化した気がする。まあ、Linux的には元々有料っていうのが
ネックでほとんど影響力なかったけど。

いろいろ検索してみたらxfs_freezeは不要なようです。
>>562さんはうまく動いてますか？

フリーズさせなきゃマウントしたままスナップショット取るだけで固まるよ

へぇ〜固まるのかｗ
ロック＆syncしてなきゃ、ファイルシステム的に不完全な状態のものになっちゃうから、
採れたとしても意味無いけど。
これに対して、zfsやext3のスナップショットはファイルシステムレベルのスナップショットだから、そのへんを気にする必要はないな。

今やってみると2.6.20では固まらないみたいだな。
2.6.16あたりのカーネルだとLVM上の/のsnapshot取るだけで簡単に固まってた。

2.6.16って13ヶ月くらいにリリースされてるね。
どこの浦島さん？

おっと、13ヶ月くらい前に

どうしようもないおばかさん達だな

>>560
>　同じ環境上の比較といいつつ、ベンチで測ってるのは
>　FSの特性の極一部。

ネットでゴタク並べる評論家クン。
一部しか測れないのは当たり前なんだよ。

１．同じ環境上で比較
２．環境をさらす。

特性の全てを測りたいならそのために必要なテスト項目を正確に言ってみろよ。

いや、だから同じ環境上で「何」を比較するのかね？

「何」を比較するかはそれぞれのテストで違うだろ？

ext4ってなんか望みなさそうだよね。

もうブロックデバイスの上のファイルシステムはお腹いっぱい感もあるし。
そろそろネットワークファイルシステムとか分散ファイルシステムに
開発リソースを振り向けたい。ていうか自分で開発したい。

>>575
> そろそろネットワークファイルシステムとか分散ファイルシステムに
なおさら VFS の利ファクタリングだ

何度もしてるだろ

ext4devのextentsにて/をマウントしたいのですが、fstabの書き方、あるいはbootでのカーネルオプション
の受け渡しが必要なのか教えてもらえないでしょうか？

ちなみに/の場合fstabへ/dev/sda*　 / ext4dev extents,defaults 0 1 の表記ではエラーが出てシステムが
ext3のroで起動してしまうのでfstabの書き換えが大変です（；；）

/以外では上記の方法でマウント可能、dmesgでもext4dev extentとして認識されます。

initrd使ってる?
GRUBってext4対応してたっけ？

>>556 >>571
まあ確かに関連のありそうなパラメータは全て列挙した上でベンチ結果出すべきだわな。
全てなんてのは無理なわけだがw

ファイル数とFSの種類による比較は結構あるけど、
例えばDB置いてSync大発生時のベンチと、通常ファイル運用での比較とか、
RAID板のバッテリバックアップなキャッシュの有無によって・・・とか、
条件次第でFS性能比較結果が逆転するとかならベンチの価値薄いとは思う。
NTFSなんざそりゃ(ry

XFSのドライブをマウントしたらこんなエラーが発生しました。
filesystem dm-0ってなんでしょうか。
XFS mounting filesystem dm-0
Ending clean XFS mount for filesystem: dm-0

>>580
列挙することは、有限である以上無理じゃないでしょ

>>581
それはエラーじゃない。
マウントしましたって通知メッセージ。
dm-0はデバイスマッパー上の論理ボリューム0番の事。

コピーが中途半端ですみません。

XFS mounting filesystem dm-0
Ending clean XFS mount for filesystem: dm-0
Filesystem "dm-0": Disabling barriers, not supported by the underlying device

これはエラーでしょうか。

エラーじゃない。

>>579
あ、レスどうもです。
おかげさまで今は / とデーター用HDD丸々1台をext4dev extentにて動かしています。/homeとか
重要なデーターディスク、その他は今のところext3ですw
ext3,4共にカーネルモジュールを組み込みに変更するためリメイク。カーネル屋のサイトから
e2fsprogsの最新を落としてmake install。あの後意外とすんなり移行できました＾＾

XFSのbarrier ってなんでしょうか。

おまえが知る必要は無い。

>>587
linux-2.6.21/Documentation/filesystems/xfs.txt

barrier
Enables the use of block layer write barriers for writes into
the journal and unwritten extent conversion. This allows for
drive level write caching to be enabled, for devices that
support write barriers.

>>588
あなたの口から直接聞かせて欲しいの。
お願い。

>>589
extent conversionって何か教えてください。

そのあたりには気違いと偏執狂がうろついてるから近づくな
忘れろ

>>590

590の人以外は見ないでください。
ttp://sakuratan.ddo.jp/uploader/source/date39503.jpg

みてしまった OTL

>>567

reiserfs+lvmでスナップショットを取ってバックアップを毎晩走らせています。SuSE9.0(カーネル2.4)のマシンと
SUSE 10.0 (カーネル2.6)のマシンがあります。2.4のほうは大丈夫ですが2.6は時々スナップショットを取るのをしくじっていて
自前のスクリプトの中の何回かのリトライでやっと取れたりしています。SuSE 9.0のほうですが当時最新だった9.3(カーネル2.6)で
負荷が重いときにLVMのスナップショットを取るとほぼ100%システム全体がハングアップしていまい
やむなく9.0にした覚えがあります。

Linux: LogFS, A New Flash Filesystem
http://kerneltrap.org/node/8159

ext3cow
http://www.ext3cow.com/Welcome.html
ext3をベースにしたバージョニングファイルシステムだそうな。

便利そうだね

そうかぁ?
ただのcowに過ぎない程度のものを
バージョニングだなどとほざいてる時点で、詐欺だろ。

そうなのか。

理屈はよく知らないけど、昨日からいろいろ試していたらsambaの領域はjfsが一番r/wとも速いので変更してみた

kwsk

>>602
俺601のこと？
pen3-500 mem 192mb
debian 最新、samba 設定そのまま、samba用のパーティションは別に切ってあるのを
ファイルシステム変えて、WinXPから読み書きの時間を計っただけ
平均4mbくらいのファイルを200個くらい、普段仕事で使ってるようなファイルでテスト

ベンチマークとかしてないお、自分の使い方だけが重要なので

むう・・・体感でどの程度差がありました？ 試した他のFSもいただけると助かります。

samba経由では確かにLinux上とは別の速度感があって、ネットワークなのかFSなのか何なのか、と
丁度調べてたもので。smbdのアクセスにはなにか特徴あるんですかね・・・
sambaが独自キャッシュでいろいろと持ってるので、そのあたりとの兼ね合いだと思うんだけど。

>>604
えーとね、xfsが俺の場合は一番遅くてjfsの1.5倍くらいかかった
jfs=60秒くらい、xfs=90秒くらいて感じ、ext3とReiserはその間くらいかな
jfsが玄箱ノーマルより速いのでw、jfsにしましたけど使い込むのはこれからだお

あんまり詳しくないし、産婆だけ動いたら問題ないので自分ではこれ以上追求しないけど
チューニングしだいで速くなるのは友人から聞いてるよ←プロのシステム屋にやってもらったらしい

jfsのチューニングってどんな方法があるんですか？
ちょっと試してみたい。ウチのマシンで。

昨日、JFSでディスクフルになったらcpがdeep sleepしたままになった。
リセットしてfsckで亊無きを得たが、やっぱり本格使用には不安が残る。
でも使うけどねw

reiserfsがコンソールに大量にエラーを吐いてカーネルごと死ぬ時がちょこちょこある．
ext3に戻したいが，今はそのマシンを止めるのも厳しい．
素人が変なのに手を出すんじゃなかったよ．

止めるのが厳しいのはきついね＾＾；

自分は常に回避用にHDD丸々１台分の空きを持っているのだけど、お金があればTAPEドライブ
が欲しい。。。早いらしいですね。TAPEのバックアップは。

自分的にはテープよりディスクのストレージ製品の方が速いと思っていたのだが。
よく考えてみたら仕事環境と個人環境では条件が違いすぎるな。
…でも個人での外付けディスクでのバックアップもそんなに遅くないと思うけどなあ。
……まぁそれも環境に依存するのか。

>>608
KNOPPIXとか1CD Linuxでブートして、ファイル全体のバックアップをとってフォーマットして
また戻すということはできないだろうか。
自分はいつも緊急時にはrsync -Hav --delete でバックアップやリストアを考えてやっている。
# むろん他のコマンドでもできるだろうが。

とりあえずUSBの外付けHDD付けて、dump&restoreすればいいんじゃないの？
USBにつないだディスクのブートブロックにgrubをインストールしておけば、
データをコピーし終わった後にディスクを入れ替えて復旧させることができると
思うけど。

>>610
個人レベルのテープストレージは糞と言い切って良い気がするがどうか？
LTO2位になればHDDよりもメリットあったりするけど、ドライブが30万とかで普通は手が出せない。
DDS系は安くて個人でも買えるが、容量少ない、エラーレート高い、クリーニング周期短い、で手間の方がかかりすぎる。


>>611
USBは手軽だけど遅いぞー
ヘビーユーザー相手だと、データを全部コピーするのに三日かかるとか、
コピー中にUSB変換が熱暴走したとか、ろくなことにならないのがオチ。
windowsしか使えない人なら、取扱いで時間かかるよりもメリットあると思うけど。

漏れなら、HDD直結かネットワーク経由だな。
うまくやれば、ネットワーク経由でも直結と速度変わらなかったりする。

usb2.0なら糞ほど遅いとも思わんが。

昔DATもらってきて自宅でも使ったことあるけど
テープによるバックアップソリューションは潤沢なテープだけでなく
スケジュール管理など手続きの明確化と自由度の無い粛々とした作業こそが大事だと痛感した

>>612
USB2.0なら3時間ちょっとで100GBぐらいコピーできるよ。
7〜9MB/sなんでそんなに遅くないと思うけど。

>612
LTO2くらいなら中古とかなら結構安くなってるんじゃない?
あとは会社の廃品をくすn(ry

30〜50GB でよければ(DDS+クラス)そろそろ BluRay ですかね

テープが早い？？
どこの世界の話だろ？

>>617
LTO2やLTO3だとHDDの転送速度よりも速いですね．
私も欲しいです．LTO2物色中。

テープが遅いとかUSBが速いとか言ってるガキがファイルシステムを語るとはねw

いいんじゃね？個人使用レベルの話なんだから

>>618
バスの種類でも違ってるの？

ﾋﾝﾄ:RL02

エンタープライズ用途だったら、バックアップの選択はこんなだ。
1.テープにする
2.テープにする
3.テープにする
HDDの大容量化に伴って、テープをディスクで置き換えることが現実的になったとかいう業界人（ディスクベースのバックアップ製品の会社のCEOとか）もいる。
が、現在のとこはまだテープ以外には無いだろうな。
ディスクアレイでもボリュームの一時コピーとかを高速で別領域でバックアップしたとしても、最終的にはそこからまたテープでバックアップするもの（まぁ例外もあるが）

しかし、個人使用だといろいろ事情が変わってくるよなあ。
結構テープって高いんだよね（テープ単体じゃなくってテープドライブ製品）
金に余裕があれば迷わずテープ製品買うんだけどさあ。

…というかファイルシステムのスレだから、バックアップ方法の話はスレ違いだったか？

とりあえず
「テープとファイルシステムの相性ってどんなだろう？」
とかとってつけたようなネタ振りしておくよ。

DDSで痛い目にあった経験がある人はテープにアレルギーが出来てて、
説得するのに苦労するというか、ほとんど説得不可能だったりする。

reiser(本人の方)はその後どうなったんだ…
もう判決出てるんでは

linuxがreiserをサポートしないという
判決マダー?チンチン

Linuxがreiserをサポートって意味が分からん。

じゃあ、SUSEがreiserを見限るでもいい

>>628
suseはreiserfs捨ててext3にしたはずだが。

>629
ホントだ。わーい

　 ∧＿∧　ﾊﾟｰﾝ
　（　・∀・）
　　　⊂彡☆))Д´)←>>630

キャポー

やっぱライザ4速いのか

エンタープライズから一気に下層まで下りるようで悪いんだが、
RAIDぽい機能を付けたFS、ってのはあるんかな？
localファイルとnfs先のどこかのファイル2つでミラーされたファイルが発生みたいな。
ディスクとかボリューム単位ならありそうだが、そろそろFSが機能持っててもいいような、とか。
又はその手の機能用にインターフェースが用意されてるとか。

またZFSの話題ですか？

>>634
の言いたい意味が全く分からんが、
ファイル単位やディレクトリ単位の冗長化設定ということか？？？？

ZFS・・・とは違うような
俺も>>634の言いたいことはよく分からんが

何のメリットがあるのかな。
ネットのインフラがよほどしっかりしてないとRAID1くらいしか組めそうに無いような気がするけど。。。
データー量でネットのリソースも食いそうだし・・

>>634
FS層でやる意味がない
やるならせめてVFS層

善し悪しはともかく、二つ目のジャーナルを用意すれば簡単に実現できそう

md+nbd

>>634
AFSじゃ駄目なん？

ごめん日本語が不自由すぎた
>>635 みたいなのであってます。ファイル単位でローカルHDD2台とnfs先にミラーリング指定、とか。
VFS層だとファイル単位でsync方法の指定変更とかやりにくそう。
DBや一部のFSでジャーナルを別ディスクに置いて・・とかあるけど、もうちょっと突き詰めてみたり。
指定ファイルはRAMDISK上にミラーしつつ、readは常にRAM側のみから行う、とか。
ドライブがBusy気味だったらnfs先からも引っぱってみるとか。
指定ディレクトリエントリは常にオンメモリとか。
このディレクトリ以下はバカアプリがsync吐きまくっても無視してキャッシュしてね、とか。
細かい挙動設定できると楽しいかなぁと。
ウイルスチェックソフトを拡張したら出来そうではあるんだが、
最終的にはFSが持たないと出来ないことかなぁと思って。

>>640-641
ども。おもしろそう。

HDD 交換を機に個人用途の leafnode で使う news spool を別パーティション
にしようと思っているのですが、なにかお薦めってありますか。
binary 系は講読しておらず普通のテキスト記事ばかりで今のところファイル数
は30万、容量1.7Gってところです。
無難に ext3 でもいいんですが、少々データが壊れても痛くないってことで
なにかいいのがあれば冒険してもいいかなーと。

つ reiser4　タイムテストされてないという一番の弱点を無視すれば面白いと思う

みんなUSBメモリのファイルシステムって何使ってる？
FAT32？NTFS？
Reiserfsとか使ってる猛者いる？

USBメモリーはWinでも見る可能性が高いからFAT32だろ
わざわざ互換性のないFS使う理由がある？

Winをつかう可能性がなければなんでもよいのでは。

FAT32の標準クラスタサイズでの最大容量に近付いているからな。

FAT64

linuxでUSBブートさせるならext2/3とかにしておくな

>>648
んまぁ、クラスタサイズでかくすれば2TBまで大丈夫だし、当分はFAT32でそ。
メモリカードの類は相互運用性・互換性が最重要。

しかし、頻繁に強制アンマウントが発生しうるデバイスで、ジャーナルなしのファイルシステム
というのも恐い。

どうもLinuxの強制的切断への対応は、いまいちらしいね。
「Windowsの方が良いくらいだ。改善しよう」って呼び掛けでいる人がいたような…。

>>653
むしろ逆のような気がする

NTFS壊れで起動しなくなるコンピュータは結構見掛ける。
まぁWindowsが多いから、というだけのことかもしれないが。

>>653
いまいちどころじゃない。
が、いざというときはダンプすれば、ということなのかも。

最近ext3とかreiserfsが飛んだ人いる？

>>657
Linuxマンセーはウザイだけ

FreeBSDではファイルシステムが飛ぶのは日常だよ

>>659
HDDのwrite back cacheを切ってください

>>659
softupdate 入った後は, ほぼ鉄板. Linux は何度もあるけど...
3-current の頃から使い続けてるけど FS 飛ぶの HD が逝った時くらいしか経験ないな...

>>652
アンマウントするデバイスだと最初から考えて使えば問題ない
無造作に使うから問題が起こる

>>662
だなぁ。bufferingしなきゃいい話だし。こうなるとfsの問題ではなく、
mount時のオプションの問題。

>>663
> bufferingしなきゃいい話だし。

FAT使ってても？
バッファリングしなきゃいいのは、
ジャーナリングファイルシステムやソフトアップデートの場合の話。

ﾅｼが噛み合ってない

バファリンでも飲んで落ち着け

頭が痛いときにインドメタシン入り膏薬貼っても効く
肩が痛いときにバファリン飲んでも効く
アスピリン錠剤買うときは一番安いのを買え。中身はどれでも同じ。
イブプロフェン製剤でも同じ。中身は同じ。
各社のインドメタシン膏薬の成分も小数点以下３ケタまで同じ。

でも中国産にだけは気を付けて

>>667
それはいいことを聞いた。
腰が痛いからあとでバファリン飲んでみるよ。

腰痛の原因は様々だからアスピリンやインドメタシンのような
プロスタグランジン合成を阻害する薬では効かない事も多い

ソンナモン阻害していいのか？

だから胃が荒れる副作用がある。
膏薬でも空腹時に大量に貼るのは良くない。

>>670
だから半分が優しさなんだぜ。

何この流れ

残りの半分はエロ。
ファイルシステムの半分はエロでできています。

>>674
実際にＦＳ上に格納されるデータの性質
を考えると待ったクソの通りだな。

差分ファイルシステムってないの？
fuseとかで特定のファイルにだけ差分扱えるとなおさら便利っぽいけど。

nilfs

よくわからないが、そういう目的のためにあるのがSVNなのでは？

>676
発想はもっともだし過去にも色々あった

だが、結局普通の file system に統合しちゃうと
無駄邪魔使いにくいということなんじゃないかな > 流行ってない

ファイルシステムで差分が欲しいってのは、バックアップ用途だと思うから
pdumpfs くらいの差分粒度で納得してる

ファイル自体のバージョンが欲しいときは、バージョン管理するし

UFSとかZFSでできるスナップショット機能の事かな？

ZFS厨乙

>680
最初に見たときは目から鱗だったなー > pdumpfs

vmwareの仮想ディスクファイル(40Gくらい)を順次バックアップとりたい、とかって場合に
差分使えるFSあるといいなーと思ったことはある。

それくらいならrsyncでもいいんじゃ

SVNって差分(サヴン)って読む？

ザブングル

＊＊＊＊＊＊恋のおまもり＊＊＊＊＊＊

　　これを見た人は，超超超超幸せもの☆☆

　　�@週間以内に好きな人に告白されるか、
■■■■■■■■■■■■■■■■■■
■■■■□□□■■■■□□□■■■■
■■■□□□□□■■□□□□□■■■
■■■□□□□□□□□□□□□■■■
■■■□□□□□□□□□□□□■■■
■■■□□□□□□□□□□□□■■■
■■■■□□□□□□□□□□■■■■
■■■■□□□□□□□□□□■■■■
■■■■■□□□□□□□□■■■■■
■■■■■■□□□□□□■■■■■■
■■■■■■■□□□□■■■■■■■
■■■■■■■■□□■■■■■■■■
■■■■■■■■■■■■■■■■■■

　　好きな人とイイ事があるよ・・・・☆★

　 コレを読んだら、1時間以内にどこかに貼る★★

数ゎあなたが好きな人への思いを込めて

[RFC PATCH] file as directory
http://www.ussg.iu.edu/hypermail/linux/kernel/0705.2/2861.html

これで少しは前に進むだろうか。

cp -r とかの挙動はどうなるのだろう？

　cp file-as-folder newfile

では file-as-folder のファイルだけがコピーされるのか、
それともフォルダとしてコピーされるのかとか。

後ろにスラッシュがついてるかどうか次第

pdumpfsは個人的に愛用してるんだが、ACLのバックアップがされてなかったことに後で気付いてぐんにょりしたわ。
本当ならpdumpfsに手を入れてACLもコピるのが正しいんだろうが、面倒だったので、pdumpfs後にgetfacl -R . でバックアップを取って、同じディレクトリにbzip2して置くようにしたよ。
なんかあったら、最新のデータを回復させ、setfaclで再適用。

もうひとつ、ext2の拡張属性もだった、こちらも取得しておかないといけない。

スレ汚しスマソ

　　 {失礼。}
　　　 ζ
　 　　　!(+Φ＿Φ)つ"　 ζ
　 　 +⊂.　+ 〆∂　　 ☆
　 　 "〆∂∂
　 　〆〆
　 .:"
【読み難いです。】



＠

　　 {失礼。}
　　　 ζ
　 　　　!(+Φ＿Φ)つ"　 ζ
　 　 +⊂.　+ 〆∂　　 ☆
　 　 "〆∂∂
　 　〆〆
　 .:"
【読み難いです。】
















＠

　　 {失礼。}
　　　 ζ
　 　　　!(+Φ＿Φ)つ"　 ζ
　 　 +⊂.　+ 〆∂　　 ☆
　 　 "〆∂∂
　 　〆〆
　 .:"
【読み難いです。】







@

>>690
!(ΦｙΦ+){file.移動などと比較してみたいですね？}

　　　 ζ
　 　　　!(+Φ＿Φ)つ"　 ζ
　 　 +⊂.　+ 〆∂　　 {釣}
　 　 "〆∂∂
　 　〆〆
　 .:"


@

pdumpfs はハードリンクの上に成り立つのに、ハードリンクを
保存できないという自己矛盾がいただけない。
歴史的にも vbackup などもうちょっとマシな実装が先にあったし。

そういやrdiff-backup使ってるけど、ACLとか含めてどの程度保存されるのかきちんと検証してないわ

[RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md
ttp://www.ussg.iu.edu/hypermail/linux/kernel/0705.3/0572.html

このスレには一家言ある人がたくさんいたと思うのですが、
まだ誰も議論に参加してませんね。

このスレには馬鹿とキチガイしか居ないよ

>>699

ごめん、ノータリンな私にはこの「自己矛盾」がよくわからん。
もし時間あったら教えてほしい。

自己矛盾というより、「不便だ」って言いたかったんじゃないか？

皮肉っぽく無く言うとこんな感じかと。

ファイルシステムの議論が読みたくてROMっていたので、できれば解説よろしく>>701

>>702
いつもの人、乙

>>644
ごめん、せっかく薦めてくれたけど結局日和って ext3 にしちった。
やっぱカーネルにパッチあてなきゃってのはちょっと面倒で。
でも xfs でもよかったかなとちと後悔。

>>707
凄い勢いで日和ったｗ

なんかext4の進展が全然無いような気がするのは自分だけ?

誰も期待していないから

おもしろそうなのでxfsにしてみた、ext3より速い感じ

>>708
そのかわり、デスクトップマシンの /home や /var なんかは xfs にしてみた
から許してくれw

>>703

pdumpfs があまり容量を使わずに過去のスナップショットを
たくさん取れるのはハードリンクのおかげ。
ところが、pdumpfs はバックアップ元でのもともとのハードリンク
情報を関知しないのでバックアップ先ではハードリンクが失われて
しまう。それを自己矛盾と表現した。

個人的には cp -al + rsync -aH くらいの方がずっと良い気がする。

そんなあなたにrsyncの--link-destオプション。

それだと世代管理できないじゃん。

ちがった。誤解してた。
(cp -al) + (rsync) = (rsync --link-dest)
だ。ごめん。

Apple、Mac OS Xのファイルシステムに「ZFS」を採用
http://journal.mycom.co.jp/news/2007/06/07/003/index.html

zfs最強すぎ

>>718
linuxでも使える日が来ればね。

>>719
FUSEでなら使える

http://www.nilfs.org/en/

NILFS version 2 will be available soon, a Garbage Collector (Cleaner) is in operation!
やっとGCが付くのか。

>>720
全然嬉しくない。
VMware使えば動きますよ、と言われているような気分になる・・・

grub2のファイルシステムサポートが全然な件について

>>723
おまえは全世界に250万の/bootを敵にまわした

>>724
いや、それlegacyだろ。
なんていうか再実装する必要あるんかね? wrapperで何とかできないの? って思うんだけど。

>>725
再実装不要ならlegacy使ってればいいじゃん。

カーネルやFSの内部挙動に詳しくないんだけど、FSの違いで
fsync()の動作(CPU負荷とか割り込み？)に差があるものなの？

現在、ガリガリとログを吐くPGでmultilogでログを記録してる
んだが、ログの切り替え時に短時間PG側が無反応になって
しまうんだよね…

currentを、@(tai64日付).sに書き換えているタイミングで、
fsync()が呼ばれているからなんだろうけど、さすがに呼ばない
わけにはいかんだろうが、その時カーネルが入出力を待ちに
してるみたいな動作をしてるんだけど、これってカーネルとか
VFSの仕様？FSごとに動作が違ったりするもの？

現在はext3でやってるんだけど、とりあえずtmpfsを検討中です。
あと、ディスクはmegaraidのSCSI-RAIDなのでそんなに遅くない
はずなんですが。

multilog使う位なのに、tmpfsですか？

renameは重い操作だからね。
PGが無反応って、renameのせいでディスクの書きだし待ちとかしてるんじゃないの？

apache付属のrotatelogs使ってログとってみたらどうよ？
rename使わねーから速くなんじゃねーか？

>>728
renameはやっぱり重いのね。

multilogはdaemon-toolでサービス監視してるから
使ってるだけなんだけど、splogger+syslog-ngとか
のパターンも検討中。

tmpfsは、一定時間でログを他の鯖に送出する方向
で考えてますた。

>>729
なるほど、rotatelogsか。
ちょっと調べてみるよ。

なんのために互換性持たせてるんだかわからないext4はあれからどうなった

なんかさー ext3 も xfs も、これ駄目すぎだろっていうバグみつけても、
みんな報告しないもんなのかなー。

負荷テストやってソースコード追ってバグ突き止めて、こりゃ酷いってのがあっても、
どこに投げればいいか分からないとか英語書けないとか報告は書けても議論できないとか、
んで自分のところだけ治して使っておしまい、ってなSEがちらほらいるんだけどー。

>732
だめだなその会社
大手なら投げる担当部署があったりするよ

>>732
そのSEさんは、修正したものを自社内のみで使っているんだよな。
お客に納品した場合は、ソースも公開してるんだよな。
偉いなあ。

突然の書き込み失礼致します。
Windows　MeにてファイルシステムをFAT32→NTFSへの変換を行いたいのですがどのような手法にて
返還すればよいでしょう？当方PCにてconsertコマンド実行を実施しましたがコマンドが実行できません…
知識不足で申し訳ありません…どうか解決法のご教示を宜しくお願いします！

>>735
NTFSは2000/XP/VistaなどNT系列のOSでないと使えない。
よってWindowsMeではできない。

>>735
Windows MeはNTFSに対応していません。
以上。

板違いな質問に真面目に回答するおまいらに感動

いまだにMeって相当ﾏｿﾞだな

>>732
redhatやkernelのbugzillaに突っ込んでおくと、
運がいいと誰かコーディネートしてくれるよ。

>>734
どんなとこでもそれが普通でしょ
まさかGPLものなのにソースつけないで納品してるのか？

えー、それはマズい
M$みたいな真似すんなよw

GPLへの誤解はHIVへの誤解とよく似てる

>>735
まあ本題は>>736-737-のいう通りなのだが、
コマンドは

convert

だろ

convertはエッチな画像を加工するのに使うんだよ

>>738
板違いではないかもしれない。
FAT32→NTFSにして、Linuxで使いたい、と。

わざわざNTFSで使うのはMじゃね？

おれは <M> じゃなくて <*> だが。

汚いカーネルコンフィグオプションだなあ

>>748
help読んで、あえてそうしてるなら問題ない

fuseで使えばいいのに…。

NFSについて教えて下さい。

mount -t nfs xxx.xxx.xxx.xxx:/export /mnt/nfs　等でマウント後、

NFSサーバー側のサービスを停止。

クライアント側で、 ls /mnt/nfs などでマウントポイントにアクセスすると返ってきません。

タイムアウトの設定はどこを見ればいいんでしょうか？

また、サーバー側のNFSサービスが停止したことを知る良い方法はないでしょうか？

man nfs

Ubuntu 7.04 で NFS鯖立てるとなぜか、クライアントともどもフリーズする。

クライアントはFedora6でもUbuntuでもどちらでもフリーズするから
鯖側の問題だと思うのだが。

Hans Reiserが、8月28日まで陪審員選出が行われない事に同意した。
陪審員の選出に1ヶ月はかかると見られるため
実質、9月下旬〜10月上旬まで公判延期の見込み。



どうなってんだ一体？

信者のほとぼりが冷めるまでHansを開発の場から隔離するのが目的だから。
このままのらりくらりと延期を繰り返すよ。

Hansいなくなったら、もうしばらくはLinuxのFSはダメなままかな。

ハンスといえば、ダイハード

ダイハードの方はもうすぐ4.0リリースだね。

いや、Linusは、ZFSに食指を動かしている
extもreiserも全部ほっぽりだして、新しいファイルシステム実装に
ごそーっと入れ替えるとかそういうのもありかも。

そこで、2.9カーネルのスタートですよ。(完全妄想)

>757
Hansいたって同じだったじゃん

ZFSが主流になったとしても、VFSは上位層で動いているわけ?

ここでよくわかってないアホの登場よ。

VFSなしでZFSはいいが、何処かでVFSと整合性とらないと仕組みの上では困らないのかな。

とかいうならreiser4嫁言われそうだが。

はあーーーーーーんす　かんばーーーーーっく

Hansは VFSを使わないようにReiserを実装したかったわけだが...

[次世代] ZFS Part2 [ﾌｧｲﾙｼｽﾃﾑ]
http://pc11.2ch.net/test/read.cgi/unix/1181716111/

レベル低い話したいなら、こちでやってくれ

>>766
>レベル低い話したいなら、こちでやってくれ
は？



大して変わんねーじゃん

766は技術的なことがまったくわからないくせに、なぜかVFSをけなされると湧いて出てくる、
いつものアレでしょ。

技術的な話してないのに、よく言うぜw

次にお前は、いつもの人、乙 という。

実績のないファイルシステムなど、クソの役にもたたないと
現場を知ってる俺から一言

役に立つのかもしれないが、役に立つことや信頼できることを客に保証できないものは使えない、
といった方が正確かな。

そっちのが適切だな
大変なんだよね、売り込むの

2chだけで、妄想の世界に浸ってれば楽でいいやね

業務ではファイルシステムを売り込もうと思ったことすらないな。
みんなext3（ELILOがFATを要求することはあるが）
(ストレージが特殊なLog Structuredなファイルシステムを使うことがあるがまあおいといて)

最初はLinux自体だって業務で使うとは信じられない時代があったんだから。
いずれ個人的にお気に入りのファイルシステムも業務で売り込める時代がくるよ。

zfsが標準で採用されないとつらにだろうな

業務ではファイルシステムなんて気にしない人がたくさんいますがね。
バックアップがそれなりに取れればいいんですよ。
24時間365日稼動無停止ってシステムはそんなに多くないんです。

実際に導入する前にはテストするんだし自分で確かめてから動かすでしょ？
まさか自分でテストもしないで使えないって言うわけでも無し。

でもVFSのやばさはまだ直らないものか。

それがやばいと思わなければ直ることもない

むしろ「当たらなければどうという事は無い」って態度だと思う。

昼間にあげ

一発だけなら、誤射も知れない

うっ

reiserfs はクソ

*エレベーターがリクエストを勝手に並び替えるのを抑止する手段がない
→2.6では修正
*syncがディスクに書き終わる前に戻ってくる
→未修正
*ディスクが外されているのに書き込み成功になる
→未修正
*ディスク上のキャッシュをフラッシュする方法が無い
→2.6では修正

こんな感じ？

>>785
まずはそれぞれの問題点のソースをだな、

>>785
そもそも2.6にエレベーターは無いだろ。

>>787
I/O schedulerと呼ぶことも多いですが、構造体の名前や linux/block/elevator.c というソースの
名前は同じなので、エレベータと呼ぶのは問題ないですね

reiserだとCFQじゃないスケジューラのほうが良かったりするん？

>>785
一番やばいのは、不意のシャットダウンでFSごと壊して
再起不能になるところではないだろうか?

そういうのを見ていると、NTFSの方が安心。

>>790
現象としてそれが問題なのは分かるけど、そのような現象に至るには
コード上のどこが問題で、どこが解決されているかっていうのが >>785 なのでは。

>>791
うむ
で、実際の問題のほとんどはVFSではなくて、個々のファイルシステムのコードに含まれた
微妙な間違いによって発生しているのも現実。

そのコード指摘しないとわからないんじゃない？

elevator.cには
そんなことが読めるコードはどこにもありませんがw

猿能あげ

>>785
でてこいあげ

いつもの人が大暴れ中

おさるさんの書き逃げ？

それにつけてもRHEL4のext3のひどいことよ。。。。

ソースコード読めない素人はだませても、そうはいかんざきおさるよ

朝っぱからFUDしてる暇あったら、Cくらい勉強したほうがいいんじゃないw
時間は大切にね^^

しかし、こんなもんも読める奴がいないとは
ま、いっか、俺の時間ももったいねえ

elevator=エレベータってだけの話じゃないの？

linuxのVFS、言うほど悪くないけどな。
syncの問題は、linusの言うとおりだと思う。

おまいらbtrfsに興味ないのか？

これか：　http://oss.oracle.com/projects/btrfs/

LWNで読んだが、チェックサム、高速fsck、スナップショット、CoW、など
必要なものはおさえてあるな。

zfsもあるな

btrfsはベターfsなんかな？
それともB-tree fsなんかな？

BiTorrentRelayFileSystem

おまえらに聞いた俺が間違ってた

Linux: Rewriting the Buffer Layer
http://kerneltrap.com/node/8434

>>811
そもそも、お前誰よ？

「俺はLinuxだ」
「そうか、奇遇だな。俺はAlanだ」
「おおこんなところで！俺はAndrewだ」
「俺は田代」
「（全員）誰？」

言いたい事は伝わるが何か違う希ガス

Hans Reiser: Once a Linux Visionary, Now Accused of Murder
http://www.wired.com/techbiz/people/magazine/15-07/ff_hansreiser?currentPage=1

嫁は

>>816
>While he launches into the intricacies of database science, I'm thinking, "Where is the front passenger seat of your car?" He has never explained this.
>It seems a fundamental hole in his defense. But he won't stop talking. When I try to interrupt, he insists I let him finish. It's as if the file system holds all the answers.
なんというか、かんというか。

>>816
どこまでがインタビュー内容／伝聞／フィクションなのか曖昧な記事だな。
わざとそういう不安定感のあるスタイルにしているのだろうけど。

その引用も後のソース中コメントがこの事件を想起させているような
表現につなげるためだし、ちょっとまともな報道・調査というより、評論家が
売らんがための文章をひねり出したような記事だと思った。

実話を元に小説を作りましたー的な。

フィクションなら
>>17-18
で既出だな

こっちのスレはVFSとHans Reiserの話しばっかりになったな。

ZFSスレでネットワークFSの話しになってる。
おもしろそうだが、難しすぎてよく分からない。

>>814

お前、馬鹿？

>>822
良くないスレですね？

タイトルに惹かれてきてみたら・・・。
ソースを読み合って、ディスカッションという場ではなさそうだな。
がっくり

ID.を確認どうぞ。

ですが、二名、以上で書き込みをしていたら、規制されますか？

>>826『追加』
cookie.は2ch.で管理、個人では使い分け出来ないのですが？
それでも、規制できますか？
それに附いては "削除" "規制"関係でどうぞ…
見直した方が良いと思います…

恐らく、手遅れです…

>>824
そうです…　 最近どうもスレのされ方が変なのです。

OLS 2日目：カーネル開発、ファイルシステムについての講演
ttp://www.itmedia.co.jp/enterprise/articles/0707/06/news038_3.html

Ext4も大した機能追加ないねぇー。

基本的にスケーラビリティの改善だけを目指している感じだからなぁ。
新機能が欲しければ他のfs使えって感じ。

会場でExt4用の新しいクールなデフラグを書こうとしている人がいたよ、みたいな話を聞いたことがある。

フラグメンテーションを決して起こさないFSも、起こしてパフォーマンスを劣化させないFSも理論上無いとはわかる。
しかし実際問題フラグメンテーションでの劣化ってそんなに起きていないような気がするんだが。
ファイルの入れ直しで解消を試みても、パフォーマンスに影響しなかった経験が何度か。

だがまぁ、やろうとしていることについて技術的に小難しいことをいろいろ聞いたので、ソースが出てきたらおもしろがれるかも。

>フラグメンテーションを決して起こさないFSも、起こしてパフォーマンスを劣化させないFSも理論上無いとはわかる。
どっちも理論上は可能だと思うが。前者はNILFSが近いんじゃないか?

Windowsのショートカットをシンボリックリンクに見立ててくれるFSって
何かいいのある？

>>833
GCしないLFSなら確かにフラグメンテーションなんて起こさない罠。
HDD使い切ったら、はいお終いだけど。

>>834
Windowsというと、現在はNTFSが（様々なバージョンの）ファイルシステムとして用いられている。

というのは別として。

質問が間違っているのかな。
「LinuxでWindowsのファイルシステムをmountした時に、
ショートカットをシンボリックリンクのように見てくれるソフトウェアはない？」
って聞きたかったのではないか。違うかな？

ショートカットって、特定のアプリケーションのデータファイルだろ。
そりゃ無理だって。

>>836
だいたいそんなかんじ。 でもソフトで出来るの？
ドライバにする必要あると思ってたけど
ユーザランドで出来るならそっちのが安全でいいな

>>837
UMSDOSなんてのがかつてあったんだから
少なくとも不可能じゃないとｵﾓﾀ

findで探してシンボリックリンクに付け替えた方が早そうだ

NTFSは危ないのでFATでおながいします

>>839
ショートカットってWindowsファイルシステム内でのソフトリンク
("C:\Temp\hogehoge" から "C:\Windows\Hogehoge" へのリンクなど)なので、
Windowsの設定情報まで参照しないかぎり意味を為さないだろう。

>>842
mount -o drive=C:/mnt/c,D:/mnt/d とかサポートすればいいんでない？

ディスクへのwaitio が高いときに、そのディスクへのopenシステムコールが何十秒も返ってこないことがあります。
処理キューみたいなものがあって、それがいっぱいになっていてopenを受け付けてくれない印象なのですが、その状態を確認する方法はないのでしょうか？

場違いなのかも知れないですけど、ファイル交換ソフトで落としたやつから
静岡県警からの重要なお知らせってやつがでてPCいかれたんですけど
ただのウイルス？

それがどうファイルシステムと関係しているのか小一時間問い詰めたい。

>>844
まずは特定のバージョンのバグかどうか確認したら？

それから、I/Oスケジューラを変更してみるとか、
dirty_rationを変えるとか。
I/Oの確認なら /sys/block/(dev)/queue/ とか。

目欄は気にするな。

Linux Foundation Japan Symposium（1）──Linuxカーネル天気予報
http://opentechpress.jp/opensource/07/07/11/0837228.shtml

btrfs試してみたらこれ、まだほとんど何もできないのね。
まぁ今後に期待

カーネル詳解とか読んでみたけど、VFSってカーネル内の至る所で
かなり広範囲に使われてるから、そう簡単に斬新とか無理そうね。
メジャーバージョンアップのときぐらいしか変更できなさそうな予感。

>>847
ありがとうございます。
kernel2.4なのでI/Oスケジュールの変更ができませんでした。
その後、いろいろ調べたところ
/test (/dev/sda1) へのｗａｉｔｉｏが高いときに、（激しくwrite中)
open(/dev/sda1) は待たされますが、
open(/ｔｅｓｔ/hoge.txt) は待たされないことがわかりました。
ｃｌｏｓｅも同様です。
writeが完了しないと、open,closeできないんでしょうか？

おまいら頭の隅に残しておけ。
ttp://www.ussg.iu.edu/hypermail/linux/kernel/0707.3/2940.html

あれまぁ

マジ？
5年くらい使うつもりの家のサーバjfsにしちゃったお（　＾ω＾）

マジ？
Web+DBのWebアプリケーション鯖をJFSで構築しちゃったお（　＾ω＾）


・・・でももうその会社辞めちゃったからどうでもいいお（；^ω^）

gentooデスクトップ用途の環境で、/をJFSで約一年使ってるが
FSが原因とおぼしきクラッシュ、速度低下などは見られないっす。
安定状態。

JFSには興味はあるんだが、dumpがないのがちょっと悲しいな。
といってもこの知識は昔の話なんですが、今はどうなんでしょう…

xfsのdumpは形式が違ってるのが悲しい。見てみればだいたいわかるんでどうにかなることは間違いないんだけどね。

>>853
の中で言及している速度低下についての話題元はたぶんこれ。
ttp://osdir.com/ml/file-systems.jfs.general/2007-01/msg00024.html

いきなり、ここのスレで叩かれているJFSだが、今まではFSの論争にも
入れてもらえなかったことを考えると大きな進歩だよな。

ぇ、これで叩かれてんの?

>>858
dumpは必要だね。
ファイル数が多いときにバックアップが速くなったりするから。

cfdiskなどでCHSを書き換えることが出来ますが
この情報はどこに格納されるのでしょうか

>>863
パーティションテーブル

DOS/V機なMS-DOSの場合
http://www.ata-atapi.com/hiwtab.htm#T7

PowerPCなMacの場合
http://developer.apple.com/documentation/mac/Devices/Devices-121.html#MARKER-2-27

前スレの300が詳しく解析してるよ。

>>861
いや、むしろ俺以外に使っている人がいてよかったなぁ、という気分に浸ってる

>>863
パーティションの区切りからCHSを推測するってこと？

>>866
ジオメトリを指定しても、cfdisk後のCHSが保存されるだけだと思っている
違ったら訂正をヨロ

Linux: Replacing atime With relatime
http://kerneltrap.org/node/14148

なんか,reiserfs3で8TB+のパッチが公開されている
って話を聞いたけど、どうなんだろ。
reiserfs3ってBKL下で動いているから
最近の多コアCPUやCFSの恩恵を受けられないし、
死にゆくfsなのか。

>>869
>>reiserfs3ってBKL下で動いているから
これってどこに書いてありました？

見た感じだとdirect IOとxattrとjournalの操作の時にlock_kernel()使ってるようですが、
direct IOやxattrは滅多に使いませんし、journalの操作は普通に1スレッドだけでやるものだと
思いますので、そんなに問題ないかと思います。

>>870
ジャーナルの操作を１スレッドでやるのとBKLにどういう関係が？

resize2fs で /dev/vg00/lv00 を小さくしようとしたら、
最初に e2fsck -f /dev/vg00/lv00 やってくれとのメッセージ。
いまやってますが、これってどういう条件で出るんだろう？

>>872
ソース嫁

ソースより先にドキュメント嫁よ
ソースなんて正しいわけ無いんだから

プログラムは書いたとおりに動く

ただし意図した動作であるとは限らない

コンパイラやインタープリタにバグがなく、宇宙のマジカルパワーも無ければな。

そんなことよりプリキュア観ようぜ
http://www.nicovideo.jp/watch/sm1290

マウントするとき、そのディレクトリのパーミッションをついでに指定
したいんだけどどうやって指定すればいいの？

mount /hoge
chmod a+rw /hoge
って毎回書くのあほらしいというか、こんなのどうにかしてfstabに書きたい

vfatの話なら mount -t vfat -o umask=

>>880
いや、ext2とかなんだけどね

じゃあmode=

>>882
そんなオプション無かったよ

>883
一応カーネルソースのドキュメントも見てみたけど、
確かにext{2,3}にはそういうオプションは無いみたいだね。
毎回設定するしか無いね。

ext2だと普通パーミッション保持されない？

chmod a+rw /hoge/.

845＞
私も場違いでスミマセンが。
そのウイルスらしきものにやられて、ＰＣ内のファイルが
ランダムにbmpファイルに上書きされました。
プログラムファイルも...

拡張子は間違いなくaviだった上に、クロスチェックかけたのに。

ﾌﾟｹﾞﾗ

ｹﾞﾗﾌﾟ

ジャーナリング宣言。してない頃だよ

ファイルシステムには2系統ある。

UNIX型とTRON型だ。

TRONのファイルシステムは非常にユニーク。

ニコニコ動画(RC)‐プロジェクトX　挑戦者たち　
第113回「家電革命 トロンの衝撃」
http://www.nicovideo.jp/watch/sm526580

>>891
TRON型？ふざけんなって。

Plan9みたいなものか

＞Toward the end, Chris was asked whether performance slows down when the disk gets full.
＞The answer was "no" because the system crashes instead.
＞That's a good reminder that Btrfs remains an early-stage development

Linuxの暗号化ファイルシステムで一番メジャーなのって何？

dm-crypt

B-TRONの体験版・・・(超漢字のご先祖)

1B/V3体験版のご案内
http://www.personal-media.co.jp/tron/1bv3_taiken.html
ftp://ftp.personal-media.co.jp/pub/1b/p971212.exe

1BV3体験版
http://tat.soga.in/btron/modules/bwiki/index.php?OS%2F1BV3%C2%CE%B8%B3%C8%C7
「超漢字」を体験させてほしい
http://homepage1.nifty.com/isdknit/_tqFOnLE.html

オープンギャラリー:1B/V3の環境
http://www.ne.jp/asahi/open/gallery/1bv3/1bv3.htm

オープンギャラリー：プラットフォームコーナ
http://www.ne.jp/asahi/open/gallery/platform.htm

reiser fsをはじめて使ってみたが、速攻でext3に戻した
lsしたら、レスポンスなくてフリーズしたかと思った
SAMBAでWindowsからアクセスしたらWindows固まるし

何この釣りFS

今ext3以外で使うとしたらxfsだろ

dir_index....

>>898
カーネル何？

>>898
メモリどんくらい積んでる?

reiser厨がいくら騒いでもreiserfsは安定しないのだった

ハンスはまだ拷問されてんのか？

>>904
タリバンに捕まって、改宗を強要されています。

　　　　　　　　　　_Y_
　 　 　 　 　 　 ｒ'｡∧｡ｙ.
　　　　　　　　　ゝ∨ノ　　　　　　　ハンスが　　　 　 　 　　　 　 　　　 ,,,ｨf...,,,__
　　　　　　　　　 ）~~（ 　 　 　 　 　　 臭い飯を喰ってる間に　　 ,.∠/ﾞ`'''t-nヾ￣"'''=ー-.....,,,
　　　　　　　　　,i　　 i, 　 　 　 　 　 　　　　　　　　　　　　　,z'"　　　￣￣　／nﾞﾞ''''ー--...
　　　　　　　　 ,ｉ>　　 <ｉ 　 　 xfs はどんどん普及し　 　 r”^ヽ 　　　　　く:::::|::|:::〔〕〔〕
　　　　　　　　 ｉ>　　　<ｉ. 　 　 ていく・・・・・・。　　　　　　入_,..ﾉ ℃ 　　　　￣U￣＿二ﾆ＝
`=.,,ｰ- ...,,,__　 |,ｒ'''"7ヽ､|　 __,,,... -ｰ,,.=' 　 　 　 　 　　　　>ーｚ-,,,...--,‐,‐;;:'''""~
　　~''':x.,,　 ~"|{ G ゝG }|"~　 ,,z:''" 　 　 　 　 　 　 　 　 　　　 ＿＿＿
　　　　　 ~"'=| ゝ､.3 _ノ |=''"~ 　 　 　＜ー＜> 　　　　　　　　／　　l￣￣＼
　　　　　　　 .|）) 　　　(（| 　 　　　　　/￣￣ﾞｉ;:､ 　　　　　「￣￣￣￣|￣|￣￣￣＼
　　　　　　　　　　　　　))| 　 　 　 ｒ'´￣「中]￣｀ヾv､　　　`-◎──────◎一'
　　　 　　　　　　　　　　　　　　　├―┤＝├―┤　|li:,
　　　　　　　　　　　　　　　　　　　|「￣ |ｉ￣ｉ|「.//||「ｌn|:;
　　　　　　　　　　　　　　　　　　　||//__|Ｌ_」||＿_.||ｌ」u|:;
　　　　　　　　　　　　　　　　　　　|ニ⊃|　　|⊂ニ| || ,|/
　　　　　　　　　　　　　　　　　　　|＿. └ｰ┘ .＿| ||/
　　　　　　　　　　　　　　　　　　　ﾍ　「￣￣￣|　/

確かにある意味タリバンだな

しかし、紆余曲折あって、ハンス・ライザーはファイルシステムの設計者としては、
世界一有名なんじゃないか？

「悪名高い」では。

Reiserはコードの管理主としての立場ファイルシステムの命名権も譲るとかいう話が出てなかったっけ？
名実ともにReiserの名はOSS界から消えるのか…。

フルキャストファイルシステムとか
スカイマークファイルシステムとか
Yahoo BBファイルシステムとか

>>910
フルキャストfsは途中で命名件返上だな。

なにその街中で無料で配ってるFS

電車の中に置き去りにされたCD-Rに入っているfs

>>901
2.6.16

>>902
512MB

パーティションは500GBのHDDを丸ごと１つ

>2.6.16
何その太古のカーネル

>>913
あーあれな

>>915
VINEなもんで。
安定性重視のため自分で入れ替えはしない。

>>917
BTS no?

>>918
わかりやすい日本語でお願いします

>>919
898の問題は
http://bts.vinelinux.org/
の何処に登録されていますか？
登録されていないのなら、あなたの所だけの問題なので
まずは自分の環境を見直しましょう。

目的はreiserfsを使うことではないんだがな

とりあえず、ID:NEgFbuDzの頭がとんでもなく悪いって事はわかった。

悪くても狂ってるよりはマシかも

悪くて狂ってるといいたいのかもよ？

JFSを30日間試してみた
http://opentechpress.jp/developer/article.pl?sid=07/09/19/016221

＞30日間あれこれやってみた結果、私はJFSを高く信頼するに至り、
＞安心して自分のデータを任せている。

そして2ヶ月めに入った途端にシステムが固まって後悔する事になる。
俺も使ってみたがJFSはまだ実用には耐えないというのが感想だ。

こちらはなんとなく/をJFSにしてもう一年だが
FS由来とおぼしき何の問題もない。

>>926
その障害はどこのBTSにファイルされていますか？

壊れる壊れる騒いでたキチガイと一緒くたにされちゃかなわんから
安定度については置いとくとしても、性能悪すぎだろJFS？

>>929
定量的にお願いします。

>>929
性能がいいという印象はないね。
使用、半年くらいだけど。
ただ、まあ別にカリカリの性能を求めている訳だから今のでいいかな。
>>930
定量的に判断する材料はどういうのがいいかな。
あまり激しくないベンチとかなら家ので取ってもいいよ。

http://linuxgazette.net/102/piszcz.html
を見るとJFSってベンチマークの数字はいいのに
実際に使ってみるとはっきり遅いと感じる。
大量ファイルのtouchなんてこっちの手元でやるとXFSの倍ぐらいかかる。

>>932
リンク先のテストでは、大量(１万)ファイルのtouchに
xfsとjfsで10%も違わないように見えますがねぇ。

>>932
というわけで、このスレの>>853辺りから読んでみ。

>>925
＞JFSはiノードに対して動的にディスク領域を割り当て、必要がなくなればその領域を解放する。
＞そのため小さなファイルが数多くある場合にも、iノードの数が不足することはない。
＞すでにカーネル内に統合済のファイルシステムのうち、この機能を持つファイルシステムは、

＞私が知る限りはJFSだけだ。
　　( 　ﾟдﾟ)　
＿(__つ/￣￣￣/＿
　　＼/　　　　/

　　( ﾟдﾟ )
＿(__つ/￣￣￣/＿
　　＼/　　　　/

>>935
＞私が知る限り
って書いてあるから問題ない

>>936
問題がどうとかじゃなく、満天下に恥を（不勉強ぶりを）さらしたって事じゃね？

(･∀･)

vxfs最高でつ

メールサーバ（maildir形式)で2000人程度扱うなら、
どのファイルシステムがオススメ？

>>940
NFSでexportして使うんじゃないんだよね？

reiserfs で良いのでは？
こまいファイル扱うの得意だそうだし。

>>942
先が無いFSを誰が使うというのか

自力でテスト、検証ができないならext3もreiserfsもxfsも違いが無い。
メールサーバーならカーネルのバージョンをガンガン上げるワケもないから
将来性を気にする必要は殆ど無い。

FSに固執しちゃうおとこのひとって。。。

データの容量も考えると、
NFSにて運用も考える場合もあるかと思います。
内蔵とNFSで、こういう場合、
ファイルシステムを使い分ける必要がありますか？
OSはRedHat Enterprise Linux 5です。
内蔵ならreiserfsでもいいですが、
NFSで使うならオススメはありますか？

LinuxでNFSで2000人…
MAXXﾊﾟｰﾌｪｸﾄにs（ry

ま、全員が使っているわけではないので、
その点、利用人数は1/10ぐらいと見てもらえれば・・・。

突発的に負荷がかかった時にサービスを保証できないのが問題なのでは？

200人と考えてもちょっと…

なんで自分で検証しないの？

>>951
これくらいの規模のテストや検証ってどうするんでしょう？

>>949
遅延ぐらいで済めばいいかと思いますが、
止まるという所までなりますか？

>>950
ハードのスペックでカバーできるものでは
ないということですか？

nfsappの費用は出ませんでした・・・。

>>952
JMeter とか使えばいいんじゃね？

とりあえず、動的inodeの選んでおいた方がいいね。
inode数最大にしておいてもいいけど。
POP3/IMAP4サーバによっては、状態キャッシュ持ってたりするから、
そこら辺調べてテストしないと意味無いよ。

メールサーバで機能が閉じてるんだし、遅くなるだけだから、NFSいらんだろ。