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

/**ファイルシステム総合スレその8**/ at LINUX

[1からを表示]
50:login:Penguin
07/09/29 02:15:06 /BL+mcur
白けてるってのはともかく、スレ違いってのはどうなのよ。
NTFSの読み書きが！な話題はLinuxのファイルシステム系FAQに
ちょくちょく登場する話題じゃねーの。

51:login:Penguin
07/09/29 03:38:45 /BL+mcur
>>49
実験したわけではないので、間違ってたらすまん。誰か詳しいひと訂正よろ。

シンボリックリンクは\\server\foo\barみたいなUNCでも、表現が有効なパスならリンクできる。

ジャンクションはUNCは駄目。普通のパス限定。そのかわり、GUIDでも良い。
GUIDは定義的に一意だから、リムーバブルメディアで抜き差しされて消えたり、
アクティブディレクトリ配下の別マシンに移動しても、追随してくれるんじゃないかと思われ。

52:login:Penguin
07/09/29 06:33:29 6qdGgOsL
IO_REPARSE_TAG_SYMLINKのタグがついたリパースポイントがシンボリックリンクとして動く。

そのリンク先のアプリケーションのファイルシステムフィルタドライバで内容を理解して
2k/XPでシンボリックリンクとして使えるようになっているんかな?
本来は無視というか理解できないリパースポイントとして処理されるんだろう。
それを作るAPIとかあるのか知らないけど、DeviceIoControlで読み書きしてくれとあるな。

>シンボリックリンクはWindows Vistaからの新機能ですが、
>作成だけならWindows 2000以降で可能です。
>Windows 2000/XPでのアクセスには専用のドライバが必要です。

ジャンクションはIO_REPARSE_TAG_MOUNT_POINTで、名前が示すとおりマウントポイント。

なんとなくだがファイルエントリに独自データを付け足す機能を使って色々実現しているような感じ?
URLﾘﾝｸ(msdn2.microsoft.com)

てか久しぶりにMSDNにきたw

で、LinuxのFSはどうやってシンボリックリンクを実現しているんだ?
struct inode_operationsにsymlink回りの操作という要求があるだけで、実装はFS独自でいいんかな?

53: ◆IIiDC8JS7w
07/09/29 10:41:07 tkK0YZpk
シンボリックリンクのメタデータはst_modeがS_IFLNK。
シンボリックリンク先を示すパス名はファイルデータとして扱うのが多いかな？
ファイルシステム依存だけど。。
readlink時にそのシンボリックリンク先を示すパス名を返却すればよい。

シンボリックリンクファイルのサイズは
シンボリックリンク先を示すパス名の長さを入れておく。
POSIXではどう定義してたかは忘れました。。

54:login:Penguin
07/09/29 11:20:41 9obDUT7z
>>49
ジャンクション→フォルダのみ（拡張なしの場合）
シンボリックリンク→ファイル、フォルダ双方
じゃね？

>41のリンク先および>52の「ジャンクションはIO_REPARSE_TAG_MOUNT_POINT」から間違いないんじゃね？

55:login:Penguin
07/09/29 11:26:22 9obDUT7z
昔、ジャンクションとハードリンク愛用してたが、
他のドライブのファイルへのリンクで困った覚えがあるよ。

56:login:Penguin
07/10/01 12:47:01 ue4uUraO
話が噛み合わないのはVistaのせいだろうな。

Vistaが出る前だったら、
「Winのジャンクションは、Linuxのシンボリックリンクの様なもの」
で済んだのが、

Vistaでは、「シンボリックリンク」と言う名の別物を追加しちゃった。

57:login:Penguin
07/10/01 13:08:51 iiACKgq1
ショートカットもあるしな。

58:login:Penguin
07/10/01 18:47:21 SuzWd+e8
WindowsのジャンクションはUNIXのmountなんだがな、本来。
ディレクトリをディレクトリにmountできる、て拡張機能があるだけ。

59:login:Penguin
07/10/01 18:52:53 ygOGMLej
Linuxのmount -bindみたいなもんか？

60:login:Penguin
07/10/01 22:47:56 KkbBVhl8
>>58
つかそれ、joinじゃね?

61:login:Penguin
07/10/04 01:01:37 XQWe7u+r
>>56
>　Vistaが出る前だったら、
>　「Winのジャンクションは、Linuxのシンボリックリンクの様なもの」
>　で済んだのが、

それは違うでしょう。

ファイルのリンクができないのにシンボリックリンク？
それともジャンクションでファイルのリンクができる？

62:login:Penguin
07/10/04 01:05:35 0U5S0sDC
どっちかっつーとハードリンクに近くなかったか？

63:login:Penguin
07/10/04 01:06:09 s9AihyIX
まー、>>56は"Vistaでは、「シンボリックリンク」と言う名の別物を追加しちゃった。 "ってことを言いたかったんでしょう。
>>38の言ういわゆる証拠を見る限りでは、確かにそう見えますしね。
実用上はシンボリックリンクとして使えるようですが。

64:login:Penguin
07/10/04 01:15:46 XQWe7u+r
>　話が噛み合わないのはVistaのせいだろうな。

こういうこと言っておいて、噛み合わない話されるのはちょっとね

65:login:Penguin
07/10/04 03:22:14 mcIslE/j
>>58
で、俺は腑に落ちたんだけどまだ引っ張るのこの話題？

66:login:Penguin
07/10/04 13:27:43 tcAb45yk
soft update vs journaling?
URLﾘﾝｸ(lkml.org)

誰も反応しないのか

67:login:Penguin
07/10/04 14:15:50 SX6Gg+w/
>2006/1/22
二年も前なのに未だに参照多いのな。
でちょっと前のスレのインターフェイスによってflushが云々とかVFSがーとかに戻るのかw

自分もまだ続けるがw、ntfs-3gがいつの間にか1.1004とかになってて
ChangeLogはパフォーマンス関係がズラズラと並んでるな。
やっぱfuseはその辺結構遅くなってしまうんかな?
そしてちょうどntfsprogも2.0もリリース。
* Cryptographic code is now integrated into libntfs, thus ntfscat and
ntfsmount can now read encrypted files.
だってさ。

68:login:Penguin
07/10/04 20:20:43 NLLldcc5
流れぶったぎって xfs だが。導入検討で負荷テストかましたらボロボロすぎて笑えた。
これ本当にプロダクションクオリティで使ってるところあるのか？
古くて遅いサーバーでは確率が低くて顕現しなかっただけなのか？

