トップページ⇒linux
1001コメント304KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin2008/10/26(日) 15:18:36ID:VYy55fXH
過去スレ
　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/1173530292/
07
08 http://pc11.2ch.net/test/read.cgi/linux/1190788761/
0682login:Penguin2009/02/16(月) 02:52:29ID:ytdqrJnE
kernelのビルドの意味自体わかってないようなヤシは放置しとけ。
06836752009/02/16(月) 20:43:00ID:EIQNz/Hf
>>681
Thx.
その線ですね、また試してみます。
0684login:Penguin2009/02/17(火) 00:25:21ID:9ZUigC3F
―Sun Microsystemsの「ZFS」など、最近はファイルシステムに関する話題がにぎやかだ。
Linuxもこうした動きに加わるつもりがあるか。
http://www.computerworld.jp/topics/osst/135711-2.html

Linusが今後のLinuxファイルシステムの展望を語っています。
ZFS, btrfs, ZFSにも言及しています。
0685login:Penguin2009/02/17(火) 00:57:36ID:yZYtcGBc
> ZFS, btrfs, ZFSにも言及しています。

ZFSのバターサンドですね、わかります
0686login:Penguin2009/02/17(火) 03:37:18ID:cFrq3dg8
btrfs が安定するのは何年後かな…
0687login:Penguin2009/02/17(火) 19:15:07ID:SVUGGIOO
今までXFSをシステム用パーティションに使っていて特に速度は気にならなかった。
mplayerのアーカイブ展開と削除が遅いと思っていたけど、
ファイルサイズが大きいからだと思っていた。

そんなわけで倉庫用の1TB HDDをすべてXFSでフォーマットして
音楽ファイルや動画ファイルをコピーし始めたんだけど...
3GBの動画ファイルはスムーズにコピーできるのに、
3MB*400個の音楽ファイルはものすごく遅い。

散々出てるけど、XFSは小さいファイルの大量処理が遅いのね...
今からフォーマット変更はできないし、親HDDの空き領域は別のファイルで埋まってる。
仕方ないのでもう１台1TBのHDDを買って、EXT4か何かでフォーマットして、
コピーをやり直そうと思う
0688login:Penguin2009/02/17(火) 19:36:50ID:8PuX+ycU
> 3GBの動画ファイルはスムーズにコピーできるのに、
> 3MB*400個の音楽ファイルはものすごく遅い。
> 散々出てるけど、XFSは小さいファイルの大量処理が遅いのね...

3MBのファイルってのは、一般的に大きいファイルの方に分類されるんだけどな
ちなみに小さいファイルってのはクラスタサイズ以下のファイルの事
まあ人によってはiノードに直接収まるサイズのファイルだけを、小さいファイルと言う人もいるけどね

ついでに言っとくと、XFSは小さいファイルの大量処理が遅いんじゃなくて、単純にファイルの大量処理が遅いんだよ
嘘だと思うなら、スムーズにコピー出来ると言っている3GBの動画ファイルを400個用意して試してみれば良い、すぐに分かるよ
0689login:Penguin2009/02/17(火) 21:12:08ID:DTt/hrVg
>>688
LinuxのXFSの場合クラスタサイズは4Kbytes、
inodeのサイズは256bytesであってる?
0690login:Penguin2009/02/17(火) 21:39:46ID:SVUGGIOO
> スムーズにコピー出来ると言っている3GBの動画ファイルを400個用意して試してみれば良い、すぐに分かるよ

1.2TBのファイル操作の結果なんて、どのファイルシステムでもすぐには分からないよ。

> 単純にファイルの大量処理が遅いんだよ

どうなのかな。
3GBぐらいのファイルを10個ほどコピーしたときはスムーズに感じたけど、
mp3の音楽ファイルになってからは激烈に遅く感じた。

