1001コメント272KB

ファイルシステム総合スレその14

■ このスレッドは過去ログ倉庫に格納されています

2012/01/15(日) 16:38:33.83ID:OMF5PJgt

●前スレ
ファイルシステム総合スレその13
http://engawa.2ch.net/test/read.cgi/linux/1311812102/
●関連スレ
ジャーナリングファイルシステム
ttp://hibari.2ch.net/test/read.cgi/unix/979408065/
OpenSolaris/Illumos (OpenIndiana, etc.) 5
http://hibari.2ch.net/test/read.cgi/unix/1285876800/

過去スレ、関連リンクは >>2-10 あたりで。

0607login:Penguin

2012/05/11(金) 08:47:12.97ID:SoMXQdp3

BerkleyDBとかMySQLとかJavaとか不幸にしまくってるじゃん。
ドキュメント方面の予算削られてMySQLの日本語ドキュメントが5.1
までしかないとか、doc.java.comが一時期なくなった(社内でがんばって
くれた人がいて復活した)とかひどい目にあってる。

JavaはGoogleとの訴訟で「APIに著作権を認めろ」とかいってるしな。

0608login:Penguin

2012/05/11(金) 09:12:10.28ID:Rs4s5bBT

オラクルの場合は貢献よりやったことの悪影響の方が多いから
OSSに対して非干渉の企業の方が1000000倍ありがたい。

0609login:Penguin

2012/05/11(金) 10:35:25.35ID:agAAD5md

業突く張りのボラクルですからね

0610login:Penguin

2012/05/11(金) 11:16:56.86ID:sTP/os3g

MSの方がまだマシって思わせる企業があるなんて

0611login:Penguin

2012/05/11(金) 12:44:07.18ID:w0RrmVyz

ZFSの未来はNexentaに頑張ってもらうしかないよね

0612login:Penguin

2012/05/11(金) 13:33:45.09ID:ocx/xIVv

挿入削除機能付きファイルシステム
ファイルに対する挿入および削除を高速に行うことを目的に開発したファイルシステム
http://www.nhk.or.jp/strl/flexible/doc_ext4_mxf.html

0613login:Penguin

2012/05/11(金) 14:15:11.41ID:GH1IWZxy

>>607
Oracleが打ち捨ててくれたおかげで幸せになれたOpenoffice.orgとかあるしな～

0614login:Penguin

2012/05/11(金) 14:56:34.05ID:5z7FqG21

開発者がほとんど逃げ出してから捨てられてのって幸せなんだろうか

0615login:Penguin

2012/05/11(金) 14:59:16.12ID:sTP/os3g

>>612
上流に寄付するなりすればいいのに
半税金で運用している会社のわりに使えないよな

0616login:Penguin

2012/05/11(金) 17:27:06.27ID:zDYdOm03

>>612

受信料を払っていないのでパス

0617login:Penguin

2012/05/11(金) 18:57:00.39ID:QWh07S8U

GPLなものに受信料は関係なかろ。

0618login:Penguin

2012/05/11(金) 20:06:42.05ID:sTP/os3g

>>617
http://www.nhk.or.jp/strl/flexible/Down01.html
NHKがいじった部分は違うよ

0619login:Penguin

2012/05/11(金) 20:09:35.37ID:jkHVDhT6

>>607
あいつらが予算削減したからドキュメントがないんだって・・・
どんだけ無料ユーザー様なんだよ。

世の中金も手も出さない所ばかりな所で、ドキュメント作成までは
カバーできなかったが出したというのに、前の支援者よりレベルが
落ちるだけでボロクソ。誰がそんなコミュニティ支援するんだ？

0620login:Penguin

2012/05/11(金) 20:20:55.68ID:ocx/xIVv

>>618
こいつはGPL2だよ。
http://www.nhk.or.jp/strl/flexible/down_ext4_mxf.html

0621login:Penguin

2012/05/11(金) 21:41:37.63ID:pEam6qOM

Oracleに買収される前にあったものが買収されたら無くなったら呆れるだろ。

0622login:Penguin

2012/05/11(金) 22:24:36.79ID:4yR4l5go

>>613
捨てるなら最初から捨てればよかったのに、さんざん引っ掻き回して
誰も寄り付かなくなってから寄贈とか嫌がらせの最たるものじゃん。

0623login:Penguin