結局、某所起源とかいう怪しいパッチを当てて多少は良くなったが、
なにこのデッドロック一直線みたいなコード。って話らしい。
まだ見つかってないものも結構ありそうってことで、当分 xfs は使わないことに決まり。
っていうか、最近 xfs のコアな開発者のアクティビティ下がってないっけ？

69:login:Penguin
07/10/04 20:53:28 SAdE+UoY
xfs って、なんか異常事態が発生したときに
レスキュー仕様がない気がする。そういうツールが見つからない。
ext2/3 にはいろんなツールが用意されていて、
部分的にでもレスキューできたことが多かった。

70:login:Penguin
07/10/04 21:39:32 v1MBmS7L
>>68
なんだこの脳内ｶｰﾈﾙﾊｶｰ

71:login:Penguin
07/10/04 21:50:58 V6CnMRGn
>>68
パッチがあるということは、問題箇所の特定ができているんだよな
晒せよ

72:login:Penguin
07/10/04 21:52:31 ETOhmAlJ
s/xfs/reiserfs/g
なら話はわかるが

73:login:Penguin
07/10/04 22:16:49 t6wFmzOR
>>69
XFSは異常な状態にならないからいらない。

74:login:Penguin
07/10/04 22:28:08 NmqYv4MX
どんな負荷テストか気になるね。
幸い、xfsがメインツリーに入る前から使ってて、トラぶったこと無いけど。

75:login:Penguin
07/10/04 22:30:14 YL3t7F7g
xfsだと問題が出るって言ってるページたまに見かけるけど、何が問題だったのか公開してないとこ多いよな

76:login:Penguin
07/10/04 23:01:34 gBGWB7sO
URLﾘﾝｸ(www.miraclelinux.com)
ここで言及されているLVM+XFSの高負荷での問題が
実はXFS+NFSや、高速CPU環境ならばXFS単体でも発生する（していた）
リソースが不足した状況でそのリソースを退避するために新たなリソースを確保しようとして死ぬ。

過去に断続的に修正されているのがソースを追っていけば分かるはずだが
何年もかけて「直した」「直した筈だが直ってなかった」の繰り返しを見れば
完治しているほうに賭ける気はおきないと思う。

パッチはAsianかTurboが作ったやつではないか。

77:login:Penguin
07/10/04 23:22:53 NmqYv4MX
なるほど。ぎりぎりの状態で運用しなけりゃ良いのかな。

78:login:Penguin
07/10/04 23:33:04 XQWe7u+r
「高速CPU環境ならばXFS単体でも」っていう点が気になるな
本当なら、今の高速CPUが普通のCPU扱いされる頃には、かなり問題

79:login:Penguin
07/10/04 23:41:00 kYZne6p6
>>76
テスト機はどのくらいのCPUを使ってたのよ？

しかし、高速なCPUで負荷掛けてると出るってのはやっかいだね。

80:login:Penguin
07/10/04 23:42:33 gBGWB7sO
本来は危険な状況になる以前にリソースを退避できるはずだが
高速なCPUでは、退避する以上の速度でリソースが消費されて
一気に危険領域に突入してしまう可能性がでてくる。

CPUとHDDの速度差が年々開いていくのが悪い。HDDもっと頑張れ。

81:login:Penguin
07/10/05 00:12:52 Es44/vFg
まぁ結局困った人が直せばいいだけで。
upstreamに投げもせずローカル八苦で
お茶を濁して、永遠に苦しめや。

82:login:Penguin
07/10/05 01:29:13 QEMnlMPt
そういえばGentooのインストールマニュアルに使用するファイルシステムの解説にXFSはきちんとした
バックアップ装置のあるシステムじゃないとお進めできないって書いてあるね。

83:login:Penguin
07/10/05 07:42:37 e7R5o0xV
いきなり現れた脳内ハッカーがなぜかそろって日本語が怪しい件。

顕現てw

84:login:Penguin
07/10/05 11:37:50 Es44/vFg
>>76
多分、ただのstackあふれの事を言ってるだけじゃない？

85:login:Penguin
07/10/05 12:04:39 1cqRS2HI
>>84
え？4KSTACKはXFSではするなとかそういう話ってこと？

86:login:Penguin
07/10/05 12:27:06 Es44/vFg
>>85
当時は4KSTACKSではもっての他だよ。

87:login:Penguin
07/10/05 16:18:50 DU6apKnl
アスペってるハッカー連中なんて日本語変で普通

88:login:Penguin
07/10/06 16:21:02 44M1ASQe
お前だけだよ、それは。

89:login:Penguin
07/10/06 20:14:10 QcfIBVCq
うちに常駐しているＳＥも日本語が通じにくい人種だなあ。
定時報告をＣかＰｙｔｈｏｎで書いてきていいよって冗談で言ったら、
本当に書いてきた・・・・

そしてＰｙｔｈｏｎの報告のほうが分かりやすかった。

90:login:Penguin
07/10/06 21:19:30 KHgOUPQm
>>89
print "うぷキボンヌ。"

91:login:Penguin
07/10/07 04:20:02 BxbjY2yi
URLﾘﾝｸ(thunk.org)
なんかニュース?かなんかの番組でreiserの特集が放送されたらしい。

URLﾘﾝｸ(www.wired.com)
上のサイトからリンクされてるwiredの記事。さすがに怖い顔w

92:login:Penguin
07/10/08 06:48:54 B3pwhPtq
>>89
それは見てみたい

93:login:Penguin
07/10/10 21:54:04 7tw4WYOv
>>89
ズバリ言おう。

お前それって単に嫌われてるんじゃネーの？

94:login:Penguin
07/10/11 05:42:59 rk8nxkTS
>>93
ちがう。
それは、愛。

95:login:Penguin
07/10/11 22:03:51 EcVz7qzq
あれも愛。

96:login:Penguin
07/10/11 22:46:53 TeO7wqtw
きっと愛。

97:login:Penguin
07/10/11 22:47:30 TeO7wqtw
ごめんなさい、たぶん愛、と抜かした気がします。

98:login:Penguin
07/10/12 05:03:50 c75VVdbM
URLﾘﾝｸ(kerneltrap.org)

99:login:Penguin
07/10/12 18:29:23 9S3clINl
Hansがタイーホされてからもう1年が経ったんだね。
長かったような短かったような。
開発に復帰できる日はいつだろう。
早くその日が来るのを待ってるからね。

$ df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sda2 reiserfs 14650812 3861780 10789032 27% /
tmpfs tmpfs 776876 0 776876 0% /lib/init/rw
udev tmpfs 10240 40 10200 1% /dev
tmpfs tmpfs 776876 0 776876 0% /dev/shm
/dev/sda3 reiserfs 169954424 89489704 80464720 53% /home
/dev/sda1 ntfs 10243768 9726120 517648 95% /win
none tmpfs 776876 12 776864 1% /tmp