Wikipediaを信用するわけではないけど、
http://ja.wikipedia.org/wiki/ジャーナリングファイルシステム
> 一般にディスク上のファイルシステムに書き込まれるデータには、
> データ自体を現す実データ部分とその実データのディスク上の位置、ファイル名/更新日時、
> アクセス権限などの管理情報を現すメタデータ部分の2種類に分類される。

XFSは実データの書き込み自体は非常に速いんだけど、
メタデータの書き込みが非常に遅いのかなと。

3GB*1くらいのファイルだと、
どのファイルシステムでも実データの書き込みには一定の時間がかかる。
そこが十分に速ければ、
メタデータ処理が遅くても十分太刀打ちできそうに思う。

極端な話、こんな感じ。
XFS (実データ書き込み40秒 + メタデータ書き込み1秒) * 400個 = 16400秒
EXT4 (実データ書き込み50秒 + メタデータ書き込み0.1秒) * 400個 = 20040秒

>>688がすでに「3GBの動画ファイルを400個用意して試してみ」たことがあるのなら、
そうなのかなとも思うけど
0691login:Penguin2009/02/17(火) 22:06:20ID:ljmr48rY
最後の2行以外全くの不要
0692login:Penguin2009/02/17(火) 23:18:30ID:ZB4aUO6M
俺は昔倉庫用のやつだけXFSにした時がある。やっぱりCDやDVDのサイズのコピーなど早かったな。
ルートをXFSにしたら読み込みや検索(これは馬鹿っぱや)は早いけど書き込みが若干遅かったし削除は
やたら遅かった・・　確かにコンパイルした後のソースディレクトリみたいな小さいファイル大量の削除とか
特に遅かった。

でもそれ以上に時々カーネルに変なウエイトが掛かってた。ディスクアクセス時に他のアプリの動きが
やたら遅く、下手したらマウスカーソルまで遅くなった。今のカーネルで使えばまた違うんだろうけど
それ以来XFS使ってないな。

大量のコピー時にも色々な作業するからシステム負荷が軽いのがいいな。だから今はext3とjfsの使い分け。
てかだんだんjfsに移行してる。来年になったらバター犬を試してみたい。
0693login:Penguin2009/02/18(水) 08:12:09ID:me5e3SfY
メターデータの処理が遅いって何度も出てるじゃん。
で、ジャーナルを別ディスクにしても遅いんだ。

>>692
たまに引っかかるのは俺もあったけど、
dirtyなデータが一定を超えてフラッシュしてるとかじゃないかな？
0694login:Penguin2009/02/18(水) 08:55:34ID:nWWnq0ds
>>687
あれ？昔聞いた話だと、大量の小さなファイルの扱いは
XFSが得意だと聞いたんだけどな。
Bonnie++でのベンチマーク比較を見れば一目瞭然だろうけど、
どこかにXFSとext3の比較載ってなかったかな・・・。
0695login:Penguin2009/02/18(水) 09:00:45ID:nWWnq0ds
あった。やっぱりXFSの方が早いじゃん。
http://www.miraclelinux.com/asianux/about/data/17.html
0696login:Penguin2009/02/18(水) 09:03:48ID:nWWnq0ds
>>692
そういえばXFSってCPU使用率が高いんだっけ？
他の処理と平行してコピーとかしてれば、
ext3の方がパフォーマンスが良くなるのかもね。
0697login:Penguin2009/02/18(水) 12:32:18ID:pOos/3lo
小さいファイルの処理が速いのは昔からreiserfsと決まってる
0698login:Penguin2009/02/18(水) 18:01:16ID:T4HijFg4
>>692
> でもそれ以上に時々カーネルに変なウエイトが掛かってた。ディスクアクセス時に他のアプリの動きが
> やたら遅く、下手したらマウスカーソルまで遅くなった。今のカーネルで使えばまた違うんだろうけど