2012/05/12(土) 01:47:50.44ID:KLe6gbzV

v28時点の機能で充分なんで、v30以降クローズドでも文句言わんからv28のコードをBSDかGPLにしてくれんかねｗ＞ZFS

0624login:Penguin

2012/05/12(土) 02:25:05.18ID:jr/vC4EX

ならばApache Licenseにしてやろう

0625login:Penguin

2012/05/12(土) 02:47:00.19ID:dQiISBRz

修正BSDならまだしもGPLはちょっと…

0626login:Penguin

2012/05/12(土) 02:49:12.79ID:AZpPqINZ

GPLにしたらFreeBSDの人たちがキレるだろうな。

0627login:Penguin

2012/05/12(土) 05:39:42.82ID:dQiISBRz

むしろIllumos側とかがやる気無くすだろ

0628login:Penguin

2012/05/12(土) 09:18:19.28ID:tnC/P8Hk

Linuxサーバ構築の仕事をやっているが、
ZFSに対してのあこがれは増すばかり。

自宅のファイルサーバ（CentOS)で使って、良い感じで使えているので、
会社のデスクトップマシンのOS入れ替えのとき、Homeディレクトリを
ZFSに割り当てちゃおう。

0629login:Penguin

2012/05/12(土) 19:13:56.22ID:R4XTgxI9

Oracleアンチスレに成り変わってしまったんやなｗ喜劇やなｗ

0630login:Penguin

2012/05/12(土) 21:06:59.32ID:Ybl2SDjr

>>629
以前のスレでも同様の事情が発生したからね
まぁ、定期的に発生するよくある話

0631login:Penguin

2012/05/12(土) 21:40:52.96ID:WiWzjoLA

最近のファイルシステム事情からするとOracleが叩かれる流れになるのは仕方ないと思うんだが。

0632login:Penguin

2012/05/13(日) 01:47:39.10ID:yRFiDpFg

ZFSクレクレ Btrfsクレクレ

0633login:Penguin

2012/05/13(日) 10:41:05.88ID:6yfJ5u8k

OSクレクレ3日でピーコ完了ｗ

0634login:Penguin

2012/05/14(月) 12:41:38.98ID:0FAxP6SH

zfsをhdd×4のraidz1で運用してる。osはsolaris11
raidの健全性を調べるコマンドって
zpool status
で必要十分なの？

0635login:Penguin

2012/05/17(木) 02:08:12.61ID:zXXpU1HC

>>594
ebayに出品されているのは中古品だろ？
メーカー出荷の新品と比較しちゃダメよ

0636login:Penguin

2012/05/17(木) 09:03:27.03ID:quLDDVor

>634

zpool scrub pool名

でオンラインチェックが出来るらしい。
今試しに動かして見てるけど、IOやCPUの負荷が
かなり大きい。全力で読み書きしてチェックしてる
様子。

scrub実行中にzpool statusを見ると、チェック
の進捗と予想終了時間が判ります。万が一エラーが
起きたら自動修復？されるんでしたっけね。

0637login:Penguin

2012/05/18(金) 02:04:44.50ID:vSGVCWOh

なんだ、ZFSもfsck必要なのか

0638login:Penguin

2012/05/18(金) 09:54:30.02ID:qWj86vXl

>637

他のファイルシステムでは、ファイルの書き込み中の電源OFFとか
カーネルパニックでファイルが壊れることがあるけど、ZFSは
書き込んでからファイルポインタを付け替えるから、ファイルが
壊れる事はない。

scrubはハードウェアの障害によるデータ化けの対策

0639login:Penguin

2012/05/18(金) 10:44:02.27ID:wFUz+ABd

ファイルポインタを付け替えようとしているときに電源が切れたらどうなるの？
とか思ってしまった

0640login:Penguin

2012/05/18(金) 12:56:46.50ID:H+gB5nnv

>>639
…。そう思ったらちょっと考えてみるぐらいしてみたほうがいいな。

0641login:Penguin

2012/05/18(金) 13:17:04.13ID:F39pzlH8

急いでつけかえるから大丈夫！！！１！！

0642login:Penguin

2012/05/18(金) 13:40:42.56ID:dgKtu+BA

考えて分かることなのか

0643login:Penguin

2012/05/18(金) 13:43:58.84ID:5sSa6Sz4

ファイルポインタを付け替える間に電源を切ることは不可能である