100:login:Penguin
07/10/12 19:44:55 z6fGMg8B
HansってReiserfsの権利をまるごと譲るって言ってなかったっけ。
ネーミングライツだけだっけ？
あれを買い取って2chfsとかいう名前にしようとかいう猛者はいないかとwktkしてたんだが。

101:login:Penguin
07/10/13 04:43:29 0RiYGNIl
結局、Hashははめられたの？？

102:login:Penguin
07/10/14 06:53:45 Drp7GIUt
HashよりB-Treeで

103:login:Penguin
07/10/15 23:46:55 1TyWb1IN
URLﾘﾝｸ(kerneltrap.org)
>I've never looked at the Reiser code though the comments I get from friends who use it are on the order of 'extremely reliable but not the fastest filesystem in the world'

104:login:Penguin
07/10/27 14:04:23 Z5LZxcC0
LeopardのTimeMachineの正体はやっぱりpdumpfsでした。
URLﾘﾝｸ(journal.mycom.co.jp)

105:login:Penguin
07/10/27 15:31:22 X7K4yEiH
いろいろ試したけどバックアップに関しては結局自分専用の
Subversion用リポジトリを持つことにした。

106:login:Penguin
07/10/27 17:57:59 fQDlUobv
>>104
pdumpfs程度であんなに大々的に宣伝するとは、Appleって…

107:login:Penguin
07/10/27 18:07:34 d/frK7MS
一応自分とこように何かカスタマイズしているんじゃないかな。
普通のハードリンクがMacのHFS+には無いっていうし。

108:login:Penguin
07/10/27 18:24:56 81dS2oIK
subversionはレポジトリの他に
ローカルコピーと.svn内のコピーと
元の三倍の容量が必要になるから
ホームをまるごととかには使いにくいんだよな。

109:login:Penguin
07/10/27 18:32:05 U/jqU4zt
>>107
あとUI。タイムラインをグリグリやってQuickLookでみるGUIとか。見せ方で売る会社だし。

110:login:Penguin
07/10/27 18:55:43 fQDlUobv
>>109
他の記事を読んでみたけど、見た目周りの変更だらけだね。
MacOS 9の頃の付属アプリのちょっとしたアップデートをOSの大々的な
アップデートのように言ってしまう時代に逆戻りした印象が。
もちろん、この記事からだけでは判断できないけど。

それにしても、根本的に腐っているHFS+をまだまだ使い続けるって
OS Xは悲惨だ…

111:login:Penguin
07/10/27 18:58:58 FseVhWdt
>>110
>根本的に腐っているHFS+

詳しく

112:login:Penguin
07/10/31 19:34:16 INSQGhSy
>>104
な、マジで！
そうか、それでRubyサポート強化か・・・

（さすがにpdumpfsそのまんまじゃないわなｗ）

いや、でもpdumpfsのアイデアは、シンプルだけど強力だっていうことでしょ。
あれで、バックアップ経路に自由が利いたらpdumpfsだけですむんだけどなぁ。

113:login:Penguin
07/11/01 00:11:23 YXZCtuNj
pdumpfsリソースコピーできないよね？
OSXだとrsnapshotかな？

114:login:Penguin
07/11/01 01:25:40 VJvPHzZF
>>113
リソースコピーってなに？

115:login:Penguin
07/11/01 07:54:10 tVJeM7w8
>>114
Mac特有のリソースフォークのことでそ
Wikipedia項目ﾘﾝｸ

116:login:Penguin
07/11/02 15:43:37 pmYz0pmP
平和だな

117:login:Penguin
07/11/06 19:57:28 Y9I3A8T4
ocfs2とかgfs2とかはこのスレでいいのかな？
最近、nfsが遅いのに腹を立て、iscsiとocfs2に切り替えた。
設定も拍子抜けするほど簡単だし、モジュールもカーネルに入ってるので
とても楽。cvsから取ってくるとコンパイル通らなかったりするけど。

118:login:Penguin
07/11/15 22:55:58 +a+rbqpF
URLﾘﾝｸ(kerneltrap.org)

119:login:Penguin
07/11/17 11:31:14 Mri548d4
ext3、reiserfs、xfs、jfsすべからくファイル名は255byteまでか

120:login:Penguin
07/11/17 11:47:48 vm/oyl4R
os側の制限とかもあるんかな?
URLﾘﾝｸ(en.wikipedia.org)

121:login:Penguin
07/11/17 12:56:50 Mri548d4
reiserfsの項目を見る限りVFSに制限がありそうやね

122:login:Penguin
07/11/17 17:50:27 5WJwcwXN
すべからく【須く】
すべくあらく（すべきであることの意）の約。
当然。

123:login:Penguin
07/11/17 19:32:01 frj6nuku
ext3 以外のファイルシステムの存在意義がわからない．

124:login:Penguin
07/11/17 19:33:49 cXymNrbW
ext4も否定かえ？

125:login:Penguin
07/11/18 00:02:09 8qBVFYp0
ex4 がデファクトになるまではな。

126:login:Penguin
07/11/18 02:32:41 SrkzGQPz
つまりスタンダードになる準備のために存在してるわけだ

127:login:Penguin
07/11/22 01:35:22 D7Its18+
しっかし、XFSやJFSがアレなことが知れ渡り、Reiser逮捕でReiser4が
開発停止状態になっていから、fsスレはさびれちゃったな…

唯一の希望のZFSはFreeBSDに話題持っていかれているし。

128:login:Penguin
07/11/22 03:42:41 IaDwOlJS
>>127
XFSやJFSのアレなことってなんじゃい？

129:login:Penguin
07/11/22 07:57:30 prIo4FxR
>>128
ZFS厨にかまうな

130:login:Penguin
07/11/22 13:27:00 D7Its18+
>>128
XFSは>>76-80、JFSは前スレ嫁

>>129
レッテル貼り付けて思考停止する人、乙。

131:login:Penguin
07/11/22 14:57:14 5Q+/5i5e
XFSについては、MLを読んで自己判断しましょう。問題ない環境の人も多いわけで。

あくまでも個人的意見ですが、RHEL4あたりの古いkernelでXFSを使うなら、
最新kernelからXFS関連の修正部分をバックポートするか、関連パラメーターを弄るべきだと思います。
が、パラメータを弄るのは難しくて良く分からない・・・。