これ、ext3で大きなファイルを削除したときにもなるんだけど、
Linuxでは解決が難しい問題なの？
それとも、JFSにするとかbtrfsの成熟を待つかすればいい話なの？
0699login:Penguin2009/02/18(水) 18:05:27ID:nWWnq0ds
>>698
サーバ用OSとして使うことを前提としたカーネル設計or設定だからかもね。
クライアントOSとして使うのなら、UIで引っかかったり待たせたりしないように
ってのを最優先すべきなんだが。

Mac OS Xなんか使ってると、完全にUI優先なのがよく分かる。
その代わりサーバとして使うと問題ありまくりだけど。
0700login:Penguin2009/02/18(水) 18:07:20ID:FGy1ZqOt
>>692
> 時々カーネルに変なウエイトが掛かってた。

たぶんディストリビューションのほうでxfs_fsr(デフラグ)を
定期的にかけてたんだと思う。

俺はCPU使用率は気にならなかったけど、
妙なタイミングでHDDがゴリゴリいいだすのが気になっていた。
xfs_dbでシステム用パーティションのフラグメント状況を調べたら、
1ヶ月以上使っていてパッケージの更新も時々していたにもかかわらず、
ほぼ最適化されていた。

次回はEXT4とReiserFSを試してみるよ。
ReiserFSは以前使ってたけど、開発者が逮捕されて先がないように感じたので使うのをやめていた。
JFSも興味持ったけど、ちょっとマイナーすぎるな。
ZFSは「FUSE経由でZFSを使った場合、出力操作についてはXFSの30〜60％の性能しか得られないようだ」。
http://www.itmedia.co.jp/enterprise/articles/0806/27/news052_2.html

Btrfsはまだ不安だし、
http://wiki.livedoor.jp/linuxfs/d/btrfs
> ディスク容量の85%を越えるまではwriteできる。(100%使いきれない)(2009131現在)
というのが気になる
0701login:Penguin2009/02/18(水) 18:12:56ID:FGy1ZqOt
書いてしまった後であれだけど、
> カーネルに変なウエイト
ってどういうことだろう。
topでみたときのどのプロセスに当たるんだろう。
「システム全体が重くなる」ぐらいに解釈したけど、
それもあやふやな話だしなあ
0702login:Penguin2009/02/18(水) 20:27:15ID:T4HijFg4
>>699
いやそういうことじゃないと思う。
(ext3でのファイル削除中に) GUIが遅くなるという表層のものじゃなくて、I/O全般が
固まってるかのような状態になるから、サーバー用途だろうがあまり頂けない状況だと思うが。
ユーザー空間でCPUサイクルを消費し続けるようなプロセスにはあまり影響が無いようなのだけど。

なぜだか理解してないが、ファイルの削除時には、カーネル空間に突入した際にCPUサイクルを
たくさん使う処理が非常に高い優先度でキューに入っていて、ユーザーが発行している
システムコールがどんどん後回しにされているような感覚を受けるレスポンスなんだよね。
色々検索してみたんだが、どういう理由でこうなるのか、なかなか見つけられない。

>>701
XFSも >>692氏の言うように、妙に「カーネルに処理を奪われてる」ようなスループットの悪さが
出るのを経験してるが、xfs_fsrによるものでじゃないと記憶してる。ext3のように、
「数GBのファイルを消してみたら必ず起こる」といった簡単な条件じゃないみたい。
0703login:Penguin2009/02/18(水) 21:16:05ID:Sto/47zW
>>702
chmod -R のようにジャーナルログが急速に太る処理をやらせると、
swapout不可能なメモリが増えて死ねる。
0704login:Penguin2009/02/18(水) 22:03:29ID:1W/ybCbq
リビングに置いてmp3再生専用のジュークボックスLinuxマシンを組もうと思っていて
静音の為ストレージはSSDにしようかなと思っているのですが
そういう用途でお勧めのFSはなんでしょう？
頻繁に書き込みが発生して寿命が縮むのは嫌ですが
まったくジャーナリングしてくれないのも不安。
無難にext3か。将来が不安なReiser3か。ネタでJFSにするか？
07056922009/02/18(水) 22:07:36ID:IcJM0mVg
皆レストン。