0644login:Penguin

2012/05/18(金) 13:52:20.88ID:g3FMqL47

ポインタの付け替え時間 <<<<<<< ファイルの書き込みの時間

ファイルの書き込みの最中に電源が落ちると、ファイルは死んでしまいます。
例えばテキストファイルを書き込み中に電源落ちて半分しか書き込めなかった
とか。ZFSでは元の情報を保持したまま、新規のデータを作成し、書き込みが
完了した後、ポインタを付け替えます。ファイル書き込み中に電源が落ちても
元のファイルは残ります。という事でファイルシステムは論理的には
壊れません。

0645login:Penguin

2012/05/18(金) 14:28:27.99ID:dgKtu+BA

そんなこと誰でも分かってるでしょw

0646login:Penguin

2012/05/18(金) 14:33:27.88ID:XuBoX5Wq

HDDユニット自体が電力を絶たれても
がんばってアトミックに動くようになってる(らしい)からでそ。

0647login:Penguin

2012/05/18(金) 16:43:51.44ID:utn7Luuj

そのためのジャーナルなんだぜ

0648login:Penguin

2012/05/18(金) 16:45:30.78ID:oOjSEvqe

ジャーナルはメタデータしか記録しないので万能ではない
単にファイルシステムのメタデータが壊れないだけ

0649login:Penguin

2012/05/18(金) 16:49:11.21ID:cy1LYrTG

>>648
んなことはない FSによって仕様は違う。

0650login:Penguin

2012/05/18(金) 19:32:32.59ID:qwD1jBDX

ext4は、電源切れた時とか、書き込み後の新しいファイルも
書き込み前の古いファイルも残らない問題があって、
その問題が出る可能性を少なくする修正をしたけど、可能性はあるまんまだよ。

0651login:Penguin

2012/05/19(土) 00:37:17.94ID:5rNSO6UU

電源切れても、アトミックに書けることが保証されてるなら、
どんなサイズのデータも
512byteのファイルに分けて書き込めば、不意の電源切断による
ファイル損失が回避できるってことだね

0652login:Penguin

2012/05/19(土) 00:44:38.79ID:oH+axjjp

アトミックに書けないとしても、ログ追記する形なら書き込み失敗＝前データが有効ということになるので安全な書き込みは保証される。

0653login:Penguin

2012/05/19(土) 01:22:01.37ID:bGawkh/l

>>652
それにプラスして>>641と>>643だから安全なんだよな

0654login:Penguin

2012/05/19(土) 10:07:02.37ID:d/xS1V5P

hdparm -W1で使ってても保証されてる？
FUA発行前の書き込みが中途半端に反映されてる状況。
FS次第？

0655login:Penguin

2012/05/19(土) 19:50:22.13ID:FRys3al+

XFS2まだかよ

0656login:Penguin

2012/05/19(土) 19:53:39.97ID:YxifvVZm

XFSは元々は他OSのFSだしext5の方が良いんじゃね

0657login:Penguin

2012/05/19(土) 19:55:42.67ID:R06bEnk+

電源の話が続いてたけど、HDDって電源とんでも1セクタは自力で書けるような仕組みを持ってるの？

0658login:Penguin

2012/05/19(土) 19:57:05.39ID:d56/CwG2

>>657
それ以前にHDDの内蔵キャッシュメモリ上の内容が揮発する

0659login:Penguin

2012/05/19(土) 20:50:18.22ID:OclJXskD

>>655
kernel 3.2でx86_64の場合は、件のスタック食いつぶしもマシになったとのこと。

kernel 3.2といえば、ext4の16GB制限もなくなっているんだよなぁ。

とはいえ、Redhatのkernelにそれがマージされるのはいつになることやら

0660login:Penguin

2012/05/19(土) 22:13:23.46ID:9MY9nMma

RedHatカーネルに移植されない＝OracleLinuxに取り込まれない
なら別に悪くないかもｗ

0661login:Penguin

2012/05/20(日) 14:48:12.14ID:eP6j5/av

>>657
いまどきのHDDならキャパシタや慣性でアトミックな書き込みになるよう努力してるが絶対の保証はされてないというのが自分の認識。

postgresqlやsqliteのマニュアルでもデフォルトでは信用してなさそうだし。
zfsみたいにfs層でアトミック性が保証されている場合はdb側はそれを信じて動作できる。

