/**ファイルシステム総合スレ その 9 **/
■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin
2008/10/26(日) 15:18:36ID:VYy55fXH01 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/
0783login:Penguin
2009/03/05(木) 01:08:15ID:7fO1LWAQ開発のマンパワーが圧倒的に足りないはずのHammerの出来がまあまあとなると、
btrfsも意外と早く使い物になる可能性も。
0784login:Penguin
2009/03/05(木) 01:19:54ID:xpefxS/h0785login:Penguin
2009/03/05(木) 01:43:33ID:4599paQ+もっとも、ファイルシステムは数年使って判断すべきものだが
0786login:Penguin
2009/03/05(木) 01:48:05ID:7EIm6RPkイメージが悪いなんて初耳だ。
0787login:Penguin
2009/03/05(木) 02:09:01ID:Wh17oSuT0788login:Penguin
2009/03/05(木) 02:58:45ID:7fO1LWAQZFS以降のfsとは機能的に世代がはっきり古いのだし。
0789login:Penguin
2009/03/05(木) 06:57:46ID:g88+Gtdaこの辺限定じゃないかい。
0790login:Penguin
2009/03/05(木) 07:11:00ID:5YrGNOjRイメージ悪くないよ。reiserfsから乗り換えるか迷ってるぐらい事前の評判は良い。
0791login:Penguin
2009/03/05(木) 09:43:04ID:owUQEQTkext3やreiser3から乗り換えるとどんなメリットがあるのですか
0792login:Penguin
2009/03/05(木) 09:49:16ID:TLZk7ArGRAID構成でふっとび率がうｐするとかかな
0793login:Penguin
2009/03/05(木) 10:30:28ID:TF4Gm0YNトラブル解決力が付いて一般人から逸脱する
0794login:Penguin
2009/03/05(木) 12:48:41ID:Zv8p611Ghttp://sourceforge.jp/magazine/09/03/03/0242205
0795login:Penguin
2009/03/05(木) 14:50:13ID:rkvz8luGCPU使用率、メモリ使用量も載せて欲しかった。
0796login:Penguin
2009/03/07(土) 11:07:50ID:kQUrBSwzありません
0797login:Penguin
2009/03/07(土) 14:07:41ID:ovs/dmRV・ディスクがちょっと増える（使い方によるが）
（小ファイルが多いと「おっ」と思う程度は増える）
・コマンド打ったときの応答がちょっとよくなる（コマンドによるが）
（小ファイルアクセスと削除速度）
たしかに体感できる差はあるけれど、いまからreiser3する理由に足りるか
どうかはわからない。
0798login:Penguin
2009/03/07(土) 14:09:28ID:ovs/dmRVじゃあいまだと「ありません」でFAだな。
0799login:Penguin
2009/03/07(土) 15:29:43ID:tAQizfuH人柱としての厨二病的満足感を得られます。
このスレでは重要なパラメータだ。
0800login:Penguin
2009/03/07(土) 17:23:00ID:vYvwCjyoぶっちゃけ、そんな事を聞いてくるような奴にはメリットなんて無いと断言できるよ
btrfsは、現在LVMやら、MDやら、メーカ独自のSoftwareRAIDなんかで苦労していて
ZFSみたいなFSがLinuxにもネイティブで実装されないかな、とか思っている人の為のFSだから
大体からして、サブボリュームやFSレベルでのRAID(0|1)に何のメリットも見いだせない人には
メリットなんて皆無に等しい、っていうか、(HDD|SSD)単体で使うならext4やreiserfsの方が速いし
管理も楽だよ
まあ、要約すると物理的、或いはネットワーク内に繋がってる、多数のストレージデバイスを
FSレベルでシンプルに管理したい人の為のFS、それがbtrfs
0801login:Penguin
2009/03/08(日) 00:17:58ID:EkVGHjwO大体今の状況で一般人がbtrfsを使えるようにする事自体が難易度あるしね。カーネルをgitにする事からだから。
安定板リリース出て標準で採用する鳥や2.6.28が選べる鳥なら即使えるのがext4、偉い違いでしょw
0802login:Penguin
2009/03/08(日) 01:52:32ID:MLSinT6Rそんなときに備えての質問です。
NTFSをmountしたんだけど、ファイルを書き込めません。
mount -t ntfs -o rw /dev/sdf1 /mnt
とやってるのに。/mntに何か書こうとしてもPermission deniedになる。
何か忘れてることありますか？
ディストリはGparted0.4.1を使っています。カーネルは2.6.26です。
0803login:Penguin
2009/03/08(日) 01:57:19ID:/9XI2K8nカーネルのntfsドライバなんか使って壊れても知らんぞ？
今、使い込まれているのはFUSEのNTFS-3g
0804802
2009/03/08(日) 02:00:25ID:MLSinT6Rファイルタイプにntfs-3gを指定したら書き込みが出来るようになりました。
＞壊れても知らんぞ？
神に祈りましょう。 ついでにえいしょうしてささやいてくれたら完璧です。
0805login:Penguin
2009/03/08(日) 03:28:03ID:LKSG8od6灰になっても知らんぞ
とだけいっておく。
後は通常運行でドゾー
0806login:Penguin
2009/03/08(日) 11:07:25ID:fNF0jG1C>>639
> ZFSやHammer FSはライセンス上の問題があったし、btrfsは渡りに船だったでしょう。
Hammer FSのライセンス上の問題って何だろ？ BSDライセンスだよね。
「Hammer FS on FUSE」をできないかと妄想し始めてるので気になった。
0807login:Penguin
2009/03/08(日) 11:21:18ID:VNWXyuGy0808login:Penguin
2009/03/08(日) 15:28:07ID:RwK/FmynFspy
http://mytty.org/fspy/
0809login:Penguin
2009/03/09(月) 00:57:57ID:GV2fXnbNinotifyを使った習作みたいなプログラムだね。
このinotifyを知った時には、ファイルに変更があった時にだけ
リモートサーバーに変更差分をpushするようなデーモン出来るかなー
と思ったんだが、やはりみんなそう思うらしくて、
http://code.google.com/p/lsyncd/
に、そういうLive Syncing (Mirror) Daemonがあったりする。
0810login:Penguin
2009/03/10(火) 17:29:28ID:fa0QTRY4バターfsなんて恥ずかしくて使えない。
0811login:Penguin
2009/03/10(火) 17:30:46ID:UYNGOKpb0812login:Penguin
2009/03/10(火) 17:32:43ID:YEjvX6c10813login:Penguin
2009/03/10(火) 17:39:37ID:UYNGOKpb0814login:Penguin
2009/03/10(火) 17:50:40ID:YQAoSTI+>>518
罵倒fsだってさ
0815login:Penguin
2009/03/10(火) 20:07:48ID:yDC62HHMバトーFSだと強そうじゃね？
mke2fs -jv で1Tのハードディスク128Gと872Gに分けてフォーマットしたら
872Gの方が途中でセグメンテーションフォルトが起きました
mke2fsは大容量対応していないんですか?
0816login:Penguin
2009/03/10(火) 20:09:03ID:OxRS8Iom0817login:Penguin
2009/03/10(火) 21:01:28ID:yDC62HHMんじゃ、HDDの初期不良かな
0818login:Penguin
2009/03/11(水) 00:50:24ID:oxPAi9BHxfs
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
0819login:Penguin
2009/03/11(水) 00:51:59ID:Q/Pii7+/0820login:Penguin
2009/03/11(水) 00:52:32ID:oxPAi9BH1TBのフォーマットは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
0821login:Penguin
2009/03/11(水) 00:54:35ID:oxPAi9BH1TBのフォーマットは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
0822login:Penguin
2009/03/11(水) 00:56:16ID:oxPAi9BH1TBのフォーマットは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
0823login:Penguin
2009/03/11(水) 00:57:37ID:RdiNL0Kx0824login:Penguin
2009/03/11(水) 01:07:56ID:Tlh+Q3Rr0825login:Penguin
2009/03/11(水) 01:09:16ID:oxPAi9BHHDDを買い足したついでにテストしてみた。
どのファイルシステムでも小ファイルの処理には
それなりに時間がかかるものなんだな。
(kernelとかだともっと差がつくようだが)
HDDのヘッドが退避しないうちにさっさとテストしたつもりだけど、
どこか手違いがあったのかもしれない。
あるいはWD10EADSが低速回転だから差がつかなかったのかな。
個人的なバックアップ用途としてはxfsも悪くないのかもしれない
0826login:Penguin
2009/03/11(水) 01:38:14ID:Tlh+Q3Rr自分もxfsが細かいファイルにもっと時間が掛かると思ってたw
ちなみに使用しているカーネルのバージョンは?比較的最近のカーネルかな。
0827login:Penguin
2009/03/11(水) 04:29:15ID:KO510Owqどんな形であれ、せっかくテストしてくれているんだから、そんな言い方をしたら失礼だぜ？
0828login:Penguin
2009/03/11(水) 05:15:14ID:Oxh4Vyl/$ tar tjf MPlayer-1.0rc2.tar.bz2 |wc -l
3260
もう一桁多いのを試してほしいような…
つうか一個のディレクトリに大量に置かないと有意な差は見えないと思う。
0829login:Penguin
2009/03/11(水) 08:03:47ID:4YDbCnMJ最も速く、最も安全に使えるファイルシステムです
0830login:Penguin
2009/03/11(水) 08:55:12ID:hFe1ZwTZ0831login:Penguin
2009/03/11(水) 10:59:47ID:4YDbCnMJ真実を述べているだけです
0832login:Penguin
2009/03/11(水) 11:10:01ID:rfDVx5RAでは適切な検証をデータ込で提示してくださいな
スレ住民も条件の選び方から見て自分にあったFSか見極めるでしょうから
「そんなことしなくても自明です」なんて言ったら電波確定
0833login:Penguin
2009/03/11(水) 11:58:04ID:4YDbCnMJこのスレの住人というものです
0834login:Penguin
2009/03/11(水) 12:36:41ID:EgNJdZ2xxfsはgentooでいろいろでかいのビルドするとき遅いと感じる。
0835login:Penguin
2009/03/11(水) 12:47:07ID:KEpL3SfB単一ディレクトリに多数の小ファイルがある場合XFSは速いけど
多数のディレクトリに分散してそれぞれ100個程度の小ファイルがある場合は遅い
後者の場合だとext4のほうが速かった
>>834が遅いって言ってるのも、これだと思う
0836login:Penguin
2009/03/11(水) 18:58:29ID:VdtLCfNFMaildirのメールサーバだから細かいファイルが沢山できる感じだが
特に問題がおきたことはない。
(スパムを全部取っているから数は結構あるな・・・)
引っ越ししたあと、家電が増えてブレーカー落ちやすくなったんだが
バカスカ落としても何もなかったように起動してくる。
偉いぜjfs。
というわけでもっとでかい運用状況聞きたいぜ。
0837login:Penguin
2009/03/11(水) 21:17:13ID:8ECCLmHdしかも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しか使っていないから他は追試出来ないけど、どうせ他のテスト結果もウソっぱちだろう
0838login:Penguin
2009/03/11(水) 23:12:10ID:rkEwTD3Mどのファイルシステムですか？
0839login:Penguin
2009/03/11(水) 23:42:26ID:IrA1hiXPそろそろクラッシュする頃だな
0840login:Penguin
2009/03/12(木) 00:12:25ID:QKWWjyLf大規模システムで使っているＹＯ
小さいファイルが多いなら、おぬぬめ
0841login:Penguin
2009/03/12(木) 05:39:50ID:Uu2UFoYU> 何しろウチの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品より
速くて当たり前のような気がする
0842login:Penguin
2009/03/12(木) 05:59:17ID: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
0843login:Penguin
2009/03/12(木) 08:24:11ID:q/of3Wvv同じくらい時間がかかるんだけどこれは仕様？
ディレクトリエントリ操作するだけなんだから一瞬で終わってしかるべきと
思うんだが・・・
0844login:Penguin
2009/03/12(木) 12:01:29ID:fUWg+Y+2このスレで何度も話題になっているが、
なぜそうなっているのか技術的理由を書ける人が
このスレに現れたことはない。
0845login:Penguin
2009/03/12(木) 12:39:28ID:Gl1f5D2ginodeを忘れないであげてください。
誰かがそのファイル掴んでいる状態で削除すれば、
ディレクトリエントリ消すだけなので一瞬で終わる。
んで、放した瞬間にHDDがカリカリ言い始めるはず。
ということでinode(つうかメタデータ)の更新がすげー遅い。
0846login:Penguin
2009/03/12(木) 13:30:20ID:FK4CPecwつか、このスレの住人って読込み性能にあんまりフォーカスしてないのはなぜ？
0847login:Penguin
2009/03/12(木) 14:45:45ID:uwGP8iQx0848login:Penguin
2009/03/12(木) 20:47:20ID:/5waLCXSTed Tsoが割り込んでクラッシュ時の信頼性をあげるために、わざとそうしていて云々と自説を述べ始めて、
スピーカー困惑。
・・・かと、思ったらそこにさらにLinusが割り込んで、「ふざけるな。オレもふだんイライラしてるんだ。高速化しる！」とか自説を
述べ始めて、二人がプレゼンターそっちのけで議論をつづけるので、セッションにすごい微妙な空気が流れたことが
発表者の中の人がかわいそうすぎます
0849login:Penguin
2009/03/12(木) 21:06:32ID:Q9tPCjh3難しいことを考えずにXFSを使え
0850login:Penguin
2009/03/12(木) 21:15:11ID:8EggFbE/0851login:Penguin
2009/03/12(木) 21:18:29ID:HGzIMQq70852login:Penguin
2009/03/12(木) 21:19:13ID:2VoPly+Y0853login:Penguin
2009/03/12(木) 23:23:22ID:RqJ4/lD8俺は、Linusにつくね。
クラッシュ時の信頼性って言えば許されるとおもってんのか！
だから、ZFSみたいなのが作れないんだよ、と。
0854login:Penguin
2009/03/13(金) 00:29:01ID:AmR0mtlJなっているけどな。おまけに大して性能も出ていないし。
0855login:Penguin
2009/03/13(金) 00:46:56ID:Xd/smKgF0856login:Penguin
2009/03/13(金) 08:53:47ID:QyWnsw8e信頼性重視なの？
0857login:Penguin
2009/03/13(金) 08:55:22ID:QyWnsw8eそうだよなー。
重視してるならReiserの時もあそこまでフレームが大きくならなかっただろうし。
0858login:Penguin
2009/03/13(金) 20:05:10ID:DZg3JUvbttp://www.atmarkit.co.jp/fserver/articles/zfs/01/01.html
0859 ◆IIiDC8JS7w
2009/03/13(金) 21:14:51ID:dlpFGOyHファイルを作成したり、削除したりする時間を測定する
ツールがあるので、使って性能測定してみてください。
redhatの人とか、btrfsの評価で使ってくれている。
ttp://www.spinics.net/lists/linux-btrfs/msg02003.html
↑の最後のほうにコードが載ってます。
0860login:Penguin
2009/03/13(金) 23:39:08ID:x6C+8Djdttp://slashdot.jp/hardware/article.pl?sid=09/03/13/1311252
0861login:Penguin
2009/03/13(金) 23:41:42ID:E6JaImFfXFSでこんなこと起きねえよ
0862login:Penguin
2009/03/13(金) 23:43:52ID:JibFhBsj最近クラッシュしたときに、書き込みしてなかったか？
ファイルサイズが同じでも中身が0で埋まってるファイルが
できてるかもよ。
rsyncでとってたバックアップも死んでるかもwwww
0863login:Penguin
2009/03/14(土) 07:11:48ID:cN9wHfAOhttp://slashdot.jp/hardware/comments.pl?sid=442678&cid=1530766
0864login:Penguin
2009/03/14(土) 10:33:27ID:wTSiQHD4ファイルシステムベンチマークなら、bonnie++が定番。
0865login:Penguin
2009/03/14(土) 10:46:54ID:Fjttua0k>>863の最初の例なんか、
truncate -> writeで、write前に落ちれば
どのジャーナルモードでもデータが消えるんじゃないか?
すでに実行されていたとしても、ジャーナルにあって次マウントしたときにreplayされても。
0866login:Penguin
2009/03/14(土) 11:40:29ID:tgz4pVHK＞ 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")
にすべきだよな
0867login:Penguin
2009/03/14(土) 14:45:40ID:NGZaZVb3最初のはそうだけど、２つ目が問題なんだわ。
xfsはデフォルトでメタデータが先にコミットされるので、その直後に
クラッシュするとファイルシステムの構造的には不整合はないが、その
メタデータが指しているデータは存在しない。
で、xfsはメタデータがゴミデータを指してる状態で開けると、何が
見えるかわからん（古い/etc/passwdのブロックかもしれん）から
セキュリティ的な問題があるよね、ときちんとメタデータが指している
データを最初はゼロクリアした状態にしている（本来のデータがコミット
されたら当然そちらに付け替える）。
ext3等はデフォルトではデータが先にコミットされるので、２での問題は
生じ得ない。一方、xfsの順序は最高性能を発揮するためで、生まれた時代や
背景を考えると致し方ない。
POSIX的にはfsyncしてない限り、どちらの挙動も問題なしで、fsyncしない
アプリ開発者がPOSIXを理解してないというのが結論になる・・・が、
正直２の書き方って、すごい一般的だよね、さあどうしよう、という状況。
hogehoge > fugafuga && fsync fugafuga.new && mv fugafuga.new fugafuga
とか直していくしかない。Ubuntuだっけ？にfsyncコマンドがあるのは
このためだろうと思われる。
もっとも、ドライブキャッシュがあるとfsyncすら保証してくれないので、
さらにバリア張らないととか延々と話が続くんだけど。
0868login:Penguin
2009/03/14(土) 16:28:12ID:l9ZzVqeQ0869login:Penguin
2009/03/14(土) 19:12:33ID:++9sa7SWそうでもないのかな？
0870login:Penguin
2009/03/14(土) 20:08:40ID:6p4fiq3Fいや、あたりまえの技法というコンセンサスはとれていた。ゆえにTed Tsoは仕様どおりだ！とか片意地はらずに直すと言っている。という理解
0871login:Penguin
2009/03/14(土) 20:11:26ID:RgsfJUAA0872login:Penguin
2009/03/14(土) 20:19:32ID:qHb4tz1u一見すると謎仕様すぎて、分かってない連中にボロくそに言われるという。
0873login:Penguin
2009/03/14(土) 20:21:09ID:Fjttua0kなるほど。
>>869もいってるけど、うまく書けたらリネームっていうのは、良くやるやり方なので、
確かにext3の挙動の方が安心できる気がしますね。
結局ext4での書き込みがext3より大幅に遅延するとしても、
ジャーナルに記録されていれば大丈夫な気がするのだが。
0874login:Penguin
2009/03/14(土) 20:23:23ID:2PA7Wxqo0875login:Penguin
2009/03/14(土) 21:23:11ID:Qv+bO9QYFSの破壊を軽減する司法取引だな
0876login:Penguin
2009/03/14(土) 21:57:26ID:wTSiQHD4これからはそういう設計が定番になるんじゃないかな。
Btrfsはどうなんだろ？
0877login:Penguin
2009/03/14(土) 23:59:37ID:1qF/srTZfreeze_fsやunfreeze_fsってwrite_super_lockfsやunlockfsから名前変えたのか？何故に・・
0878login:Penguin
2009/03/15(日) 10:02:11ID:PCGBiEcTこれは現場ではうまくいっていたけど理想的な方法ではないのを、改めているのだと思うぞ。
0879login:Penguin
2009/03/15(日) 10:18:44ID:xjkBDfQMきまぐれ。
0880login:Penguin
2009/03/15(日) 19:42:41ID:PU06YtStstruct struct0001_s {
member0001_t member0001;
member0002_t member0002;
member0003_t member0003;
...
として意味は仕様書と帳票で管理すべし。これならコードで
書く内容も迷うことが少なくていいし、順序がずれたらABI破壊バグと
すぐわかる。
0881login:Penguin
2009/03/15(日) 20:01:52ID:mnUY72EVだったら やめて ちょうだい
本気で好きになりそうだから
あなたの前では きれいでいたいし
0882login:Penguin
2009/03/15(日) 20:31:39ID:ReDUN6OlbtrfsはZFSと同じくCOWで書くから、この問題は起こらない
■ このスレッドは過去ログ倉庫に格納されています