引っかかるってのはまさに>>702が的確に書いている感じ。HDDのスループットが限界に来たとかCPUの処理量を
超えたとかじゃない、ホントにこっちの処理が後回しになってる感じ。

簡単に言うと例えば何かファイルをネットワーク越しに他のマシンへコピーしてる状態で、何か処理をしてその時にCPU
使用率100%になっても大きくネットワークの転送速度って落ちないでしょう。例えばローカルの処理でHDDのスループット
が限界まで来ちゃったとしてもその間の書き込みや読み出しはHDDの能力にしたがって下がっちゃうけどネットワークの
転送は続くでしょう。

自分の言っている引っかかりってのが出たときは、この状況下だとネットワークの転送が0になります。ガクンっと落ちて
完全に0までいく。まさにその時GUIだけじゃなくてI/O全般が固まってる感じ。
0706login:Penguin2009/02/18(水) 22:10:07ID:/cuS6lKA
>>704
その用途でジャーナリングが必要か？
0707login:Penguin2009/02/18(水) 22:13:34ID:T4HijFg4
>>704
そんな使い方ならreadが多くてwriteが殆ど無いだろうから、
事実上Write限界による寿命なんて来ない。
つーか、先に他の部分が故障する。
精神安定剤として、少しでもwriteを減らしたいなら、noatime付けときゃいい。
0708login:Penguin2009/02/18(水) 22:54:01ID:1O7/we0+
あのext3でrmしたときの挙動は何なんだろうね
たとえrm完了がもっと遅くなってもいいから他の処理を邪魔すんなと。
0709login:Penguin2009/02/18(水) 22:56:30ID:1W/ybCbq
>>707
そうですね。
なるべくsyslog吐かないようにとは思っていましたが
noatime付けないと読み出しただけでatime書かれちゃうんでしたか。
Debian Lennyでext4はまだ安定してないかな？
0710login:Penguin2009/02/19(木) 14:55:51ID:z04j4qzs
>>705
つまりXFSの処理のどこかにネットワークやカーソルにも影響するような
ジャイアントロックがあるのかな？
0711login:Penguin2009/02/19(木) 19:39:32ID:Lb+Jk4NK
OCFSってどうなん？
使ってみた報告とか皆無なんだが
0712login:Penguin2009/02/19(木) 19:54:51ID:pOrVrzb0
2.6.28でXFSも速くなるようなのが入ったみたいだけど、速くなった感じがしない。
0713login:Penguin2009/02/19(木) 23:30:57ID:3shEVFBp
WinXPとUbuntuの両方で外付けHDDを使うんだけど、
ファイルシステムはどうするべきだと思う?
NTFSかext3のどちらかだと思うが、
どちらが互換性やパフォーマンスの面で障害が少ないのか?
0714login:Penguin2009/02/19(木) 23:38:13ID:cCKDE498
>>713
なんで人に聞くの？
0715login:Penguin2009/02/19(木) 23:44:45ID:Z25DcziU
>>713
外付けHDDを2つ買って、一個をNTFS、もう一個をext3にすればいい。
0716login:Penguin2009/02/20(金) 00:06:24ID:TEwNW093
>>713
悩むならFATにしとけばいいんでないかと思う。
どっちでも確実に読み書きできるし。
0717login:Penguin2009/02/20(金) 00:51:17ID:hX26sJzO
>>713
パーミッションのことを考えると外付けをext3(かreiserfs)とNTFSの二つのパーティションに区切った方が良い予感。
0718login:Penguin2009/02/20(金) 02:59:22ID:2k7EPZJe
>>711
OCFS2なら正直、イイ！よ。
GFSとかOpenGFSで泣いてた人にとっては神のようなクラスタFSだわ。