132:login:Penguin
07/11/22 21:47:50 WgZY+aov
129のようなバカが湧いてきたんで、前スレのJFSダメやんって話題の
元になったメールを。
URLﾘﾝｸ(www.ussg.iu.edu)

133:login:Penguin
07/11/24 19:03:53 bxJhbnRn
現実問題として一番テストされてるのが ext3 である以上、
独自に納得いくまでテストするのでなければ
ext3 以外に選択肢はない。

134:login:Penguin
07/11/24 19:12:56 sauQFbv3
oracleのbtrfs、nttのnilfs、dragonflyのhammerfs、sunのzfs、
そして今回は速度面の改良も割と入っているext4あたりが今後のネタか？
ただアイディア的にはfs界ではraiserが突出してたようなあ感じがするが。
一部にはzfsのパクリとか言われながらも割と進化してるbtrfs、
reiserを追い越せるか、最強のfsになるとか言ってたようなhammerfsあたりはおもろそうだが、
システムと一体となったzfs,ntfsあたりはやはり強そう。

135:login:Penguin
07/11/24 21:37:22 BiG3ryPJ
>nttのnilfs

さりげなく何を入れてるんだ…

136:三文字路線で
07/11/24 21:38:39 BiG3ryPJ
おっ、ID がビッグ3 だ…

というわけで勝手に ZFS XFS JFS をビッグ3 と決めますた

137:login:Penguin
07/11/24 21:44:18 lC7phVQh
>>117
ocfs2とかどないなのか気になる。
というか次世代となるとクラスタFSになるんじゃない？
速度や信頼性を追求する場面でextとかxfsとかいう話は出てこなくなるのかも

138:login:Penguin
07/11/24 21:51:40 8qHXSCfW
zfsもクラスタ対応になるんじゃなかったっけ？

139:login:Penguin
07/11/24 22:01:51 sauQFbv3
クラスタ対応とかは興味ないというかいらないなぁ、クライアントじゃぁ。

140:login:Penguin
07/11/29 19:45:24 rD7JhOhk
次世代ファイルシステムの行方
URLﾘﾝｸ(japan.internet.com)

141:login:Penguin
07/11/30 09:37:54 rV4snyMU
特に何の意味もない記事だなあ。