0662login:Penguin

2012/05/20(日) 15:11:25.04ID:8YfFWlKc

とあるMLだと大抵HDDメーカーの人とDB側の人が喧嘩してるイメージがある
性能上げる為にメモリにキャッシュしてんのにアトミックじゃないって言われてキレてたりとか
ハード屋からみたら当たり前だし、ソフト屋は分かってて噛みついてんだろって思うｗ

0663login:Penguin

2012/05/20(日) 15:20:18.69ID:YuJ3DDEz

ぶっちゃけUPSいれろで結論出てるけどな

0664login:Penguin

2012/05/20(日) 15:40:45.14ID:8YPwgSyJ

ハード屋は電源無くなりゃなんも出来んって言ってるのに
ソフト屋はack返してんだろって言うからなｗ
ま、どっちも正しいんだがfcの頃ならともかくiSCSみたいのでfsyncでクラスタfsが完璧に補償されるとか思って欲しくないわ

0665login:Penguin

2012/05/20(日) 16:00:28.49ID:p9BF+Jlq

奥なんとかさん。呼んでますよ。

0666login:Penguin

2012/05/20(日) 17:15:21.17ID:HhKMOwRD

え？iSCSIってアトミック動作保証されないの？？
ジャーナルFSにしてても、破損する可能性あるのか

0667login:Penguin

2012/05/20(日) 18:23:12.40ID:uTdrFX86

iSCSI の実装が腐ってるか、クラスタfsの設定が悪くて実装されていないコマンド
呼んでるとかタイムアウト系のパラメータ間違ってるとかじゃねーの？

0668login:Penguin

2012/05/20(日) 23:25:07.01ID:ELQ5/TDV

>>657
http://www.atmarkit.co.jp/flinux/rensai/watch2010/watch03b.html
＞Martin K. Petersen（OracleのLinuxエンジニアで、IDEMAの内部事情に詳しい）は、
＞「もともと512bytesでも保証はなかった。
＞ベンダは努力はしていたが、実際には、例えば書き込みセクタを調整することでホットスポットを分散させたりしてたから、
＞そういう処理が原因でアトミックに処理できなかった。
＞そういう訳で、非揮発性キャッシュ付きのRAIDをみんな使っていたのさ」と説明。
＞これについては、「アトミック書き込み保証問題は、サーバ業界が4KiB論理セクタ長に向かっている理由の1つである」とコメントが付きました。

0669login:Penguin

2012/05/21(月) 08:26:04.95ID:0vaQ/+dW

家のnilfs は、全部ext4に戻しました。長期間使った時のパフォーマンスの著しい低下が我慢できなかった。

0670login:Penguin

2012/05/21(月) 08:52:31.83ID:ibgDvpSH

ところで、linuxの次期FSとして一番有力なのはどれなの？
1)btrfs
2)ZFS
3)ReiserFSもしくはそのフォーク？
4)EXT4もしくはその拡張
5)その他

0671login:Penguin

2012/05/21(月) 09:31:16.61ID:xHaR64QJ

そもそも1セクタ分がアトミックに書き込めることにfs的にどんだけの意義があんのかな。
複数セクタの書き込み単位でアトミックになっていないと整合性が判断できないんであればあまり意味ない気もするし。

0672login:Penguin

2012/05/21(月) 09:54:20.81ID:w3v01jDq

1セクタアトミックに書けるなら
任意の複数セクタをアトミックに書けるようにソフトウェアだけで実装できる

0673login:Penguin

2012/05/21(月) 09:57:25.79ID:PP15/LMj

>>670
1)btrfs→オラクルからはエンジニアが既に去った。
2)ZFS→ケチケチサポートに突入。
3)ReiserFSもしくはそのフォーク？→そんな気配は無い？
4)EXT4もしくはその拡張→結局これだろう。誰かが知恵絞って、多くの人間にたたき上げられてext5とか出るのが想像つきすぎる。
5)その他→ZFSの人が何か作るんじゃないかと個人的には思ってる。

0674login:Penguin

2012/05/21(月) 09:58:33.96ID:PP15/LMj

> 1)btrfs→オラクルからはエンジニアが既に去った。

去ったのはZFSの人か。スマソ。

0675login:Penguin

2012/05/21(月) 10:04:58.51ID:2/Hjj9MT

>>670
4

0676login:Penguin