性能もかなりまっとう。LVS+SANとかLVS+DRBDを併用すれば簡単に
クラスタシステムを組み上げられるのは最高です。
0719login:Penguin2009/02/20(金) 03:28:53ID:rWFxWd60
外部ログをSSDに乗っけてる人っている？
0720login:Penguin2009/02/20(金) 07:56:35ID:4rQ+o/wl
>>713,716
FATはファイルサイズの上限が低くて(俺には)使いにくかった。
最近のディストリビューションならNTFSで良いと思うけど。
0721login:Penguin2009/02/21(土) 06:48:33ID:diXlsjkP
>>718
おお、そうなのか。正直感想がなさ過ぎて迷ってたw
今度入れてみる
0722login:Penguin2009/02/21(土) 10:02:48ID:Z5GPRaK3
iSCSIがかなり普及しつつあるのに、クラスタ対応fsのほうは全然なんだよねぇ。
0723login:Penguin2009/02/21(土) 10:51:51ID:ol94TBik
>720
一度ハデに壊してから追ってないのでよく知らないが、
NTFSへの書き込みってちゃんと動くようになったの？
0724login:Penguin2009/02/21(土) 16:52:53ID:PagV8OCn
ntfs-3gでとりあえず動いてます。
常用はしていない
0725login:Penguin2009/02/21(土) 17:28:03ID:8YMgGvyx
>>723
>>720ではないけど、
実データが壊れたことは一度もない。
ただLinux側からNTFSパーティションのデータを削除すると
見かけ上データは消えているのに空き領域が増えないことはあった。

例えば50GBのNTFSパーティションで
"du *" が5GBなのに
"df" だと残容量が10GBしかないみたいな。

Windows側でもいろいろ操作していたので
Linux側のせいとも言い切れないんだけど。

結局chkdskを実行したら正しい空き容量に戻った。
そんなことが何回かあったが、
ここ2ヶ月ぐらいは不具合はおきてない。

NTFS-3GはCPU負荷がかなり高いので、そこだけが気になる
0726login:Penguin2009/02/21(土) 19:01:39ID:b/h0+KPy
>>723
カーネル付属のntfsの事は忘れろ
0727login:Penguin2009/02/21(土) 22:28:52ID:ol94TBik
>724-726
さんくす。カーネル外のやつ探すなんて思い付きもしなかった。

ntfs-3gいろいろウオッチしてくる。
カーネルのがアレなせいでずっと>716状態なんだわ。
0728login:Penguin2009/02/22(日) 09:55:44ID:w1DGhqfd
クローズドなNTFSを無理やり実装したものよりも、
オープンなext3をWindowsに移植したものの方が安心できそうなんだけど。

現在の実装だとntfs-3gの方が安定してるの？
0729login:Penguin2009/02/22(日) 10:26:21ID:beSgjmV0
>>728
何と何を比べているの？
0730login:Penguin2009/02/22(日) 10:45:51ID:w1DGhqfd
Ext2IFS と ntfs-3g
0731login:Penguin2009/02/22(日) 12:18:41ID:stOI91h6
ちなみにntfs-3gはかなり安定している。これにはコツがあってLinuxでntfs-3gを使うならなるべくLinuxだけ
それにアクセスするようにしといた方がいい。まる2年ntfs-3gを使っているけどノントラブル。

