/**ファイルシステム� ..

---

[2ch|▼Menu]

769:login:Penguin
09/02/28 17:22:43 aNwKJdXE
なんとなく、このスレ見ている人はほとんどがext3のような気がする

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

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

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

770:login:Penguin
09/02/28 18:55:55 3GTmrs/s
もっと自信を持て

771:login:Penguin
09/03/01 02:52:29 K/NlP2TL
「作成日時」が保存できるext4に期待してたりする。
sambaを使ったファイルサーバーにおいて互換性が上がる。


772:login:Penguin
09/03/01 03:49:40 gD2Mfu4Y
>>771
Fedoraでext4試してるけど、sambaは使ってないな。

773:login:Penguin
09/03/01 10:11:23 66aHl2zT
>>769
reiserfs一択ですが何か？
Mad FS作者Hansカムバーック！！！

774:login:Penguin
09/03/01 14:42:54 ssL6mAXv
>>769

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

そうです。サーバ用途など特化した物でなければ何でも良い。


775:login:Penguin
09/03/03 21:38:43 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時間かかる勢い...（遅...）

同じような環境はいくつあるけど、こういう現象には
はじめて、あった。何が起きているんだ...

776:login:Penguin
09/03/03 21:52:39 qXmTBZnJ
sparse file
ls -lsh

777:775
09/03/03 22:16:30 NKr7FQ8a


ありがとうございます！

「VMware Server の Web UI から、事前割当・2G 分割を指示しても
sparse fileを作りやがります。」という記事も見かけたので、大きい
ファイルをあまり作らなかったため、単に、気づいていなかっただけなのか。
URLﾘﾝｸ(blog.woremacx.com)

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





778:login:Penguin
09/03/04 10:42:21 uN0jlBSw
HANS REISER
Hans Reiser

779:login:Penguin
09/03/04 14:19:22 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なんかも端末を流れる文字の早さが違う。

780:login:Penguin
09/03/04 20:55:03 Gpey/fcN
どうせやるならmount optionにjournal_async_commitも付けてみ。

781:login:Penguin
09/03/04 22:35:19 PTgFZXPi
>>780
しったか君乙

とりあえずext4/super.c嫁
journal_async_commitはデフォルトで有効だ

782:login:Penguin
09/03/05 00:48:54 3fH/NsnT
卑しい揚げ足のとり方だなw
まるで野党だ

783:login:Penguin
09/03/05 01:08:15 7fO1LWAQ
Dragonfly BSDのHammer FS、かなり使い物になる模様。
開発のマンパワーが圧倒的に足りないはずのHammerの出来がまあまあとなると、
btrfsも意外と早く使い物になる可能性も。

784:login:Penguin
09/03/05 01:19:54 xpefxS/h
本当にデフォルトでjournal_async_commitが有効なら別に揚げ足じゃないと思うけど

785:login:Penguin
09/03/05 01:43:33 4599paQ+
何故かイメージ悪いが、ext4はかなり使い物になる印象
もっとも、ファイルシステムは数年使って判断すべきものだが

786:login:Penguin
09/03/05 01:48:05 7EIm6RPk
>>785
イメージが悪いなんて初耳だ。

787:login:Penguin
09/03/05 02:09:01 Wh17oSuT
一部でbtrfsまでの腰掛けみたいな評価だからな

788:login:Penguin
09/03/05 02:58:45 7fO1LWAQ
ext3の正統後継者なのは確かだけど、btrfsまでのつなぎなのも確かでしょ。
ZFS以降のfsとは機能的に世代がはっきり古いのだし。

789:login:Penguin
09/03/05 06:57:46 g88+Gtda
>>786
この辺限定じゃないかい。


790:login:Penguin
09/03/05 07:11:00 5YrGNOjR
>>785
イメージ悪くないよ。reiserfsから乗り換えるか迷ってるぐらい事前の評判は良い。

791:login:Penguin
09/03/05 09:43:04 owUQEQTk
私のような一般人にとって
ext3やreiser3から乗り換えるとどんなメリットがあるのですか

792:login:Penguin
09/03/05 09:49:16 TLZk7ArG
>>791
RAID構成でふっとび率がうｐするとかかな

793:login:Penguin
09/03/05 10:30:28 TF4Gm0YN
>>791
トラブル解決力が付いて一般人から逸脱する

794:login:Penguin
09/03/05 12:48:41 Zv8p611G
DragonFly BSD 2.2で実用段階になったHAMMER FSを試す
URLﾘﾝｸ(sourceforge.jp)


795:login:Penguin
09/03/05 14:50:13 rkvz8luG
>>794
CPU使用率、メモリ使用量も載せて欲しかった。

796:login:Penguin
09/03/07 11:07:50 kQUrBSwz
>>791
ありません

797:login:Penguin
09/03/07 14:07:41 ovs/dmRV
一応体感できる差としてはこんなもんか：

・ディスクがちょっと増える（使い方によるが）
　（小ファイルが多いと「おっ」と思う程度は増える）

・コマンド打ったときの応答がちょっとよくなる（コマンドによるが）
　（小ファイルアクセスと削除速度）

たしかに体感できる差はあるけれど、いまからreiser3する理由に足りるか
どうかはわからない。

798:login:Penguin
09/03/07 14:09:28 ovs/dmRV
しまった、ext3,reiser3->btrfsへの乗り換えメリットか。
じゃあいまだと「ありません」でFAだな。


799:login:Penguin
09/03/07 15:29:43 tAQizfuH
>>791
人柱としての厨二病的満足感を得られます。
このスレでは重要なパラメータだ。

800:login:Penguin
09/03/07 17:23:00 vYvwCjyo
ext3,reiserfs → btrfsの乗り換えメリット？
ぶっちゃけ、そんな事を聞いてくるような奴にはメリットなんて無いと断言できるよ

btrfsは、現在LVMやら、MDやら、メーカ独自のSoftwareRAIDなんかで苦労していて
ZFSみたいなFSがLinuxにもネイティブで実装されないかな、とか思っている人の為のFSだから

大体からして、サブボリュームやFSレベルでのRAID(0|1)に何のメリットも見いだせない人には
メリットなんて皆無に等しい、っていうか、(HDD|SSD)単体で使うならext4やreiserfsの方が速いし
管理も楽だよ

まあ、要約すると物理的、或いはネットワーク内に繋がってる、多数のストレージデバイスを
FSレベルでシンプルに管理したい人の為のFS、それがbtrfs

801:login:Penguin
09/03/08 00:17:58 EkVGHjwO
話の流れから見て>>791はext3やreiser3からext4に乗り換えるって言ってるように見えるんだが・・

大体今の状況で一般人がbtrfsを使えるようにする事自体が難易度あるしね。カーネルをgitにする事からだから。
安定板リリース出て標準で採用する鳥や2.6.28が選べる鳥なら即使えるのがext4、偉い違いでしょw

802:login:Penguin
09/03/08 01:52:32 MLSinT6R
そして時は流れ、時代の主流はNTFSに。


そんなときに備えての質問です。
NTFSをmountしたんだけど、ファイルを書き込めません。
mount -t ntfs -o rw /dev/sdf1 /mnt
とやってるのに。/mntに何か書こうとしてもPermission deniedになる。
何か忘れてることありますか？

ディストリはGparted0.4.1を使っています。カーネルは2.6.26です。

803:login:Penguin
09/03/08 01:57:19 /9XI2K8n
>>802
カーネルのntfsドライバなんか使って壊れても知らんぞ？
今、使い込まれているのはFUSEのNTFS-3g

804:802
09/03/08 02:00:25 MLSinT6R
ありがとうございます。
ファイルタイプにntfs-3gを指定したら書き込みが出来るようになりました。

＞壊れても知らんぞ？
神に祈りましょう。 ついでにえいしょうしてささやいてくれたら完璧です。

805:login:Penguin
09/03/08 03:28:03 LKSG8od6
>>804
灰になっても知らんぞ

とだけいっておく。
後は通常運行でドゾー

806:login:Penguin
09/03/08 11:07:25 fNF0jG1C
ちょっと古いレスだけど

>>639
> ZFSやHammer FSはライセンス上の問題があったし、btrfsは渡りに船だったでしょう。

Hammer FSのライセンス上の問題って何だろ？ BSDライセンスだよね。

「Hammer FS on FUSE」をできないかと妄想し始めてるので気になった。


807:login:Penguin
09/03/08 11:21:18 VNWXyuGy
そういやSun vs. NetAppってどうなったん

808:login:Penguin
09/03/08 15:28:07 RwK/Fmyn
このスレ的にどうよ？

Fspy
URLﾘﾝｸ(mytty.org)

809:login:Penguin
09/03/09 00:57:57 GV2fXnbN
>>808
inotifyを使った習作みたいなプログラムだね。
このinotifyを知った時には、ファイルに変更があった時にだけ
リモートサーバーに変更差分をpushするようなデーモン出来るかなー
と思ったんだが、やはりみんなそう思うらしくて、
URLﾘﾝｸ(code.google.com)
に、そういうLive Syncing (Mirror) Daemonがあったりする。

810:login:Penguin
09/03/10 17:29:28 fa0QTRY4
btrfsは名前が悪い。絶望的に。

バターfsなんて恥ずかしくて使えない。

811:login:Penguin
09/03/10 17:30:46 UYNGOKpb
バーターって読むんだけど・・・

812:login:Penguin
09/03/10 17:32:43 YEjvX6c1
作者がbutter-fsだって言ってるじゃん

813:login:Penguin
09/03/10 17:39:37 UYNGOKpb
おお、ほんとだ。すまん。

814:login:Penguin
09/03/10 17:50:40 YQAoSTI+
>>810
>>518

罵倒fsだってさ

815:login:Penguin
09/03/10 20:07:48 yDC62HHM
>>814
バトーFSだと強そうじゃね？

mke2fs　-jv　で1Tのハードディスク128Gと872Gに分けてフォーマットしたら
872Gの方が途中でセグメンテーションフォルトが起きました
mke2fsは大容量対応していないんですか?

816:login:Penguin
09/03/10 20:09:03 OxRS8Iom
お前んとこだけだよ

817:login:Penguin
09/03/10 21:01:28 yDC62HHM
>>816
んじゃ、HDDの初期不良かな

818:login:Penguin
09/03/11 00:50:24 oxPAi9BH
HDD: WD10EADS

xfs
1TBのフォーマットは2秒くらいで終わる。

# 大ファイルの操作
1.2Gのファイル4個をコピー
$ time -p cp * /mnt/backup/
real 273.95

コピーした1.2Gのファイル4個を削除
$ time -p rm -f *
real 0.20

# 小ファイルの操作
MPlayerを解凍
$ time -p tar jxf MPlayer-1.0rc2.tar.bz2
real 4.83

解凍したMPlayerを削除
$ time -p rm -rf MPlayer-1.0rc2
real 4.22

# 中ファイルの操作
mp3ファイル556個(1ファイル2-3MB)計1.4Gをコピー
$ time -p cp *.mp3 /mnt/backup/
real 41.64

コピーしたmp3ファイルを削除
$ time -p rm -f *
real 1.46

819:login:Penguin
09/03/11 00:51:59 Q/Pii7+/
三国志ヲタには馬騰fs

820:login:Penguin
09/03/11 00:52:32 oxPAi9BH
ext4
1TBのフォーマットは4-5分かかる。

# 大ファイルの操作
1.2Gのファイル4個をコピー
$ time -p cp * /mnt/backup/
real 273.64

コピーした1.2Gのファイル4個を削除
$ time -p rm -f *
real 0.20

# 小ファイルの操作
MPlayerを解凍
$ time -p tar jxf MPlayer-1.0rc2.tar.bz2
real 5.76

解凍したMPlayerを削除
$ time -p rm -rf MPlayer-1.0rc2
real 6.46

# 中ファイルの操作
mp3ファイル556個(1ファイル2-3MB)計1.4Gをコピー
$ time -p cp *.mp3 /mnt/backup/
real 41.51

コピーしたmp3ファイルを削除
$ time -p rm -f *
real 1.45

821:login:Penguin
09/03/11 00:54:35 oxPAi9BH
reiserfs3
1TBのフォーマットは30秒くらいで終わる。

# 大ファイルの操作
1.2Gのファイル4個をコピー
$ time -p cp * /mnt/backup/
real 283.27

コピーした1.2Gのファイル4個を削除
$ time -p rm -f *
real 0.19

# 小ファイルの操作
MPlayerを解凍
$ time -p tar jxf MPlayer-1.0rc2.tar.bz2
real 4.83

解凍したMPlayerを削除
$ time -p rm -rf MPlayer-1.0rc2
real 4.24

# 中ファイルの操作
mp3ファイル556個(1ファイル2-3MB)計1.4Gをコピー
$ time -p cp *.mp3 /mnt/backup/
real 41.75

コピーしたmp3ファイルを削除
$ time -p rm -f *
real 1.50

822:login:Penguin
09/03/11 00:56:16 oxPAi9BH
jfs
1TBのフォーマットは1秒くらいで終わる。

# 大ファイルの操作
1.2Gのファイル4個をコピー
$ time -p cp * /mnt/backup/
real 280.49

コピーした1.2Gのファイル4個を削除
$ time -p rm -f *
real 0.19

# 小ファイルの操作
MPlayerを解凍
$ time -p tar jxf MPlayer-1.0rc2.tar.bz2
real 5.02

解凍したMPlayerを削除
$ time -p rm -rf MPlayer-1.0rc2
real 4.33

# 中ファイルの操作
mp3ファイル556個(1ファイル2-3MB)計1.4Gをコピー
$ time -p cp *.mp3 /mnt/backup/
real 40.73

コピーしたmp3ファイルを削除
$ time -p rm -f *
real 1.46

823:login:Penguin
09/03/11 00:57:37 RdiNL0Kx
シングルタスクしかしない人ですか？

824:login:Penguin
09/03/11 01:07:56 Tlh+Q3Rr
どれを使っても大差ない感じなのかな。そうなるとシステム負荷が軽いのが良いな。

825:login:Penguin
09/03/11 01:09:16 oxPAi9BH
xfsは小ファイルの処理が非常に遅いと感じていたので、
HDDを買い足したついでにテストしてみた。
どのファイルシステムでも小ファイルの処理には
それなりに時間がかかるものなんだな。
(kernelとかだともっと差がつくようだが)

HDDのヘッドが退避しないうちにさっさとテストしたつもりだけど、
どこか手違いがあったのかもしれない。
あるいはWD10EADSが低速回転だから差がつかなかったのかな。

個人的なバックアップ用途としてはxfsも悪くないのかもしれない

826:login:Penguin
09/03/11 01:38:14 Tlh+Q3Rr
>>825
自分もxfsが細かいファイルにもっと時間が掛かると思ってたw
ちなみに使用しているカーネルのバージョンは?比較的最近のカーネルかな。

827:login:Penguin
09/03/11 04:29:15 KO510Owq
>>823
どんな形であれ、せっかくテストしてくれているんだから、そんな言い方をしたら失礼だぜ？

828:login:Penguin
09/03/11 05:15:14 Oxh4Vyl/
>>825
$ tar tjf MPlayer-1.0rc2.tar.bz2 |wc -l
3260

もう一桁多いのを試してほしいような…
つうか一個のディレクトリに大量に置かないと有意な差は見えないと思う。


829:login:Penguin
09/03/11 08:03:47 4YDbCnMJ
XFSはあらゆる場面において
最も速く、最も安全に使えるファイルシステムです

830:login:Penguin
09/03/11 08:55:12 hFe1ZwTZ
釣るつもりならもっと上手く書けボケ老人

831:login:Penguin
09/03/11 10:59:47 4YDbCnMJ
釣りではありません
真実を述べているだけです

832:login:Penguin
09/03/11 11:10:01 rfDVx5RA
>>831
では適切な検証をデータ込で提示してくださいな
スレ住民も条件の選び方から見て自分にあったFSか見極めるでしょうから

「そんなことしなくても自明です」なんて言ったら電波確定

833:login:Penguin
09/03/11 11:58:04 4YDbCnMJ
何をやってもXFS批判を噴出させるのが
このスレの住人というものです

834:login:Penguin
09/03/11 12:36:41 EgNJdZ2x
普段使うだけならjfs悪くないよ。
xfsはgentooでいろいろでかいのビルドするとき遅いと感じる。

835:login:Penguin
09/03/11 12:47:07 KEpL3SfB
>>825
単一ディレクトリに多数の小ファイルがある場合XFSは速いけど
多数のディレクトリに分散してそれぞれ100個程度の小ファイルがある場合は遅い
後者の場合だとext4のほうが速かった
>>834が遅いって言ってるのも、これだと思う

836:login:Penguin
09/03/11 18:58:29 VdtLCfNF
家庭内的にjfs使い始めてそろそろ2年だが問題ないなぁ。
Maildirのメールサーバだから細かいファイルが沢山できる感じだが
特に問題がおきたことはない。
(スパムを全部取っているから数は結構あるな・・・)

引っ越ししたあと、家電が増えてブレーカー落ちやすくなったんだが
バカスカ落としても何もなかったように起動してくる。
偉いぜjfs。
というわけでもっとでかい運用状況聞きたいぜ。

837:login:Penguin
09/03/11 21:17:13 8ECCLmHd
カーネルの展開が遅いって書かれてたのに、何でMPlayerの展開でテストしてんだか…
しかもHDDの型番はともかく、他はマシン構成はおろか、フォーマット時のオプションすら書かれてないし
テスト結果はかなりウソくさい

何しろウチのML115初代 ＆ AthlonX2 5000+ ＆ 2GB DDR2 × 2 ＆ WD5000AAKS ＆EN8600GT ＆ SoundBlaster Audigy無印って構成のPC上から
X ＆ KDE 4.2.1立ち上げて、その中でkonsoleからsudo emerge texliveしながら、隣のタブでMPlayerのtar玉解凍したって
ウチのext4はそんなにはかからないから

ぶっちゃけ、上記の状態ですら time tar xjf MPlayer-1.0rc2.tar.bz2 なら
real　 　0m3.224s
user　 　0m2.980s
sys　 　 0m0.250s
俺はext2とext4しか使っていないから他は追試出来ないけど、どうせ他のテスト結果もウソっぱちだろう

838:login:Penguin
09/03/11 23:12:10 rkEwTD3M
z/Linuxに向いてるのは
どのファイルシステムですか？

839:login:Penguin
09/03/11 23:42:26 IrA1hiXP
>>836
そろそろクラッシュする頃だな

840:login:Penguin
09/03/12 00:12:25 QKWWjyLf
>>836
大規模システムで使っているＹＯ
小さいファイルが多いなら、おぬぬめ

841:login:Penguin
09/03/12 05:39:50 Uu2UFoYU
>>837
> 何しろウチのML115初代 ＆ AthlonX2 5000+ ＆ 2GB DDR2 × 2 ＆ WD5000AAKS ＆EN8600GT ＆ SoundBlaster Audigy無印って構成のPC上から
> X ＆ KDE 4.2.1立ち上げて、その中でkonsoleからsudo emerge texliveしながら、隣のタブでMPlayerのtar玉解凍したって
> ウチのext4はそんなにはかからないから

フォーマット時のオプションすら書かれてないし
テスト結果はかなりウソくさい。

というのはさておき、

> 他は追試出来ないけど

rm -rf MPlayer-1.0rc2 はできるはず。

あとマシン構成はいらないけど、
(サウンドカードとかグラボとか関係あるのかな)、
WD5000AAKSの場合は新旧プラッタがあるから
そこを書かないとね。
320GB*2プラッタ品で7200rpmだったら、
WD10EADSみたいに3プラッタ5400rpm品より
速くて当たり前のような気がする

842:login:Penguin
09/03/12 05:59:17 Gl1f5D2g
無意味に割り込みかけてくるサウンドカードとか、無駄にバスを占有する
ビデオカードとかだと影響するんでないかい。

ついでに適当な計測結果
Dell INSPIRON 1501 + 2.6.26 + reiser3
ほぼ無負荷
$ time tar xjf MPlayer-1.0rc2.tar.bz2

real 0m6.101s
user 0m4.932s
sys 0m1.124s

$ time rm -rf MPlayer-1.0rc2

real 0m0.756s
user 0m0.008s
sys 0m0.712s


843:login:Penguin
09/03/12 08:24:11 q/of3Wvv
ext3で50GBとかのファイル数個をrmすると、50GBのファイル書くのと
同じくらい時間がかかるんだけどこれは仕様？

ディレクトリエントリ操作するだけなんだから一瞬で終わってしかるべきと
思うんだが・・・

844:login:Penguin
09/03/12 12:01:29 fUWg+Y+2
>>843
このスレで何度も話題になっているが、
なぜそうなっているのか技術的理由を書ける人が
このスレに現れたことはない。


845:login:Penguin
09/03/12 12:39:28 Gl1f5D2g
>>843
inodeを忘れないであげてください。

誰かがそのファイル掴んでいる状態で削除すれば、
ディレクトリエントリ消すだけなので一瞬で終わる。
んで、放した瞬間にHDDがカリカリ言い始めるはず。

ということでinode(つうかメタデータ)の更新がすげー遅い。



846:login:Penguin
09/03/12 13:30:20 FK4CPecw
そりゃbitmap使ってるfsの宿命ですがな。

つか、このスレの住人って読込み性能にあんまりフォーカスしてないのはなぜ？

847:login:Penguin
09/03/12 14:45:45 uwGP8iQx
読み込みは気になったこと無いなぁ。

848:login:Penguin
09/03/12 20:47:20 /5waLCXS
去年のカンファレンスでプレゼンターが削除速度を速くしたくて・・・と話していたら
Ted Tsoが割り込んでクラッシュ時の信頼性をあげるために、わざとそうしていて云々と自説を述べ始めて、
スピーカー困惑。
・・・かと、思ったらそこにさらにLinusが割り込んで、「ふざけるな。オレもふだんイライラしてるんだ。高速化しる！」とか自説を
述べ始めて、二人がプレゼンターそっちのけで議論をつづけるので、セッションにすごい微妙な空気が流れたことが

発表者の中の人がかわいそうすぎます

849:login:Penguin
09/03/12 21:06:32 Q9tPCjh3
何度も言うが
難しいことを考えずにXFSを使え

850:login:Penguin
09/03/12 21:15:11 8EggFbE/
さすがXFS教。言うことが違う。

851:login:Penguin
09/03/12 21:18:29 HGzIMQq7
ここは、btrfsに期待

852:login:Penguin
09/03/12 21:19:13 2VoPly+Y
結論 JFSでまた〜り


853:login:Penguin
09/03/12 23:23:22 RqJ4/lD8
プレゼンターも、突っ込んでやれよ。

俺は、Linusにつくね。
クラッシュ時の信頼性って言えば許されるとおもってんのか！
だから、ZFSみたいなのが作れないんだよ、と。

854:login:Penguin
09/03/13 00:29:01 AmR0mtlJ
信頼性軽視するからLinuxのfsは他OSからportしてきたものでもアレなことに
なっているけどな。おまけに大して性能も出ていないし。

855:login:Penguin
09/03/13 00:46:56 Xd/smKgF
いろんなFSを量産しているのも弊害だよなぁ

856:login:Penguin
09/03/13 08:53:47 QyWnsw8e
>>854
信頼性重視なの？

857:login:Penguin
09/03/13 08:55:22 QyWnsw8e
ごめん。読み違えたw
そうだよなー。
重視してるならReiserの時もあそこまでフレームが大きくならなかっただろうし。

858:login:Penguin
09/03/13 20:05:10 DZg3JUvb
Solaris ZFSの基本的な仕組みを知る
URLﾘﾝｸ(www.atmarkit.co.jp)

859: ◆IIiDC8JS7w
09/03/13 21:14:51 dlpFGOyH
たくさんのファイルを複数のディレクトリに
ファイルを作成したり、削除したりする時間を測定する
ツールがあるので、使って性能測定してみてください。
redhatの人とか、btrfsの評価で使ってくれている。

URLﾘﾝｸ(www.spinics.net)
↑の最後のほうにコードが載ってます。

860:login:Penguin
09/03/13 23:39:08 x6C+8Djd
ext4がXFSライクなデータ消失を起こしたようです。
URLﾘﾝｸ(slashdot.jp)

861:login:Penguin
09/03/13 23:41:42 E6JaImFf
一緒にすんなハゲ
XFSでこんなこと起きねえよ

862:login:Penguin
09/03/13 23:43:52 JibFhBsj
>>861
最近クラッシュしたときに、書き込みしてなかったか？
ファイルサイズが同じでも中身が0で埋まってるファイルが
できてるかもよ。
rsyncでとってたバックアップも死んでるかもwwww

863:login:Penguin
09/03/14 07:11:48 cN9wHfAO
fsのバグでもなんでも無いじゃないか。
URLﾘﾝｸ(slashdot.jp)

864:login:Penguin
09/03/14 10:33:27 wTSiQHD4
>>859
ファイルシステムベンチマークなら、bonnie++が定番。

865:login:Penguin
09/03/14 10:46:54 Fjttua0k
これってext3でも起こるよね。起こりにくいだけで。
>>863の最初の例なんか、
truncate -> writeで、write前に落ちれば
どのジャーナルモードでもデータが消えるんじゃないか?
すでに実行されていたとしても、ジャーナルにあって次マウントしたときにreplayされても。

866:login:Penguin
09/03/14 11:40:29 tgz4pVHK
＞ rename("~/.kde/foo/bar/baz", "~/.kde/foo/bar/baz~") --- this is optional
＞ rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")

は

unlink("~/.kde/foo/bar/baz~")l
link("~/.kde/foo/bar/baz", "~/.kde/foo/bar/baz~")
rename("~/.kde/foo/bar/baz.new", "~/.kde/foo/bar/baz")

にすべきだよな

867:login:Penguin
09/03/14 14:45:40 NGZaZVb3
>>865
最初のはそうだけど、２つ目が問題なんだわ。

xfsはデフォルトでメタデータが先にコミットされるので、その直後に
クラッシュするとファイルシステムの構造的には不整合はないが、その
メタデータが指しているデータは存在しない。

で、xfsはメタデータがゴミデータを指してる状態で開けると、何が
見えるかわからん（古い/etc/passwdのブロックかもしれん）から
セキュリティ的な問題があるよね、ときちんとメタデータが指している
データを最初はゼロクリアした状態にしている（本来のデータがコミット
されたら当然そちらに付け替える）。

ext3等はデフォルトではデータが先にコミットされるので、２での問題は
生じ得ない。一方、xfsの順序は最高性能を発揮するためで、生まれた時代や
背景を考えると致し方ない。

POSIX的にはfsyncしてない限り、どちらの挙動も問題なしで、fsyncしない
アプリ開発者がPOSIXを理解してないというのが結論になる・・・が、
正直２の書き方って、すごい一般的だよね、さあどうしよう、という状況。

　hogehoge > fugafuga && fsync fugafuga.new && mv fugafuga.new fugafuga

とか直していくしかない。Ubuntuだっけ？にfsyncコマンドがあるのは
このためだろうと思われる。

もっとも、ドライブキャッシュがあるとfsyncすら保証してくれないので、
さらにバリア張らないととか延々と話が続くんだけど。

868:login:Penguin
09/03/14 16:28:12 l9ZzVqeQ
blogの翻訳？

869:login:Penguin
09/03/14 19:12:33 ++9sa7SW
一時ファイルに書き込み→名前変更ってのは当たり前の技法だと思ってたけど
そうでもないのかな？

870:login:Penguin
09/03/14 20:08:40 6p4fiq3F
>>869
いや、あたりまえの技法というコンセンサスはとれていた。ゆえにTed Tsoは仕様どおりだ！とか片意地はらずに直すと言っている。という理解

871:login:Penguin
09/03/14 20:11:26 RgsfJUAA
しかしまぁ、仕様通りだから悪くない、と言っても汎用的なFSとしては使えないよなぁ

872:login:Penguin
09/03/14 20:19:32 qHb4tz1u
でもそうやって理想の仕様よりも現実を優先していくとWindowsみたいになるわけだけだが。
一見すると謎仕様すぎて、分かってない連中にボロくそに言われるという。

873:login:Penguin
09/03/14 20:21:09 Fjttua0k
>>867。
なるほど。
>>869もいってるけど、うまく書けたらリネームっていうのは、良くやるやり方なので、
確かにext3の挙動の方が安心できる気がしますね。

結局ext4での書き込みがext3より大幅に遅延するとしても、
ジャーナルに記録されていれば大丈夫な気がするのだが。

874:login:Penguin
09/03/14 20:23:23 2PA7Wxqo
そしてHans Reiser恩赦に

875:login:Penguin
09/03/14 21:23:11 Qv+bO9QY
壊れたメタデータのコミット先を教えるかわりに
FSの破壊を軽減する司法取引だな

876:login:Penguin
09/03/14 21:57:26 wTSiQHD4
ZFSとかFS層の破壊防止を徹底してるから、
これからはそういう設計が定番になるんじゃないかな。

Btrfsはどうなんだろ？

877:login:Penguin
09/03/14 23:59:37 1qF/srTZ
super_operations構造体のメンバ
freeze_fsやunfreeze_fsってwrite_super_lockfsやunlockfsから名前変えたのか？何故に・・

878:login:Penguin
09/03/15 10:02:11 PCGBiEcT
>>872
これは現場ではうまくいっていたけど理想的な方法ではないのを、改めているのだと思うぞ。

879:login:Penguin
09/03/15 10:18:44 xjkBDfQM
>>877
きまぐれ。


880:login:Penguin
09/03/15 19:42:41 PU06YtSt
もう名前変更しなくていいようにメンバは

　struct struct0001_s {
　　member0001_t member0001;
　　member0002_t member0002;
　　member0003_t member0003;
　　...

として意味は仕様書と帳票で管理すべし。これならコードで
書く内容も迷うことが少なくていいし、順序がずれたらABI破壊バグと
すぐわかる。

881:login:Penguin
09/03/15 20:01:52 mnUY72EV
>>879
だったら　やめて　ちょうだい
本気で好きになりそうだから
あなたの前では　きれいでいたいし

882:login:Penguin
09/03/15 20:31:39 ReDUN6Ol
>>876
btrfsはZFSと同じくCOWで書くから、この問題は起こらない

883:login:Penguin
09/03/15 20:34:14 kmO3PCzB
btrfsはなんでaddressingを128bitにしなかったの？ZFSに負けちゃうよ

884:login:Penguin
09/03/15 20:56:32 LgaDmqJ8
>>881
吹いた


885:login:Penguin
09/03/15 22:13:07 VfSmlfyi
デ♥フ♥ラ♥グ

886:login:Penguin
09/03/15 23:37:34 mnUY72EV
>>884
歌詞の一部です　若かった昔を思い出させる
今夜のナンバー　１曲目は
長渕剛　素直
URLﾘﾝｸ(www.youtube.com)

887:login:Penguin
09/03/16 01:59:21 Gwa/wpQE
>>883
btr2fs誕生のフラグです

888:login:Penguin
09/03/16 02:03:51 08WqhxTZ
>>883
アドレスが128bitだとIPv6を連想して不吉だから

889:login:Penguin
09/03/16 15:19:00 fRtMFqd9
マジレスするとVFSが対応していない。

890:login:Penguin
09/03/16 15:31:04 FfCxFL0P
ext3は罪な奴だな
fsyncを徹底すると遅すぎて使い物にならないし
fsyncをしなくても十分安全だから
fsync無しの更新を一般化させてしまった


ext4も、data=orderedがデフォルトで安全なはずなんだけどなぁ
遅延アロケーションはジャーナルのコミットを考慮しない言うのか


891:login:Penguin
09/03/16 16:49:59 TUvh8KP2
extなんとかが最もポピュラーなのはなぜ？
歴史的な理由ですか？

892:login:Penguin
09/03/16 18:13:10 4dJsZZR0
なんだかんだで愛されてるんだよ

893:login:Penguin
09/03/16 18:59:45 XO5/u8kb
殺人よりはマシだからな（ワラ

894:login:Penguin
09/03/16 20:55:40 fRtMFqd9
>>891
そのとおり。
ext2時代は事実上、それしか選択肢がなかった。
ext3時代はredhatが他のFSをサポートしなかった。FSの品質はテスターの数にめっさ依存するので
ディストロの対応重要。

---

最新レス表示

スレッドの検索

類似スレ一覧

話題のニュース

おまかせリスト

▼オプションを表示

レスジャンプ

mixiチェック！

Twitterに投稿

オプション

しおりを挟む

スレッドに書込

スレッドの一覧

暇つぶし2ch

---

5046日前に更新/219 KB
担当:undef