2012/05/21(月) 10:11:32.22ID:VzIf2jh+

やっぱり4だよね。

0677login:Penguin

2012/05/21(月) 10:49:59.19ID:Ms9i3XwP

４だと思う。
で、アマノジャクな人が２か５のZFSもどきを使う。
（だって面白いからな。）

0678login:Penguin

2012/05/21(月) 12:15:28.09ID:bVL44HWG

DragonflyBSDのHammer移植の方が現実的かもなぁ

0679login:Penguin

2012/05/21(月) 14:23:23.29ID:ibgDvpSH

やっぱりext4の系譜かー。そうだよね。

0680login:Penguin

2012/05/21(月) 14:58:35.07ID:ocjJ24me

>>679
機能的にZFS以降のfsとは差がつきすぎているし、
代替は欲しいんだけどねい…

0681login:Penguin

2012/05/22(火) 07:50:09.39ID:7a68CDWm

http://japan.cnet.com/news/business/35017280/

　来日中の米Microsoftの最高経営責任者（CEO）Steve Ballmer氏が5月21日、東京・渋谷区のホテルで開催されたパートナー向けのイベント「Windows Partner Executive Summit」で講演した。

　Ballmer氏が米国外を公式に訪問するのは、2012年に入ってから初めてのことだ。次期OS「Windows 8」の開発が最終段階に入った今、最初の訪問国・日本のパートナーに「今年はMicrosoftの歴史の中でも、
もっともワクワクする1年」とメッセージを発し、Windows 8の登場によって大きな変化が訪れると強調した。
Windowsを再創造する
マイクロソフトCEOのスティーブ・バルマー氏。明日から韓国、中国、インドを歴訪する。マイクロソフトCEOのスティーブ・バルマー氏。明日から韓国、中国、インドを歴訪する。
※クリックで拡大画像を表示

　Windows 8は、今年後半の登場が予定されているMicrosoftの次期OS。従来に比べて機能を追加しただけでなく、新たなUIを投入する点が特徴だ。より高速で滑らかに動作し、
スマートでモダンなデザインを実現させることを目標としている。既存のWindows 7の機能もさらに強化し、「新たなレベルに引き上げ」（Ballmer氏）たものの提供を目指して開発が行われている。

　Ballmer氏が繰り返したのは「再創造（Re-Imagine）」だ。Microsoftは、Windows 8で「再創造の1年であり、チャンスの1年」（同）にしたい考え。
この1年で、3億5000万台のWindows搭載PCが出荷されているとの調査を引きながら、「競合他社はPCとタブレットをあわせて6000万?7000万台の出荷」（同）と、その差を強調。
Windowsという強力なプラットフォームが「再創造」されることで、パートナー企業にとっても新たなチャンスが生まれるとした。

んなもんより時代遅れのNTFSよか新しいファイルシステム作れや！！！！！！！！！１１１１１１

0682login:Penguin

2012/05/22(火) 09:32:07.35ID:In5wan4s

初歩的な質問ですまないけど一つ教えて。

ext4であるファイルの内容を修正（ファイル全体のサイズは変わらないような変更）をした時、
該当箇所を格納したブロックの内容を変更して、書き戻す位置はHDDに対して元あったLBAと同じ位置を指示するの？
それとも別の空いてる場所に書くの？
さらに修正箇所が複数ブロックに含まれる場合はどうなるのでしょうか？

0683login:Penguin

2012/05/22(火) 10:29:12.17ID:xdP67uUV

>>672
んなことない。
それは書き込み順序が保証される場合で、バリア張れなければセクタアトミックでマルチセクタアトミックは実現無理。

0684login:Penguin

2012/05/22(火) 10:53:33.83ID:1cxhPa0y

>>682
今時のファイルシステムは、ファイルの内容を書き換える場合に、
データブロックをそのまま使って中身だけ書き換えるなんてことはしない。
理由はトランザクション処理におけるクリティカルセクションが長くなるから。

1. 古いデータだけしかない状態
2. 新しいデータを空いているブロックに書き込む
3. 古いデータも新しいデータも共存していて、ただしメタ情報は古いデータを指している状態
4. 新しいデータを指すようににメタ情報を書き換える
(メタ情報はすごく小さいのでクリティカルセクションを小さく出来る)