実際はWINと共用する時も多いだろうからその時の注意点はファイルが閉じきらないうちにOSを終了したとき、
特にWINDOWSの場合は異常終了したWINがLinuxの扱うNTFS領域にアクセスしていた場合必ずまたWINを
起動させて正常終了させとかないとたまに変になる。
0732login:Penguin2009/02/22(日) 12:42:20ID:Yqyj03NJ
LinuxからだけアクセスするNTFSに何の意味があるのか
0733login:Penguin2009/02/22(日) 12:54:50ID:stOI91h6
>>732
いいツッコミだ
0734login:Penguin2009/02/22(日) 16:04:11ID:tLUpC+31
vxfsﾏﾝｾｰ
0735login:Penguin2009/02/22(日) 17:17:32ID:HZYCnhHX
今後は複数のOSで利用する可能性があるものはexFATにしておけって感じになるのかな?
0736login:Penguin2009/02/22(日) 18:48:45ID:U800G2ZZ
LinuxからはNTFSと似たような立ち位置になるんじゃね
多分ポストFATにはならん
0737login:Penguin2009/02/23(月) 00:35:04ID:OM5UFZHj
exFATを見るとどうしてもextra fat(超デブ)が連想されしまう
0738login:Penguin2009/02/23(月) 00:41:09ID:vF6Q5d6I
どれでもそれなりに使えるFSがないのが痛いねぇ
リムーバブルメディアには重要だと思うんだけど
0739login:Penguin2009/02/23(月) 01:09:00ID:AeFg25fy
それこそオープンソースで誰でも使えて機能・安定性ともガチ鉄板
みたいなファイルシステムが、一つは欲しいよねえ…

このさい速度はあまり速くなくても構わんよ
つうかext2/3あたりがどうしてWindowsに移植されたりしないのかと
0740login:Penguin2009/02/23(月) 01:28:37ID:rKbUvqb5
安定性、機能では多分NTFS>ext3だと思うよ。
0741login:Penguin2009/02/23(月) 01:29:56ID:gfs0EQ4Z
>739 つうかext2/3あたりがどうしてWindowsに移植されたりしないのかと

されてるように見えるが > EXT2IFS

0742login:Penguin2009/02/23(月) 01:31:51ID:rKbUvqb5
EXT2IFSってWINから自由にext3に書き込んだり出来るの?
0743login:Penguin2009/02/23(月) 11:15:16ID:KfjF9GSX
一番の問題は、ファイルシステムとパーミッションの関係
0744login:Penguin2009/02/23(月) 14:23:29ID:EloijtZT
ext3ifsってinodeのサイズでうまくいかなかったな、俺の環境では。
inodeのサイズをいじるくらいなら、最近ではLinuxですくなり使えるNTFSの方がいいと思った。
0745login:Penguin2009/02/23(月) 14:26:20ID:i5dtDe8U
exFATにはACL機能が入っている。ところが、Vista SP1では未実装…
0746login:Penguin2009/02/23(月) 15:14:41ID:vF6Q5d6I
ocfsあたりをwindows向けも配布してくればいいのに
実績もあるし、今更出し惜しみするほどのものでもないでしょ
0747login:Penguin2009/02/23(月) 19:00:54ID:N2jXG+uY
ZFSをネイティブに使いたいばかりに
opensolarisに行ってしまって
そのまま帰ってこない人とか出てくるんだろうか。
0748login:Penguin2009/02/23(月) 19:03:07ID:RMEIkcBQ
ZFSはメモリ使用量が・・・
0749login:Penguin2009/02/23(月) 19:59:02ID:KfjF9GSX
バカが使ってから気づくんじゃないか
0750login:Penguin2009/02/23(月) 20:09:14ID:nJBZND0X
>>739
ocfs2
0751login:Penguin2009/02/23(月) 20:19:25ID:+UjaXVVu
>>745
要るか？
それこそNTFS使えよって話じゃね
0752login:Penguin2009/02/23(月) 22:58:42ID:XOl4kN7J
>>751
そりゃHDDやらSSDならそうだろうけど、SDカードとかは
PCよりも、他のところで使うことの方が多いわけで。
0753login:Penguin2009/02/23(月) 23:27:49ID:8h0TqS0R
複数環境で共有すればACLは無い方が都合がいいと思う
0754login:Penguin2009/02/24(火) 00:48:04ID:PNU47U+F
俺もそう思う
別環境で設定したACLなんて無意味だし
0755login:Penguin2009/02/26(木) 22:25:47ID:tsF5+r8X
SDカードとかそんなのはセキュリティなんて有って無いような物だし、中身が消えても大したもんじゃないしね。
0756login:Penguin2009/02/27(金) 06:09:10ID:r6OMqEB7
>実際はWINと共用する時も多いだろうからその時の注意点はファイルが閉じきらないうちにOSを終了したとき、
>特にWINDOWSの場合は異常終了したWINがLinuxの扱うNTFS領域にアクセスしていた場合必ずまたWINを
>起動させて正常終了させとかないとたまに変になる。