142:login:Penguin
07/11/30 10:42:43 mleGbSeF
っていうか「日記はチ(ry」

143:login:Penguin
07/11/30 21:26:49 pAVg9f1O
Linux ファイルシステムの徹底調査
URLﾘﾝｸ(www.ibm.com)

144:login:Penguin
07/11/30 21:30:53 deZGR6be
＞以上が、20,000 フィートの上空から眺めた VFS とファイルシステム・コンポーネントの全体像です。
いいね、こういうのは。

145:login:Penguin
07/12/01 22:07:33 g+5VeIb9
お前もカーネルと一緒に静止軌道衛星で上空に浮かんでろ！
て、思う。

146:login:Penguin
07/12/08 01:20:52 sU/Rcdj4
Linuxって、FS層にイベント処理組み込む予定ないんだろうか？
実装されたら、サーバ間同期とか、リアルタイムバックアップを、
低い負荷で実現できそうなのに。

あとはパーティションを超えてのハードリンクと、
ディレクトリのハードリンクが実装されないかなー。

147:login:Penguin
07/12/08 01:25:50 FeHiOV7B
>>146
inotify?

148:login:Penguin
07/12/08 01:46:12 FNgZ13Kb
>>146
ディレクトリのハードリンクは".."があるから構造的にムリだべ。

149:login:Penguin
07/12/08 01:54:29 sU/Rcdj4
>>147
inotifyってFSレベルで実装されてたのか。知らなかった。

inotifyを使ったバックアップソフトってもう登場してる？
ググっても見つからない・・・。

150:login:Penguin
07/12/08 02:37:44 YDy//UIh
ところで、NTFSが遅いのでLinux+sambaに置き換えようと思っているのだが、
ファイル数とパフォーマンスの比較ベンチみたいなデータ掲載してるサイト有りませんかね
/home的なファイル群なのでパーテ多数作って細分化したら速度落ちないかなぁと期待してるんだけど。
xfsが巨大ファイルに強いってのは見たことあるんだけど、ファイル数での得手不得手ってどうなんでしょ。

151:login:Penguin
07/12/08 02:54:59 ELorHOyo
>>149
incron+今使ってるバックアップツール
じゃだめなのか？

152:login:Penguin
07/12/08 03:57:20 sU/Rcdj4
>>151
イベントが起こるごとにプロセス起動してたら、
せっかくの低い負荷が台無しになりそうな予感。

incron
URLﾘﾝｸ(inotify.aiken.cz)

イベントを受け取って、指定されたファイルに
イベント名とパスをひたすら出力するデーモンと、
そのファイルに書かれてるパスをバックアップするツールを
組み合わせるとかが妥当かな？

そうすれば好きなバックアップツールを使えるし、
負荷が低い深夜とかにバックアップさせることも出来るし。

153:login:Penguin
07/12/08 04:29:16 AOgHL0gM
てか、バックアップ対象のリストを作るだけならincron自体がいらないじゃん。
好きなバックアップツールだけをつかって負荷が低い深夜に(ry

154:login:Penguin
07/12/08 04:35:29 sU/Rcdj4
>>153
いやいや、それが最近の容量が大きいHDDだと、
一晩じゃバックアップできないんだよね。
手持ちサーバだと、差分バックアップしても10時間ほどかかってる。

そこでイベント処理で素早くできないかなと。

155:login:Penguin
07/12/08 04:50:40 AOgHL0gM
>>154
ファイルシステムレベルでのスナップショットがいるんじゃない?
とふってみよう。

156:login:Penguin
07/12/08 04:56:58 sU/Rcdj4
>>155
確かにスナップショットは欲しいけど、
本稼働サーバでXFSを試すほどではないかなー。

157:login:Penguin
07/12/08 06:02:13 AOgHL0gM
>>156
更新をIN_ONESHOTで監視してイベントを受け取ったらデイリーバックアップ
ってことにすればいいんじゃねぇと思ったけど、肝心のinotify(7)って、
監視イベントを踏んだ方はイベントを受け取るプロセスをただ起こすだけで、
処理をじゃんじゃか続行してかねーか?

158:login:Penguin
07/12/08 11:54:13 7rFxjzQG
>>149
バックアップとはちと違うかもしれんがこんなのか
URLﾘﾝｸ(freshmeat.net)

159:login:Penguin
07/12/08 13:58:48 fXv3+El5
inofityって監視したい対象ごとにinotify fdに追加していかなきゃいかんから
システム全体の全ファイルをモニタするのは無理。

欲しいのはVFS hookなんだけど、LSMとかkprobesでモニタするような処理を
挿入できるのかなぁ。

160:login:Penguin
07/12/08 17:21:09 9+lQmPMD
>>154
それrsyncで普通にバックアップした方が結局速くなったりしない？

161:login:Penguin
07/12/08 18:03:30 sU/Rcdj4
>>158
おっ、やっぱりあったね。

>>159
まじで・・・。
トップディレクトリだけじゃダメなんだ？

>>160
今rsync使って10時間。
rsync 3.0でメモリ使用量が激減するらしいので、
そうなれば少しは早くなるかなとは思うけど。

162:login:Penguin
07/12/08 19:42:14 AOgHL0gM
>>159
mmap(2)してるやつまで考えると頭が痛くなりそうな気がする・・・

163:login:Penguin
07/12/10 09:05:05 1o7EIMpK
>>146
backup/restoreしたらリンクが切れそうだ

164:login:Penguin
07/12/16 22:42:42 kEiA0RYk
同時アクセスに強いFSって今だとどれ？

165:login:Penguin
07/12/17 00:22:30 HS8oigxL
>>164
read に関してページキャッシュに乗ってればどれでも一緒じゃないか？
とコードも見ずに言ってみよう。

166:login:Penguin
07/12/17 01:55:43 RktuIZ7Z
ヘッドシークが短くなるよう設計してる(らしい)ReiserFS

167:login:Penguin
07/12/17 05:01:49 sg1FvI6J
その手の話は下でLVMやmdなどが動いていたら、fsレベルで何をやってもほとんど無意味じゃない?
fsレベルで下位のデバイスを直接面倒見るようにしないと、あまり高級なことはできなんだよなぁ。

168:login:Penguin
07/12/17 10:14:55 xMRdJbZY
それってI/O schedulerの仕事な気がする
ReiserFSはnoopと組み合わせたときに最高のパフォーマンスになるのだろうか

169:login:Penguin
07/12/18 01:29:57 +yZejH3O
もし
FSに与えられたボリュームの先頭と末尾にFAT的なものを設置して頻繁にsyncをかける、
などというFSがあったらやはり遅いのでは？
よくある環境で遅くなりにくいFS実装というのはありだろう。実際にどれがどうなのかは知らんけど。
同時アクセスつーても大雑把すぎるが、エントリのリストアップが高速なFSはWin向けによさそうかな

170:login:Penguin
07/12/18 04:18:07 6DnGK8YD
じゃあtmpfsが最強ってことでおｋ？

171:login:Penguin
07/12/18 09:57:01 stAupCCv
次点はReiser4な

172:login:Penguin
07/12/19 03:03:55 ICj0cKZP
Resier4そんな速いのかw
ext2で中途半端にキャッシュに乗った状態はすこぶる遅いと表明しておこう
ext3は挙動がよくわからない

173:login:Penguin
07/12/19 09:37:18 FtoZ4/4Y
>>172
>ext2で中途半端にキャッシュに乗った状態はすこぶる遅いと表明しておこう
何今更ネタを披露してんだ？

174:login:Penguin
07/12/20 06:22:34 vEhWN4uA
NTFSはもっと遅い

175:login:Penguin
07/12/30 13:51:28 1u1is7/Z
ちょっと前にイベント処理の話し出てたけど、
Mac OS Xは↓こうなってるらしい。翻訳もしてくれた人がいた。
URLﾘﾝｸ(arstechnica.com)
ｽﾚﾘﾝｸ(mac板:54-63番)

なかなかおもしろいね。
Be OSの方もどうなってるのか気になるなー。

176:login:Penguin
07/12/31 01:38:48 u9rDnk0D
ext3の500GBのHDDに500M～2GBぐらいのTV録画のmpegファイルを適当に放り込んでいたら一杯になったので、
もう一個SATA|IDE-HDDを買ってきてUSBでつないでバックアップつーか要保存のだけ
そっちに整理することにしたのだが、ファイルシステムは何がいいでしょうね?
保存用なので、HDDの利用効率(ext3はちょっと目減り激しい気がす)と壊れにくいのがいいのだけど、
場合によってはUSBで直付けしてWindowsでも見れるntfsもありかなと思っているんだけど。

177:login:Penguin
07/12/31 02:21:15 bruoMmTv
btrfsで。

178:login:Penguin
07/12/31 02:31:26 u9rDnk0D
>>177
ありがとう。調べてみます。

179:login:Penguin
07/12/31 02:49:08 +0ONQ7NM
btrfsはまだアルファ版では？

180:login:Penguin
08/01/12 02:03:46 jzLk1uOI
>>175
Appleも日本語リファレンス出したよ。

ファイルシステムイベントプログラミングガイド
URLﾘﾝｸ(developer.apple.com)

181:login:Penguin
08/01/12 02:29:53 Bx7hU4VM
板違いの話でなんでざーとらしくageちゃうんだろ・・・。
いや、触ったら連中の思うツボ。ここは触っちゃいけないんだったな。くわばら、くわばら。

182:login:Penguin
08/01/12 05:25:06 MhamVZBR
住人気取りきめぇ

183:login:Penguin
08/01/12 05:29:58 jzLk1uOI
>>182
住人だし。
イベント処理を使ったバックアップが出ないかなーと思ってるから、
参考になるかなと思って貼っただけ。

184:login:Penguin
08/01/12 05:38:03 SErII+Xc
気にも留められずに無視されるよりは、たとえ嫌われてでも意識してもらえる方がマシ…とかね

たとえウザがられようともMacやAppleという単語を目に触れさせるようにして、
1000人に一人でも10万人に一人でもいいから
「でもちょっと調べてみるか」くらいのアホが出て来ることを期待してるんだよ

自分たちの何十倍も巨大で、そしてその殆どが自分たちに対して興味すら抱いていない場合に
最も有効な戦略は、まずウザがられて叩かせることなんだ

ほんの10年前、2chができる前に、韓国や北朝鮮や、在日の話なんて誰も知らなかっただろう？
今では2chに来る人の間では、ほとんど常識になっているよね。
必死に彼らを叩く嫌韓厨たちは、連日「韓国」」「朝鮮」「在日」といった単語を
宣伝して回っていたというわけだ。憎悪に駆られて毎日膨大な時間を、韓国ニュースとかを漁ってね。

Appleも、同じ事をやり始めた。いくらメリットを説明しても、メッセージが届かなければ宣伝にならない。
まずはちょっとひと揉みしてアンチを生み、彼らに宣伝を手伝ってもらおう。…今は、そういう段階なんだよね

185:login:Penguin
08/01/12 06:01:06 jzLk1uOI
しかしこれだけストレージが大容量化されてくると、バックアップが大変。

HDDの障害はRAID構成で対処できるけど、
RAIDコントローラーの障害、ファイルシステムの破損は、
結局外部メディアにバックアップしておくしかない。
もし落雷や火事にまで対応するのなら、ネット経由でのバックアップが必要。

しかし常にLoadAverageが高いサーバだと、
バックアップのために割けるCPUリソースがない。
そこで、イベント処理型のバックアップシステムが必要とされてると思うんだけど。
とくにSANなどの外部共有ストレージが使えない低コストが求められる環境だとなおさら。

そういう需要って少ない？

186:login:Penguin
08/01/12 06:37:11 bmbAU9+b
スレ違いだが……

>>184
それで嫌韓連中を増やしたことが韓国のメリットになったのか？
アップルもしくはその支持者の戦略だとするなら、まずそこを
検討しているはず、と思うのだが。

187:login:Penguin
08/01/12 06:57:51 SErII+Xc
>それで嫌韓連中を増やしたことが韓国のメリットになったのか？

韓流ブームはTVと週刊誌で成立したものだと思ってるクチ？
その下地づくりが何時から始まったのか、調べてごらんよ

188:login:Penguin
08/01/12 07:07:04 bmbAU9+b
>>187
なにを示唆したいのか、さっぱり分からん。
てか、「ほのめかし」に終始して会話する気ないでしょ。

189:login:Penguin
08/01/12 07:22:17 SErII+Xc
理解する気がないくせに「会話する気がない」って何様

190:login:Penguin
08/01/12 10:50:20 4BgmnGqv
>>185
真にバックアップの必要なデータって極わずか。
それらが大量にあるというなら、それなりの
コストを払ってSAN上で２重化すれば。

つかCPUマシンとI/Oマシンくらい別にすれば。

191:login:Penguin
08/01/12 11:09:04 IDm5jJbB
>つかCPUマシンとI/Oマシンくらい別にすれば。

なんだその表現ｗｗｗ

192:login:Penguin
08/01/12 11:27:17 jzLk1uOI
>>190
SANが導入できる予算があれば苦労しないわけで。

しかしSANってかなりファイルアクセスコスト高いから、
大量の小さいファイル（HTMLとか）で
500GBとか占めてるサーバの差分バックアップ取ろうとしたら、
かなり時間掛かるんじゃないだろうか。
ブロックコピーだったら問題ないけど。

193:192
08/01/12 11:29:24 jzLk1uOI
SANはSANでも共有ファイルシステムを使った場合の話しね。

194:login:Penguin
08/01/12 11:52:55 4BgmnGqv
>>192
>大量の小さいファイル（HTMLとか）で
>500GBとか占めてるサーバの差分バックアップ取ろうとしたら

それらが本当にバックアップ対象なの？
差分とる必要があるなら、差分がとりやすいような構成に
するんじゃないのか。何も考えずに/varに500GBとか
やってるんすかね。

195:login:Penguin
08/01/12 11:55:47 yT37g0aU
>>185
そんなだらだらとしたバックアップが実際に役に立つと思いますか？
データの一貫性を保つためには、きちんと決められた時点のデータがすべて揃わないと何の意味も無いんですよ。
あなたみたいな、ハードウェア的な要件だけでしか物事を考えられないSEは邪魔なだけですよ。

196:login:Penguin
08/01/12 12:26:21 jzLk1uOI
>>194
HTMLの場合もあれば、2chのdatファイルのようなこともあれば、
Maildirのメールファイルのこともある。
HTMLやMaildirの場合はディレクトリ構成とかをこっちの自由にはしにくいから、
全体で差分バックアップを取る必要がある。

>>195
DBのバックアップじゃないから、OK。
HTMLの場合なんかだと、スナップショットを取る必要すらない。
決めつけの頭固いSE乙。

197:login:Penguin
08/01/12 12:30:53 iYG31qhb
Appleのドキュメント見に行ったけど、バックアップに使うというのは、
イベントによってファイルシステムのある瞬間の状態をとれるということだよね。
スナップショットをとってのバックアップだったらLVMとかでLinuxで既にやっているし？
あまりLinuxで似たような実装するとか(効果や労力の点で)考える必要ないんじゃない？
と思ったけど、そういうこととは違うの？

198:login:Penguin
08/01/12 12:43:43 jzLk1uOI
>>197
いや、違う。
例えば100KBのファイルが5000000個あるボリュームがあって、
それの差分バックアップを取りたい場合、前回との差を調べるだけで、
１～５時間ぐらい（バックアップ先やLAによって異なる）かかる。
でも実際にはほとんど更新されてなかったりして、
ファイルコピー自体は10分ぐらいで終わってしまったりする。

そこでどのファイルが更新されたのかをイベント処理によって検知して、
その更新されたファイルリストを作っておき、
そのファイルだけをコピーするようにすれば、
差分バックアップがあっという間に出来てしまう。
これなら１時間おきに差分バックアップを取ることも可能。

ってことをやりたい。

199:login:Penguin
08/01/12 13:07:29 iYG31qhb
ionotify APIを使えばできるようになるのかなあ
URLﾘﾝｸ(www.linux.or.jp)
うーん、これを利用するプログラムなら、もうあった気がする。
というかそのプログラムの説明でこのAPIを知った筈なんだが。

200:login:Penguin
08/01/12 17:24:53 Y+I93RRs
lsyncd
URLﾘﾝｸ(www.pri.univie.ac.at)
これか？

201:login:Penguin
08/01/12 17:37:47 zybZJIGE
で、ループしてinotifyは監視できるノード数に限界があって・・・、で戻る。
inotifyで/以下監視しようとするとさくっと死亡します。
ただし、/home以下ならユーザー数や利用のされ方しだいでは可能。

現実的な策としてAppleの実装は参考になるよ。
もっとも根底からinotifyとは違う方式なので、単にログサーバが
別途あればいけるというようなことにはならない＞Linux

202:login:Penguin
08/01/12 17:56:05 Bx7hU4VM
>>198
> HDDの障害はRAID構成で対処できるけど、
> RAIDコントローラーの障害、ファイルシステムの破損は、
> 結局外部メディアにバックアップしておくしかない。
> もし落雷や火事にまで対応するのなら、ネット経由でのバックアップが必要。

よくわからんが、その「どのファイルいぢったかイベントドリブンでメモしときましょう型」
バックアップってさ、結局そのメモスレッドが走ってるCPUマシンが障害起こしたら
おしまいじゃねーの?
バージョン(世代)管理型のバックアップでもないようだし
RAIDコントローラーの障害を心配して、RAIDにしない理由がいまいちわからん。
RAIDコントローラーを一枚(or一台)余計に
買って使わないで保存しとけば、RAIDでOKじゃね?

203:login:Penguin
08/01/12 20:48:27 1iC8xxCD
>>202
ID:jzLk1uOI はRAIDを使わないとは言ってないのでは？
RAIDがあってもバックアップは大切。
そのバックアップを早くしたいって話なんじゃないの？

204:login:Penguin
08/01/12 22:13:37 jzLk1uOI
>>201
同意。

>>202
203の通り。

>>203
代わりのレスあり。

205:login:Penguin
08/01/12 22:16:35 4BgmnGqv
>>204
金も知恵も使いたくないなら
RAID１やってバックアップとるとき抜いて、
別マシンで差分とればいいんじゃね？

206:login:Penguin
08/01/12 22:23:07 jzLk1uOI
>>205
RAID1の片方のHDD抜いたら、
ホットスペアディスクに転送始まって、
終わるまで重くてしょうがないよ。
それにわざわざデータセンター行かないとできないし。

207:login:Penguin
08/01/12 23:01:22 Bx7hU4VM
>>204
RAID5/6でもダメ?

バックアップ取りたいってのは分かる気がするけど
んーとさ、これってファイルシステムレベルで
やる話なのかな?って思った。

アプリケーションレベルで保存先二つにするとか、
ユーザのログアウト時にユーザの書き込み範囲だけ
バックアップ同期するとかそんなんでもよさげな気がす。

208:login:Penguin
08/01/12 23:28:26 gMk/W/4K
>>207
というかブロックレベルでやればいいよな、と思った。なに？EMC高い？AX4なら100万以下だぜ

209:login:Penguin
08/01/12 23:43:07 Bx7hU4VM
>>208　そりゃそれなら文句ないだろうけど。
ここの話で、確かにもう少しそういうものの小規模、低コストなものは需要があるのかもしれんね、とおもた。

210:login:Penguin
08/01/12 23:58:53 D/8nBsgE
クラスターファイルシステムもここでいいんかな？

iSCSI+ocfs2でファイル共有したいんだが、centos5.1とubuntu7.10だと同時にマウントできない
centos5.1同士、ubuntu7.10同士は問題ない

centos5.1がocfs2 1.2.7-1、ubuntu7.10がocfs2 1.24
バージョン違うと共有できんのかな？

gfs2はバージョン違うとダメだったりします？
ocfs2とgfs2のそれぞれの利点がさっぱり分かりません・・・

211:login:Penguin
08/01/13 10:03:01 Nollm+Al
>>210
基本的に、クラスタで両方からいっぺんにアクセスされる可能性があるものの場合は
バージョンをあわせなきゃダメだろ。バージョンが違うと言うことは機能に違いが
あるということなのだから。

212:login:Penguin
08/01/13 13:45:13 uE2Jrzt9
>>204
URLﾘﾝｸ(nzfug.nz.freebsd.org)
FreeBSDの話だけど。
ZFSでsnapshot作って、前回のsnapshotとのバイナリ差分をリモートに送信・同期させる方法。

213:login:Penguin
08/01/13 14:04:33 weLbJnIm
そういえばUNIXマガジン買ったやつはいないのか。

214:login:Penguin
08/01/13 14:42:06 T1kxn9Tz
>>208
そのAXなんちゃらEMかんちゃらも高いからなあ。
なら自分は手順覚えれば無料のを使った方がいいや。

215:204
08/01/13 22:38:13 PiB7mojI
>>207
> アプリケーションレベルで保存先二つにするとか、

Webアプリが出力したデータをバックアップするときは、この方法使うこと多いね。
けど、FTPでアップされたファイルとかだと
デーモンをいじらないと出来ないから、キツいねー。

>>212
おっ、これ理想的かも。

216:login:Penguin
08/01/14 00:20:29 qmocvwzd
NetBSD上でだけど、ファイルの書き込みや移動、削除が発生すると
ファイルパスを通知するファイルシステムを昔作ったよ。
理由はmknmzが毎度毎度ディレクトリを全部スキャンして遅かった
からなんだけど…。
既存のファイルシステム(overlay filesystem)のコードを流用したから、
結構簡単に作れたよ。

Linuxでも検討してみたけど、ファイルシステムの設計がスタッカブル
じゃないんで面倒臭くなってやめちゃったなあ。
今ならFUSEとunionfsを駆使すれば、同じようなことでできるんじゃないかな？

217:login:Penguin
08/01/14 00:37:09 6n5zEajJ
aufs使えばできそうだな。

218:login:Penguin
08/01/14 02:19:06 qPxdU3yy
vfsで実装

219:210
08/01/15 02:26:55 BF3bHG9k
>>211
やっぱそうですよね、合わせないとダメですよね・・・
ubuntuの方を1.27にしてみます

ocfs2とgfs2の違いは相変わらずよく分からん、ocfs2の方が設定簡単そうぐらいしか

220:login:Penguin
08/01/15 03:29:14 Ar++HS05
SDカードのFATエントリなんか他のエリアと比べて
何倍も書き換えられると思うんだけど
フラッシュメモリの使い方として問題ないの？

221:login:Penguin
08/01/15 03:30:48 jvp0V+W6
今はフラッシュメモリ側で散らす機能があるでしょ。

222:login:Penguin
08/01/15 03:40:12 Ar++HS05
ほー、なるほど賢いね。
カードに直接そういう機構がそなわってるってこと？
それともカードを扱う使用機器のドライバ側ってこと？

223:login:Penguin
08/01/15 03:42:21 edpzbljx
カード側で持ってるよ。アルゴリズムは各社の極秘中の極秘だそうだ
まあカードの書き換え速度や寿命に如実に影響する肝の部分だしな

224:login:Penguin
08/01/15 03:54:19 Ar++HS05
なるほどありがとう。
しかしそうするとメモリーカード上のフラグメンテーションって
純粋に仮想的なもので実測には影響しないのかな。

225:login:Penguin
08/01/15 03:57:55 edpzbljx
フラッシュメモリはSDRAMみたいにバーストリードで速度が上がるとかいう要素は無いだろう
ランダムリードと言っても元々数KB～数十KB単位のセル単位で読み書きだし

そのセルが物理的に離れた箇所にあったとしても、スピンドル回してヘッドがギコギコ動く訳じゃないから
どれだけアクセス時間がかかるかとかはほとんど誤差の領域じゃないかねえ
まあ俺も素人だから正味のところはわからんが

それよりもコントロールロジックの処理速度の方が遥かに影響が大きそうだ

226:login:Penguin
08/01/15 04:23:10 RzvkwwJj
知ってる方がいたら教えてほしいのですが、ext3のdata=journalのモードってのは
本当にフルデータジャーナリングなのでしょうか。メタデータだけじゃなくて、データ
の変更についてもジャーナルログに書き出してるんでしょうか。

大抵の文書には、
「フルデータジャーナリングじゃ」だから「2度データが書き出される」と書いてあるのですが、

@ITの記事によると「journalモードではディスクへの書き込みが完了したことを確認してから
ジャーナリングの記録を行う」とありまして、同期書き込み＋メタデータジャーナリングのよう
な解説をしてあります。これだとデータの書き出しは1度だけです。
URLﾘﾝｸ(www.atmarkit.co.jp)

詳しく解説してあるので、@ITの方が正しいような感じがするのですが、どんなもんでしょう。

それからもう一つ疑問なのですが、フルデータジャーナリング使うぐらいなら
同期マウントした方が良い気がするのですが間違ってますか？
（同期マウントでもメタデータの更新中に停電したらアウト…なのかな）

アホな質問ですいません

227:login:Penguin
08/01/23 01:52:59 N7D3q8Og
ここで言う同期マウントって例えば？

228:login:Penguin
08/01/23 13:49:47 1HOl8oN3
-o sync, dirsync

229:login:Penguin
08/01/23 14:27:45 l6jXIqfH
同期モードでmountしている状態でもクラッシュしたらfsckが必要ですし
実現できる機能が違いますよね

230:login:Penguin
08/01/25 05:13:31 V+xKWgCR
そもそも同期モードで書いてる途中で落ちたとして、
どこまで何を書いたかは誰が覚えてるんだろうねぇ？

231:login:Penguin
08/01/25 19:51:15 OAhQQFKa
誰も覚えていない。
書き込みそのものがなかったものになるだけ。

232:login:Penguin
08/01/26 07:10:51 nkamkNao
それはジャーナル有る場合だろ

233:login:Penguin
08/01/26 07:50:09 8OpwyOTH
はあ？

234:login:Penguin
08/01/26 14:24:53 nFnPAV3G
同期・非同期とトランザクションの区別はつけようぜ。

235:login:Penguin
08/01/26 15:24:51 Pvih2f3X
>>232
fsckでなかったものにされるんじゃね？
ジャーナルなんて関係ないでしょ。

236:login:Penguin
08/01/26 15:53:50 8QyNar63
>>235
fsckすると残りのジャーナルを適用することもある。
どっちが整合性を保ちつつデータを保全できるかによるようだ。

237:login:Penguin
08/01/26 17:14:55 X0RlC9mR
ちょっとまて >>226の
>フルデータジャーナリング使うぐらいなら同期マウントした方が良い
かどうかだろ
ジャーナリング無しで同期書き込みしたらfsckでロールバックかかるってこと？？

238:login:Penguin
08/01/26 17:25:57 IqVOKU/f
ちゃんと流れ読めよ

239:login:Penguin
08/01/26 19:00:37 Pvih2f3X
>>236
なんでそうなるのか、それがわからん。
同期の場合は、sync（）にしろwrite（）にしろ、書き込みがすべて終わるまで戻ってこないんでしょ？
対象がジャーナルFSであっても。

>>237
fsckで行う作業をロールバックというな。

240:login:Penguin
08/01/26 21:51:13 X0RlC9mR
状況がよく分からんのだが、ファイルの内容書き換え中に落ちたとして、
fsckでどうやってロールバックされるわけ？
>>230な状況になるんじゃないのか

241:login:Penguin
08/01/27 01:29:39 LrB7nbuV
RDBMSの場合は、SQLレベルでの論理的な操作すべてが記録されているから、
直前のバックアップデータに対してログをリプレイすることで、完全復旧ができるというわけだが、
ファイルシステムに当てはめて考えれば、バイトレベルの操作すべてに対してログが採られていなければ、データの中身までは保障できないということになる。
現実的には、そんなことしてたらログの量がとてつもなくなるから、到底無理な話。

ジャーナルFSが復旧処理でやっていることは、通常のfsckがすべてのファイルに対して実行する検査を
ログをなめることで省略しているにすぎない。
当然、正常に閉じていないファイルは、問答無用でlost+found逝きとなる。
これをロールバック/フォワードなどという言うには違和感あるでしょ？

242:login:Penguin
08/01/27 03:02:00 i1WeOFxf
>>241
データについてもする場合はopen以後のwriteは別領域に書いて、
適当なタイミングでFS構造からの参照を付け替えればいいだけ。
この場合、write中にクラッシュした後の復旧でロールバックする。
ただし XFS とかの実装だとcreat自体はコミット済みだから
０バイトファイルが残ってくれたりとある意味困った挙動になったり。

さらに進んでNTFSとかreiser4ではアプリ側からトランザクション性を
制御した書き込みができる（た？）はずだけど、どういう形なんだっけ？

あとfsckがやってるのは正常に閉じられなかったファイルではなく、
参照があるのに参照先がないとか、参照がないのに実体があるとかの
FS構造としての不整合状態をブロックをなめて発見したものを
lost+foundに集めたりクリアしたりしてるだけで、閉じられなかった
ファイルを救ってるわけではない。

243:login:Penguin
08/02/02 17:24:24 Sk+gOLYe
どこのスレが該当するかわからんがとりあえずここに。
mdadmでraid1構築、ocfs2にフォーマットしてマウントは問題ないんだが、
raid0とraid10で同じ事をやると失敗する。
(ひとまずローカルディスクで実験してます。最終的にはiSCSIを複数使ってやる予定)

以下マウント時のエラー
ocfs2_hb_ctl: I/O error on channel while starting heartbeart
mount.ocfs2: Error when attempting to run /sbin/ocfs2_hb_ctl: "Operation not permitted"

/etc/init.d/o2cb statusすると確かにハートビートが動いてない。
んで手動でocfs2_hb_ctl -S -d /dev/md7(作ったRAIDデバイスがmd7)実行するも
ocfs2_hb_ctl: I/O error on channel while starting heartbeart
でダメ。

これはocfs2の仕様なんですかね？GFS2だとなんとかなる？
clvmで-iと-mのが可能性あったりするのかなあ、もうわけわからん

次ページ