3(または2)の段階でクラッシュしても、古い状態は完全に残っている。
実際にはさらにインテントリストを使って、再起動後に更新をリプレーする工夫がある。

データベースのトランザクション処理を勉強すると良い。

0685682

2012/05/22(火) 11:07:12.35ID:lf9QnnI6

分かりやすい解説、ありがとうございます

0686login:Penguin

2012/05/22(火) 16:06:03.57ID:YPS563wb

>>684
そうすると、空き容量が書き換えようとするファイルのファイルサイズより小さい場合、
書き換えに失敗するということですね

0687login:Penguin

2012/05/22(火) 16:23:56.66ID:1cxhPa0y

トランザクション単位は通常ブロックだよ。

ファイルのバージョン管理しているファイルシステムには、
さらにopen/close単位でもトランザクション管理しているのもあるけど。

0688login:Penguin

2012/05/22(火) 17:52:40.29ID:LU/paeRW

mbrを消したら完全に読めなくなるFSってあるんですか？EROIひと

0689login:Penguin

2012/05/22(火) 18:26:05.86ID:A1CjT9vU

MBRってどういうものか、ググればわかるような

0690login:Penguin

2012/05/22(火) 18:30:33.55ID:OmWdc1HW

MBRってFS関係あるんですかね・・・？

0691login:Penguin

2012/05/22(火) 18:34:53.53ID:1cxhPa0y

wikipediaくらいは読んでるの?

0692login:Penguin

2012/05/22(火) 20:10:19.29ID:LU/paeRW

>>690
mbr消してもtestdiskつかったりdumpすれば
先頭のデータみたらどこからどのパーティション始まるかわかるから
mbr修復できるけど、それができないFSはあるのかなと・・・

0693login:Penguin

2012/05/22(火) 21:33:06.53ID:rvtR6o93

>>668
＞＞これについては、「アトミック書き込み保証問題は、サーバ業界が4KiB論理セクタ長に向かっている理由の1つである」とコメントが付きました。

この引用だけ読むと、ん？セクタ長が長くなる方がアトミク保証キツそうだがと思ったが、AFTのRMWを問題視してるのかな？

確かにアラインがあってない状態でブロックライトしたときたまたまそれがトラックまたがりだったりしたら、
電源供給たたれた状況ではRMW完遂キツそうかも。

0694login:Penguin

2012/05/22(火) 21:39:10.48ID:rvtR6o93

ごめん、FSのブロックとHDDの物理セクタは直接の関係はないからアラインうんぬんはミスリードね

0695login:Penguin

2012/05/22(火) 21:47:16.05ID:Gee1IVDc

>>690
ディスクだ

0696login:Penguin

2012/05/22(火) 22:28:52.43ID:UDqTDYqA

>>682
>>684
簡単な検証をしてみたが次のようになった。

1. dd で 1GB のファイル(disk.raw)を作成、mkfs.ext4 でファイルをフォーマット
2. loop オプションでマウント
3. 64KB のファイルを作成。中身は全部 0xC1 (00とかFFでなければ何でも良かった)
4. 一旦アンマウント。
5. disk.raw を 16進ダンプして C1 が 16個並ぶ行をカウント → 4096 行
5. fseek と fwrite(C言語) 使って 7000(0x15B8)番地から 12000バイト適当なパターンを書き込み
6. アンマウント
7. disk.raw を 16進ダンプして C1 が 16個並ぶ行をカウント → 3345 行

(4096-3345)*16(１行16バイトでダンプ)=12016 (12000 バイト + 16の倍数では無いところから開始分)

1GBを32MBにするとブロックサイズは 4KB から 1KB になるけど結果は同じ。
このとき 16進ダンプ自体を比較したが変更されたのは 832 行 (13376 Byte) だけ。
# diff -u pre.txt post.txt | egrep -e '^[+]' | wc -l --> 832

diff の結果を詳しく見ると書き込んだパターンの前のデータはすべて C1 の行で、
どう好意的に解釈しても >>684 の言う動作をしているとはいえない結果だった。

0697login:Penguin

2012/05/22(火) 23:21:43.39ID:rvtR6o93

ext4のmountオプション

2012/05/22(火) 23:40:12.43ID:tlYG6Oak

684さんはDBか何かの話をしているのだろう、普通のファイルシステムは
セクタ単位に上書きして済ませ面倒な操作は回避する。