その症状、Linux側でマウントするときジャーナルからの復旧が行われてないのでは。
ntfs-3gがジャーナルに対応してないとか。
0757login:Penguin2009/02/27(金) 06:22:16ID:r6OMqEB7
ちょっと調べてきたので書かせてもらうと、
ntfs-3gはジャーナルの書き込みは出来るけど
ジャーナルからの復旧は出来ないらしい。

Linuxだけで使う分には問題ないのは元々ジャーナルを当てにしていないのかもしれない。
WindowsだけでNTFSを使う時に問題ないのはジャーナルにきちんと対応しているから。

Windowsで使っていて正しくアンマウントし損ねた後にntfs-3gでマウントするとおかしくなると。
0758login:Penguin2009/02/27(金) 06:25:33ID:r6OMqEB7
WindowsからもLinuxからも安定して使えるFSとしてUDF2.01はどうだろうか？
各OSとの互換性を重視して一通りの属性を備えている点がポイントだけど
0759login:Penguin2009/02/27(金) 11:36:03ID:rFrhZlUn
>>755
でも、SDカードの大容量化で外付けHDD的に使う人が出てくると、ACL必須。
規格としてはあったほうがいい。
0760login:Penguin2009/02/27(金) 11:41:54ID:QDEi4t0U
FATの上にext3を乗っければいいじゃない。
0761login:Penguin2009/02/27(金) 12:33:13ID:o2Mjgcyd
>>757
なるほど、納得した。

>>759
根本的に何を求めるための物かはっきりしてないとコケるよ。SDカードを外付けHDDとして利用する人が
何を求めるかとか根本的な問題。

ノート型PCでやたら性能良いCPU積んでとっても重くなった上にバッテリーももたないなんてモデルがあった。
性能良いからちょっと高くてもデスクトップでも使えるなんて思って買った。
コケたねw　重くて外に持ち歩く気がしないし直ぐにバッテリ無くなるし。

変に色々機能足して肥大化して安定性や速度に影響でたりしたら結局使えない中途半端FSで消えてくんじゃないかな。
0762login:Penguin2009/02/27(金) 12:35:01ID:Kp8y2VVq
安定性はともかく、速度はそれほど求められないんじゃないの
使いやすいさのほうが重要だね
0763login:Penguin2009/02/27(金) 12:45:05ID:UAfggC9g
>>757
確かに復旧は出来ないんだが、それが必要な状態なら一度Windowsを起動しろとメッセージを出して、
forceオプションをつけない限りマウントさせないと思うのだけれどね……
-o forceしてしまえば
> The logfile  will be unconditionally cleared.
ってことでおかしくなるのもわかるんだが。
0764login:Penguin2009/02/27(金) 20:26:16ID:mryp32nH
>>761
脳みそが１０年前で止まりました
こうですか？
0765login:Penguin2009/02/27(金) 21:03:17ID:o2Mjgcyd
>>764
そうですね
0766login:Penguin2009/02/28(土) 14:12:20ID:czwrTfys
いまどきext3なんて使ってる奴いるの？馬鹿？
0767login:Penguin2009/02/28(土) 14:25:45ID:8lhPQ1EQ
>>766
うちはみんなext3だよ
0768login:Penguin2009/02/28(土) 15:23:19ID:JwdYPYzY
まだext2が残ってたり…
/bootだけど
0769login:Penguin2009/02/28(土) 17:22:43ID:aNwKJdXE
なんとなく、このスレ見ている人はほとんどがext3のような気がする

でもってほとんどが個人のデスクトップ仕様のような気がする