電源が落ちると、HDDは一番外側のトラックに緊急書込みしてDRAMの
イメージを保存する、SSDもDRAM上に保持していた更新データは急遽
特定のページに書込む、HDDもSSDもDRAM上のデータは電源が落ちても
維持するから書込み応答があれば書込めたと考えていいはず。

ただ、SSDで電源の落ちる速度が速いと飛んでしまうSSDがあって、
それでWindowsの休止が使えないSSDを掴まされた。

0699login:Penguin

2012/05/22(火) 23:45:08.80ID:R0N4pj0/

彼の言う「今時のファイルシステム」にext4やntfsは含まれていないのですよ

0700login:Penguin

2012/05/23(水) 00:20:02.34ID:0eIoicZI

5の処理はひとつの操作じゃないから、
5の間に解放されたブロックが最利用されてるんじゃないの?

0701696

2012/05/23(水) 00:47:46.11ID:9NniJAVU

>>700
すいません、次のとおりです。

1. dd で 1GB のファイル(disk.raw)を作成、mkfs.ext4 でファイルをフォーマット
2. loop オプションでマウント
3. 64KB のファイルを作成。中身は全部 0xC1 (00とかFFでなければ何でも良かった)
4. 一旦アンマウント。
5. disk.raw を 16進ダンプして C1 が 16個並ぶ行をカウント → 4096 行
6. マウント
7. fseek と fwrite(C言語) 使って 3. のファイルの 7000(0x15B8)番地から 12000バイト適当なパターンを書き込み
8. アンマウント
9. disk.raw を 16進ダンプして C1 が 16個並ぶ行をカウント → 3345 行

> 5の間に解放されたブロックが最利用されてるんじゃないの?
再利用されていれば 1KB(1ブロック) 以上 C1 じゃ無いところが発生するはずだが実際は
すべて上書きだった。ここまでだとデフラグされた可能性はあるけど、
ext3/4 のジャーナルがメタ情報しかジャーナリングで保護されないと知っていれば
>>684 の言う動作はしていない(していればメタ情報しか保護しない理由がなくなる)
と解るはず。

0702login:Penguin

2012/05/23(水) 20:08:33.34ID:53GntL47

>>684はそこまで的外れなことは言ってないんじゃないの。
手元のext4のファイルシステムで試してみたけど
openにO_TRUNCを付けて開く→別のブロックアドレスに新規の内容が書き込まれる。元のブロックアドレスにはファイルの内容は残存。(>>684の言う動作をしてる?)
openにO_TRUNCなしで開く→同じブロックアドレスに上書きで書き込まれる。(>>701のやった実験)
どっちの場合でもinode番号は保持されている。

当たり前だけど一つの巨大なファイルをO_TRUNCなしで開いて何回もlseekとか使って読み書きする場合は
同じブロックに書き込まないと断片化しまくりんぐなんだよね。
んで>>682の質問は多分O_TRUNCなしの場合の疑問だから多分元あったLBAにそのまま上書きってことでいいと思われ。

まあ、俺もあんましファイルシステムに詳しい訳じゃないから間違ってたら指摘頼む。

0703login:Penguin

2012/05/23(水) 20:14:35.20ID:Uvt1kmUp

>>684
それ、Copy-On-Write を実装したファイルシステムの典型的な挙動で
それでbrtfsやZFSが注目されてるけど、まだまだ一般的じゃないよ

今普通に使われてるファイルシステムは
未だに停電時のデータ保全は保証されてなくて
だからデータベースソフトは凝った制御をわざわざしてる

0704login:Penguin

2012/05/23(水) 20:46:06.35ID:zTpk22Ks

>>703
ZFSやbtrfsやHAMMERはモダンなfsと言われている由縁ですな。
あと、機能的にはボリュームマネージャとfsとの統合もしているのが
モダンなfsの特徴。

0705login:Penguin

2012/05/23(水) 21:47:33.19ID:HiaPoJkG

>>702
truncしたら
＞1. 古いデータだけしかない状態
ここが無いだろ

0706login:Penguin

2012/05/24(木) 09:35:00.94ID:8W5aSkeX

nilfsもモダン

0707login:Penguin

2012/05/24(木) 09:48:16.92ID:fjuo8JDB

lfsはモダンすぎた

■ このスレッドは過去ログ倉庫に格納されています

ファイルシステム総合スレ その14

ファイルシステム総合スレその14