だから最適は自然とext3のような気がする

所詮個人デスクトップのfsを変えてもほとんどが自己満足のような気がする
0770login:Penguin2009/02/28(土) 18:55:55ID:3GTmrs/s
もっと自信を持て
0771login:Penguin2009/03/01(日) 02:52:29ID:K/NlP2TL
「作成日時」が保存できるext4に期待してたりする。
sambaを使ったファイルサーバーにおいて互換性が上がる。
0772login:Penguin2009/03/01(日) 03:49:40ID:gD2Mfu4Y
>>771
Fedoraでext4試してるけど、sambaは使ってないな。
0773login:Penguin2009/03/01(日) 10:11:23ID:66aHl2zT
>>769
reiserfs一択ですが何か？
Mad FS作者Hansカムバーック！！！
0774login:Penguin2009/03/01(日) 14:42:54ID:ssL6mAXv
>>769

＞所詮個人デスクトップのfsを変えてもほとんどが自己満足のよう
＞な気がする

そうです。サーバ用途など特化した物でなければ何でも良い。
0775login:Penguin2009/03/03(火) 21:38:43ID:NKr7FQ8a
こんにちは。

ls -laで出てくるファイルサイズの合計と
df -hで出てくる使用量の値が大きく
違っているって、どんなことが考えられますか？

Debian 5.0（AMD64）上にVMwareServer2.0を
入れて、XFS上に仮想ディスクを「allocate all disk space now」
としてファイルは2G分割で40GByte作りました。

ls -la すると、2Gのファイルが合計40GByte
になるように多数、ファイルができているように
見えるのですが、df -hすると、数MByte（数十だったかな）
程度しか消費していない...

　「allocate all disk space now」やってないと、
　最初は小さいファイルが少しできる
　はずだから、操作ミスはしてないと思うんだが...

で、そこにWindowsをインストールすると、ls -la
で出てくるファイルサイズは変わらないように
見えるんだけど、df -hの表示は、徐々に増える...

空の40Gの仮想ディスクをNTFSフォーマットすると、
4,5時間かかる勢い...（遅...）

同じような環境はいくつあるけど、こういう現象には
はじめて、あった。何が起きているんだ...
0776login:Penguin2009/03/03(火) 21:52:39ID:qXmTBZnJ
sparse file
ls -lsh
07777752009/03/03(火) 22:16:30ID:NKr7FQ8a


ありがとうございます！

「VMware Server の Web UI から、事前割当・2G 分割を指示しても
sparse fileを作りやがります。」という記事も見かけたので、大きい
ファイルをあまり作らなかったため、単に、気づいていなかっただけなのか。
ttp://blog.woremacx.com/2008/11/on-the-way-to-replace-perl.html

　vmware-vdiskmanager使うことも考えます。



0778login:Penguin2009/03/04(水) 10:42:21ID:uN0jlBSw
HANS REISER
Hans Reiser
0779login:Penguin2009/03/04(水) 14:19:22ID:HYrKyMtS
ubuntu9.04でext4で/を作って運用中。ubuntuのカーネルも2.6.28なんだけど、一応最新の安定版2.6.28.7を
kernel.orgより落として自己ビルド。tune2fs -lでこんな感じ。
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery
　　　　　　　　　　　extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash

findコマンドとかばかっぱやになってますね。アプリのmekeなんかも端末を流れる文字の早さが違う。
0780login:Penguin2009/03/04(水) 20:55:03ID:Gpey/fcN
どうせやるならmount optionにjournal_async_commitも付けてみ。
0781login:Penguin2009/03/04(水) 22:35:19ID:PTgFZXPi
>>780
しったか君乙

とりあえずext4/super.c嫁
journal_async_commitはデフォルトで有効だ
0782login:Penguin2009/03/05(木) 00:48:54ID:3fH/NsnT
卑しい揚げ足のとり方だなw
まるで野党だ
■ このスレッドは過去ログ倉庫に格納されています