07/09/26 15:39:21 VZk+Fjj0
過去スレ
01 ｽﾚﾘﾝｸ(linux板)
02 ｽﾚﾘﾝｸ(linux板)
03 ｽﾚﾘﾝｸ(linux板)
04 ｽﾚﾘﾝｸ(linux板)
05 ｽﾚﾘﾝｸ(linux板)
06 ｽﾚﾘﾝｸ(linux板)
2:login:Penguin
07/09/26 15:40:20 VZk+Fjj0
関連リンク
ext4
URLﾘﾝｸ(www.bullopensource.org)
reiserfs/reiser4
URLﾘﾝｸ(www.namesys.com)
xfs
URLﾘﾝｸ(oss.sgi.com)
jfs
URLﾘﾝｸ(jfs.sourceforge.net)
nfs
URLﾘﾝｸ(nfs.sourceforge.net)
ntfs
URLﾘﾝｸ(linux-ntfs.sourceforge.net)
fuse
URLﾘﾝｸ(fuse.sourceforge.net)
関連スレ
[次世代] ZFS Part2 [ﾌｧｲﾙｼｽﾃﾑ] [UNIX]
ｽﾚﾘﾝｸ(unix板)l50
ジャーナリングファイルシステム [UNIX]
ｽﾚﾘﾝｸ(unix板)l50
FS関連スレ [OS]
ｽﾚﾘﾝｸ(os板)l50
3:login:Penguin
07/09/26 18:22:54 wVYv9yLG
おにぎり。
4:login:Penguin
07/09/26 18:55:50 fkqYAask
漢字Talk7.1なんて知りません
5:login:Penguin
07/09/26 21:23:16 Wnx9Obs/
>>5はシャブおじさん
6:login:Penguin
07/09/26 22:02:44 IxHQdjkm
>>1-2
乙。
>>3-5
スレの最初なんだから挨拶くらいしろよ。
そんなだから社会で(ry
7:login:Penguin
07/09/26 23:34:11 IayyRUIJ
ext3 って mke2fs で明示的に -j つけないとダメよね？
前スレの 991 に聞きたいんだが。
8:login:Penguin
07/09/26 23:41:13 Wnx9Obs/
-j付けないとext2じゃん？
9:login:Penguin
07/09/26 23:42:13 mD6yA1Cq
>>6
謹んで新スレのお慶びを申し上げます。
前スレ中はひとかたならぬご厚誼にあずかりまして、厚くお礼申し上げます。
ご家族の皆様のご多幸をお祈り申し上げます。
10:login:Penguin
07/09/26 23:56:57 fwXIpG1j
mkfs.ext3
11:login:Penguin
07/09/27 00:07:22 jAMuA/Sw
ext3って巨大なファイルの削除、めっちゃ遅くない？ ext4で速くなるのん？
12:login:Penguin
07/09/27 07:43:36 c5i0QVCt
Just do it!
13:login:Penguin
07/09/27 08:17:04 YniL8R4M
おにぎり
14:login:Penguin
07/09/27 17:29:34 +635kBxg
新スレ乙。
漏れのext3は、btreeが有効になっているか確認する方法キボンヌ。
っていうか、ext3にbtreeなんてあったのか・・・鬱。
15:login:Penguin
07/09/27 17:44:26 CjJ3eVte
tune2fs -l /dev/XXXしてFilesystem featuresにdir_indexがあればおｋ
16:14
07/09/27 18:09:24 +635kBxg
>>15
サンクスコ、CentOS5はデフォであった。
これはすでに機能しているという意味？それともdir_indexサポートしてるよって意味？
17:login:Penguin
07/09/27 18:18:23 uExRxqAO
>>16
つman mke2fs
18:login:Penguin
07/09/27 21:39:39 1VnkPk49
>>16
CentOS 4の2.6.9カーネルにはないね。
19:login:Penguin
07/09/27 21:48:01 l1697NrL
oioi
20:login:Penguin
07/09/27 22:09:40 3eLY41rB
なに その 太古の カーネル
21:login:Penguin
07/09/27 22:21:44 YWxRT+vC
>>18
ﾊｧ? これが実装されたのは2.5.42だ
2.6.9にないわけがない
22:login:Penguin
07/09/27 22:29:19 akzcgiqo
>>21
CentOS 4のインストーラーがdir_index無しでmkfsしてるんじゃね？
23:login:Penguin
07/09/27 22:32:53 vrN2mNRI
ext3のディレクトリエントリはhtree(ハッシュツリー)
で管理しているんじゃないの？
24:login:Penguin
07/09/28 01:24:07 fGy6KcFJ
>>18
あ、ごめん、あったあった。
CentOS4のインストーラーで作ったパーティションにはあった。
見てたシステムのディスクは2.4 カーネルからも時々マウントする
必要もあるという特殊事情でわざわざこれらの新しい機能を除いて
mkfsしてたのを忘れてた。
25:login:Penguin
07/09/28 17:29:39 X8XvEBl4
NTFSのジャンクションとシンボリックリンクとハードリンクを正しく扱ってくれるものがほしい。
うちじゃNTFSでジャンクションとシンボリックリンクとハードリンクをガンガン使いまくってるから
Linuxからマウントすると何が何やらさっぱりな状態になってしまう。
26:login:Penguin
07/09/28 17:31:47 Q2R5taht
>>25
最初からNTFS使わなければいいんじゃないか？
27:login:Penguin
07/09/28 18:06:55 JX2W1VWp
NTFSにシンボリックリンクってあったんだ・・・
28:login:Penguin
07/09/28 18:24:18 X8XvEBl4
>>26
外付けの持ち運び用2.5吋HDDはWindowsと共用だからNTFSにしなきゃならない。
ＦＡＴなんか使ってられない。
>>27
あるよ。
隠し機能だからエクスプローラやCMD.EXEではシンボリックリンクを張ることはできないけど、
読むだけならちゃんと読んでくれる。
張るにはLINK.EXEを使うか、
またはシンボリックリンク対応のファイラー等を利用することになるけど。
29:login:Penguin
07/09/28 18:35:08 6S57Qy5A
NTFSはジャンクションという、シンボリックリンクによく似た機能で、
シンボリックリンクはないんじゃない?
あるのは、ジャンクションとハードリンクでしょ。
んで、共用?ディスク、しかも持ち運び用ファイルシステムで
NTFSの標準で利用できない機能を利用するという運用方法自体に
問題があると思うのだが。
NTFSはマイクロソフトが仕様を公開していない以上、アクロバチックな方法を
模索するのはリスクが大きいので、ジャンクションなどの仕様を止めた方が賢明だと思う。
30:login:Penguin
07/09/28 18:36:16 ZQh/z4sn
symlinkはVistaから隠し機能じゃなくて正式にサポートされたんじゃなかったっけ?
これはどう?
俺は使ったこと無いからどの程度動くのか知らないけど。
URLﾘﾝｸ(www.ntfs-linux.com)
31:login:Penguin
07/09/28 18:40:40 X8XvEBl4
>>29
ジャンクションとシンボリックリンクは違う。
NTFSには両方ある。
32:login:Penguin
07/09/28 18:44:34 6S57Qy5A
Vistaからシンボリックリンク使えるようになったんか。しらなかったわ。
33:login:Penguin
07/09/28 19:00:42 X8XvEBl4
いや、2000からある。
34:login:Penguin
07/09/28 19:24:44 6S57Qy5A
いやだからそれはシンボリックリンクではなくジャンクション・・・
シンボリックリンクはVistaから導入されたらしい。
URLﾘﾝｸ(www.microsoft.com)
URLﾘﾝｸ(ja.wikipedia.org)
35:login:Penguin
07/09/28 19:27:46 jELIQobq
linkdだっけ。あれで作ったやつをdirでみると＜JUNCTION＞って表示されたんだよね。
それにしても、ntfs-3gからどう見えるんだろう。
俺も使ってないし＜ジャンクションとかシンボリックリンクとか。
試すのはNTFS壊しそうで怖い…。
36:login:Penguin
07/09/28 19:31:24 hjsOlEXz
ジャンクションはハードリンクみたいなものじゃなかったっけ？
ntfs-3gでは暗号化も圧縮もダメなんじゃないかなぁ？
おれはcaptive使ってるけどｗ
37:login:Penguin
07/09/28 19:55:39 X8XvEBl4
>>34
2000からシンボリックリンクもジャンクションもあるって。
今まで隠し機能だったものがVistaでやっと公開されただけ。
じゃあ、現にシンボリックリンク使いまくってるうちの2000はパチモンなのか？
38:login:Penguin
07/09/28 20:14:03 X8XvEBl4
証拠。
上から順にハードリンク、元ファイル、ショートカット、シンボリックリンクね。
シンボリックリンクはハードリンクと違ってファイルサイズが0だ。
しかし、ちゃんと元ファイルと同様に扱えるし、このISOをマウントすることもできる。
URLﾘﾝｸ(www.imgup.org)
39:login:Penguin
07/09/28 20:22:29 l1pVH9VE
シンボリックリンクってファイルサイズゼロじゃないんだが。
ジャンクションをシンボリックリンクに見せかけていただけだっていう話はもう出てただろう？
40:login:Penguin
07/09/28 20:30:37 6S57Qy5A
>>38
だからそれ、ジャンクション・・・
ここでも読んで勉強した方がいいよ。
URLﾘﾝｸ(homepage1.nifty.com)
41:login:Penguin
07/09/28 20:32:25 X8XvEBl4
ジャンクションはディレクトリに対してしか張れない。
ここの説明を読んでみな。
URLﾘﾝｸ(homepage1.nifty.com)
＞Windows 2000/XPの標準でもWindows Vistaのシンボリックリンクを作成はできますが、作成したリンクをたどれません。
＞そこでシンボリックリンクへのアクセスを提供するドライバ(symlink.sys)と、
＞ドライバをロードするためのツール(senable.exe)を作成して同梱しました。
42:login:Penguin
07/09/28 20:40:50 FokR087f
それは2000のツールじゃなくって、NTFS5の機能を有効にするフリーソフトの機能だろうが！
43:login:Penguin
07/09/28 20:53:55 X8XvEBl4
だからNTFSにはそういう機能があるけど、
標準ではサポートされてなかったということなのだ。
それがVistaで初めて標準でサポートされるようになったのだ。
44:login:Penguin
07/09/28 21:49:51 WsNinqHh
標準シェルを含む通常のシェルから
シームレスに使えないんだったら
正直混乱させるだけじゃなかろうか。
45:login:Penguin
07/09/28 22:02:13 JX2W1VWp
>>41
ドライバを入れなくては見れないものを、Windows2000でもその機能があった、という・・・
そこがおかしい部分なんですよ。
FATにはディレクトリを表現する機能がありましたが
MSX-DOS1では、ディレクトリを扱えませんでした。
CDコマンドが無いのです。
このときMSX-DOS1でもディレクトリが扱える、と表現するのは誤解を招きやすいです。
46:login:Penguin
07/09/29 01:10:25 c75YhqoT
2000/XPにもシンボリックリンクは、あった。
ただしNTFSのドライバ内でdisableになっていた。
何らかの手段でenableにすれば、ジャンクションでもハードリンクでもなく、
ファイルに対するシンボリックリンクが作れて使えた。
Vistaで正式にサポートされたシンボリックリンクは、微妙に2000/XPのものと仕様が異なる。
このため、Vistaで製作したシンボリックリンクを2000/XPで使うためには、
使用の差異を吸収するドライバが必要になる。
結論。2000/XPでは隠し機能としてシンボリックが存在した。
2000/XPとVistaのシンボリックは微妙に別物。ほかに質問ある？
47:login:Penguin
07/09/29 01:24:33 qvb3vLW1
そもそも最初にNTFSの話題をしてきたのは>>25のID:X8XvEBl4だったのでは。
結論：スレ違い。よそでやれ
だな。
48:login:Penguin
07/09/29 01:43:10 4wXsAH2m
というか、みんな白けて相手にしていないことに気づけ。
49:login:Penguin
07/09/29 02:14:40 hRmV2en9
そもそもジャンクションとシンボリックリンクって
どういう用途で使いわけるの？
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特有のリソースフォークのことでそ
URLﾘﾝｸ(ja.wikipedia.org)
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のが可能性あったりするのかなあ、もうわけわからん
244:login:Penguin
08/02/06 21:12:32 xB+Vp2Cl
トーバルズ：OS XはVistaよりマシ、でもファイルシステムはゴミ
URLﾘﾝｸ(japanese.engadget.com)
ktkr
245:login:Penguin
08/02/06 21:24:53 xsQFoZY7
誰か言ってやってくれ
LinuxはServer2008よりマシ、でもファイルシステムはゴミ
246:login:Penguin
08/02/06 21:35:04 CEBTMN4n
>>245
いやそれは逆だろ。
ファイルシステムはマシだが・・・。
247:login:Penguin
08/02/06 21:43:01 bycraF9D
NTFSってどうなん？
248:login:Penguin
08/02/06 21:45:17 AbBwRF41
ゴミ
249:login:Penguin
08/02/06 21:45:58 kmV4D3eE
速度的に光るものはないが、耐久力はゾンビ級。
ext3なんかよりよっぽど優れたfsだと思うんだけどな…
250:login:Penguin
08/02/06 21:59:15 MW2Uiq4L
>>249 それ賛同
251:login:Penguin
08/02/07 00:55:39 Jh0j2rM7
リーナスってバカだな
252:login:Penguin
08/02/07 03:33:18 UdsqPHwZ
ntfsでファイルがぶっ飛んで破片も出てこないのはプログラムが悪いの？
253:login:Penguin
08/02/07 10:56:01 NVBqFf6j
俺なんかはntfsよりreiser・・・じゃなかった、xfsで何事も無かったように再起動できたことに驚愕したものだが。
ntfsだとどっか壊れるよなーという落とし方をしてしまった時のことだ。
まぁxfsはfsckしないからというのもあるだろうが。
254:login:Penguin
08/02/07 11:16:04 JbuBRM/5
>>253
どこかに0バイトのファイルが転がってるかもよ。
255:login:Penguin
08/02/07 17:47:13 nagQT8db
ちなみにどういう落とし方したの？
256:login:Penguin
08/02/07 18:16:17 lsDyIYji
酒を飲みつつ恋愛論を語った
257:login:Penguin
08/02/07 18:26:42 MhI2GJBO
たしかにntfsだとぶっ壊れそうだ。
あとできちんとf*ckしとけよ。
258:login:Penguin
08/02/08 02:06:16 5Qp7toYJ
いったいなんのスレだよw
>>253
xfsはマウント時にfsckするんじゃなかったっけ？
259:login:Penguin
08/02/08 02:20:17 SRnPVqDy
>>258
昔のxfs_fsck.c
int
main(int argc, char **argv)
{
return 0;
}
今はshell scriptになったな。
260:不明なデバイスさん
08/02/08 07:58:24 YoHKP6tC
>>198 索引の更新日付は収容ファイルの更新で変更になる、
だから索引の更新日付をチェックして前回バックアップした日付以前なら
その索引直下に収容のファイルは対象外にできる、
そうすれば処理時間は一桁以下にできるのでは。
261: ◆YtPQzYyEH.
08/02/08 15:40:09 C4+Xg+NF
262: ◆JuFLxjEbXg
08/02/08 15:42:03 C4+Xg+NF
な
263:login:Penguin
08/02/08 16:39:10 lO2z0Hih
NTFS自体は機能とパフォーマンスを考えたら
PC用のファイルシステムではトップクラスじゃねーかと思う
大元のHPFSが優れていたんだろうな
しかしNTやVistaでさえその機能をきちんと使っていない点でクソ
それとフラグメント化が激しすぎるのもクソ
HFSは褒める部分を探すのに苦労して苦労して、それでも何も見つからないくらいにクソ
さらにそれを告げると信者が火病起こしてわめきだすのがさらにウザくてクソ
ext系は、とりあえず動きますよって段階では不満は無いんだが
それ以上のものでもないし、お世辞にも優れた部分は見出せない
偉大なる平凡
xfsは、こんなもんタダで使わせてもらって本当にいいんスか？って感じだな
jfsは知らん
reiser fsはこれからどうなっちゃうの？って感じ
264:login:Penguin
08/02/08 16:49:38 B7rrj2AA
NTFSは異常終了無しで半年使って、chkdskかけたら数千ファイルのaclが吹っ飛んだことがorz
FSが問題なのかどうか微妙なラインだが手痛かった。
xfsはcronでデフラグかけてるといい感じでうごいてる。
reiserは・・・ボリュームでかいとマウント時にものっそ時間かかるんだが・・・
265:login:Penguin
08/02/08 18:25:44 WpMOTmXO
xfsは古いマシンで使うぶんには良いんだけどね。
新しいserverに入れる気はおきないな、mlみてたら怖くて。
266:login:Penguin
08/02/08 18:42:58 PGSC+VCd
>>264
それはどんなファイルシステムでも書き込んだ後1度も読み取りもしなかった領域が
不良セクタ化したらウンコーッ って話だろ。
267:login:Penguin
08/02/08 18:47:17 oKxB/QKg
>>265
新しいマシンだと何か不具合出るの？
最近のコードが安定してない、って話なら分かるけど。
268:login:Penguin
08/02/08 22:53:36 5Qp7toYJ
xfsはシュルシュル、reiserfsはヌルヌル。
性能いいのはreiserなんだろうけど、
xfsはそこそこ性能を発揮して低負荷。
>>259
あーあー、そうだったそうだった。
月イチxfs_check使ってるので忘れてたわ。
269:login:Penguin
08/02/09 11:55:22 I5g2yu0o
>>264
MSKB831374、831375、327009、873437とか該当してなかった？
270:login:Penguin
08/02/09 12:20:37 woPPxICV
xfsはファイルの削除が遅い。カーネルツリー削除するのに時間がかかるよー。
271:login:Penguin
08/02/09 13:11:25 aL9fnslD
削除なんてバックグラウンドでやらせときゃいいじゃん
272:login:Penguin
08/02/09 13:18:17 JxDwlQM6
>>266
いやRAIDだし不良セクタ関係ないw
ハード障害に対するFSの耐久性の話ではない。
273:login:Penguin
08/02/10 21:20:25 zTNy08k4
3wareのRAID板で1TB*3のRAID5を構築したのですが、
Linuxのファイルシステムとしてデータ領域に適しているのはどれになるんでしょうか？
CPUはGeodeNXのDualなのでパワーはあまりありません。メモリは2GB積んでます。
reiserfsとXFSとで検討の枠を絞ってしまっていいものか、
最近のトレンドが分からないのでご意見ください。
現状持ってる数年前のイメージでは以下の感じ。
XFS
○ ファイルシステムが大きくてもマウントが早い
○ あまり負荷がかからない
○ reiserfsより早い
× ファイルの削除が遅い
× fsckちゃんとしてるのかよく分からない・・・
reiserfs
○ ファイルシステムの縮小が唯一できる
× ファイルシステムが大きくなるとマウントが遅い
最近はどうなんでしょうか？
274:login:Penguin
08/02/10 21:29:22 GwVP/ZS2
>>273
個人で使うなら大して変わらないから好きなの使えば?
275:login:Penguin
08/02/10 21:33:29 BEDS9Otr
個人で1TBx3か？すごいな
276:login:Penguin
08/02/10 21:43:31 GwVP/ZS2
>>275
1TB 2.5万だからちょっとしたおもちゃだろ？
277:login:Penguin
08/02/10 22:46:57 41EqjFSS
1Tx3が2.5万x3
ML115が1.5万
メモリ2Gを0.5万で追加したとしても
9.5万で2TなNASが用意できる時代ですぜ。
278:login:Penguin
08/02/10 22:52:26 kPqZgS0L
知らない間にバカ安になってるな。
うちのノートPCのHDDも取りかえたい。
279:login:Penguin
08/02/10 23:13:04 jaGVAHE6
1Tも入れるものが無い
280:login:Penguin
08/02/11 00:55:40 v/vK9WxC
>>273
どちらが良いとは言わない、だがこれだけは言わせてくれ。
・xfs_repair ＆ xfs_check は、1TB につき 1GB のメモリが必要。
・プロセス毎で使えるメモリ量は限られている。(特に32bitな環境では)
・メモリを増設しても、プロセス毎で使えるメモリ量は変わらない。
281:login:Penguin
08/02/11 00:57:39 NXuZoz9l
>>280
>・xfs_repair ＆ xfs_check は、1TB につき 1GB のメモリが必要。
すごくフラグメントしてたり、むちゃくちゃになってしまった時に
必要なだけで、普段はそんなに要らない。
もっともcheckやrepairが必要なときは、かなり終わってるけどな。
282:login:Penguin
08/02/11 12:55:43 hHXFn50e
>>281
> > xfs_repair ＆ xfs_check は、1TB につき 1GB のメモリが必要。
> すごくフラグメントしてたり、むちゃくちゃになってしまった時に
> 必要なだけで、普段はそんなに要らない。
俺は、良く聞く4MB/i-nodeにつき128MB/RAMという、xfs_repairの昔からの定説から
1TBならi-nodeはおよそこれ位だから、RAMはだいたい1GB的な一般解を>>280は導いてきたと思ったんだが
i-nodeの大きさだけじゃなく、フラグメントも関係あるのか？
俺はツーリングとか、息子の運動会、家族旅行で流し撮りした映像の置き場や、編集用として
WD7500AAKS×4を2410SAでRAID5運用していたわけだが、RAMは1GBしか積んでない
当然中身はGBオーバーの動画ファイル群のみ
だが突然の電源断や、停電などで落ちた際にxfs_checkをかける時でも、これまで一度として
メモリが足りなくなったりしたことはこれまでなかった
俺はこれをエクステントが効いている為に、i-nodeの大きさ自体はそれほど増えていないからだと
理解していた訳なんだが、もしフラグメントが関係しているなら、一度もxfs_fsrをかけたこともなく
使用量も80%を余裕で超えているこのディスクは、相当に断片化しているはずなんだけどな
283:login:Penguin
08/02/11 13:01:33 L4qR2Tu7
フラグメントは関係ない
284:268
08/02/12 02:16:28 XWn0I4iF
>>280
システム移行時にサブ(メモリ256MBのP3)機で1.5TBのxfs_checkしたけど、
メモリ食う仕様忘れててswapディスクなしだと見事に固まったな。
低速ながらswapディスク付けたら一晩ちょいでどうにか終わってた。
285:login:Penguin
08/02/14 10:51:10 U8W3css3
URLﾘﾝｸ(www.smalltown.ne.jp)
おれもxfsってたまに重くなると思ってた。
こういうのもログを別ディスクにしたら性能あがるのかね
286:login:Penguin
08/02/14 10:57:56 S8QS6vkZ
>>285
swapに追い出せないジャーナル用のメモリを他のアプリや
カーネルと取り合いしてメモリ上でスラッシングしている
んじゃないかな。
287:login:Penguin
08/02/14 10:59:02 S8QS6vkZ
だから、高速なディスクに素早くジャーナルを書き出せれば
起きないのではないかと思う。
288:login:Penguin
08/02/16 10:58:54 1+pZMLPj
>>281
xfs_repair,xfs_checkは正常にマウントできなくなった時に使う。
１TB当たり1GBは正解。
ただし、今じゃxfs_repair -L位しか使った記憶ないなぁ
289:login:Penguin
08/02/21 00:04:34 Qe0QvPTZ
SuSEでブート領域を外部ディスクにして使ってます。
その外部ディスクが停止したりしてI/Oが一時的にでも停止すると、
ext3 が即座に Read-only で自動的にリマウントされます。
調べたところこれはext3(ext2)の仕様のようですが、どうにかして
リブートせずに Read-write でリマウントできないでしょうか？
今まで試したことは以下の通りです。
1. mount の remount オプションの使用
2. マウントしたまま fsck をかけた後、1を実施
tune2fs のエラー発生時のハンドリングは Continue になっています。
スレ違いでしたらすいません。
290:login:Penguin
08/03/02 13:54:44 hc9C85N7
1FSあたりのファイル,ディレクトリ数って、増えすぎると速度落ちるよね？
その辺のデータって詳しいサイト無いかな。若しくは影響出やすいFSの体験談とか。
1ディレクトリに大量ファイルってのはまたちょっと別なんだけど。
291:login:Penguin
08/03/02 13:57:47 e0Thmhwp
それはフラグメンテーション
292:login:Penguin
08/03/02 15:02:36 hc9C85N7
あぁ、ファイルの読み取り速度とかディスク速度とかじゃなくて、
ファイルへのアクセス速度(fopen完了までとか)ね。
293:login:Penguin
08/03/02 15:09:57 e0Thmhwp
それもフラグメンテーション
294:login:Penguin
08/03/02 21:13:23 hc9C85N7
なんのこっちゃ・・・
えーとじゃあ、デフラグした状態で。
295:login:Penguin
08/03/02 21:19:19 1ooFJNDl
>影響出やすいFS
FATとかか？
296:login:Penguin
08/03/02 22:01:33 QO19JZJo
実装を別にしてもあれが糞なのは疑いようがない
297:login:Penguin
08/03/02 22:03:01 88VAzaOv
手軽さと互換性をちょっとは評価してもいいとは思うが
298:login:Penguin
08/03/03 14:31:32 olTABkIp
NTFSはドライブ内のファイル数が増えてくると急に遅くなる気はするな
MFT周りなんだろうけどよくわからん
FATは論外として、xfsもファイル数増えるとなんかもっさり。
reiserは結構耐える感じ？ まnotailとかのオプションにもよるだろが
299:login:Penguin
08/03/03 15:01:41 JCTvrwL7
単純にindexが肥えていじるのに時間かかるようになるから。
ファイルシステムは大体そういうものだ。
reiserはそういう状況でもそれなりに動く様に設計されとる。
300:login:Penguin
08/03/03 15:08:13 8CT1QtMK
ここまで客観的な数値ゼロ
301:login:Penguin
08/03/03 17:34:55 QQPe3/34
>>290が体験談を望んでるから妥当な流れ
別に有ってもかわまんので書いてくれても良いよ>>300
302:login:Penguin
08/03/03 19:17:19 ic5kxWI3
xfsに変えたら彼女ができました！
303:login:Penguin
08/03/03 20:25:58 i1bQg1Re
reiserfsに変えたら妻が失踪しました！
304:login:Penguin
08/03/03 20:59:30 vUAhW00A
zfsはどうなんだろうね、ｌｉｎｕｘでも早いところつかえるようにならなかね
305:login:Penguin
08/03/03 23:37:31 aMHSs4ys
jfsに変えたらサーバが青いタワー型に！
306:login:Penguin
08/03/04 00:03:47 MG8dmV58
>>305
逆だろ、それ。
307:login:Penguin
08/03/04 00:40:55 mPcUgsuW
>>303
そういや、あれってどうなったんだろ。
保釈されたんかな？殺人容疑だからありえないか。
308:login:Penguin
08/03/04 13:36:55 luMzogFa
Reiserfsってどの程度のファイル数耐えられる？
ext2みたく酷くはないと思うが怖くて使ってない
309:login:Penguin
08/03/04 20:56:04 2F2RseEP
inodeが動的にあれだからなあ。
結構いくと思うけど。
310:login:Penguin
08/03/04 21:53:43 kk4vfn0k
参考までにどぞ。
TimeMachineに頼れない人のための完全バックアップ方法：日経パソコンオンライン
URLﾘﾝｸ(pc.nikkeibp.co.jp)
311:login:Penguin
08/03/16 21:01:35 flqkXLd1
ディレクトリエントリつーの？findしたときに読まれるデータを、
優先的にキャッシュに残しとくFSとかオプションとか無いかね。
312:login:Penguin
08/03/17 10:38:08 4IyCtHoK
それは FS というか単にキャッシュのアルゴリズムでは?
313:login:Penguin
08/03/17 12:26:47 7b6j/OHS
キャッシュバッファのレイヤですな
314:login:Penguin
08/03/17 14:54:29 nm4uxoxm
普通はページキャッシュかブロックバッファと言わないか？
キャッシュバッファだと馬から落馬みたいだ
315:login:Penguin
08/03/17 15:22:06 pTUBucW/
>>311
Linuxならディレクトリエントリキャッシュはあるけど。
316:login:Penguin
08/03/18 01:32:40 jCQs8JOZ
>>314
buffer cacheといいたかったんだろう。
317:login:Penguin
08/03/23 15:41:33 NvqLU+q0
>>316
しかしバッファキャッシュはfindの高速化になんの関係もないので本来の意図は
i-cache, d-cacheではあるまいか？
318:login:Penguin
08/03/23 16:57:13 4i3/VEiN
>>317
通常のファイルシステムでは、ファイル名ってのはdirectory fileに格納されているので、buffer cacheは関係なくはないんじゃね？
むしろdirectory entryのcacheはfindには関係なくないか？
inodeのcacheを使うかどうかもfindのオプションによると思う。
319:login:Penguin
08/03/24 11:41:29 xCc6BPh+
そのへんよくわからんな
Linuxのディスク～fs～buffスレとか無いものか
320:login:Penguin
08/03/28 22:28:36 26zHaioF
UBI File System
URLﾘﾝｸ(kerneltrap.org)
321:login:Penguin
08/03/29 21:41:44 f/e2EUT3
>>320
JFFS2のスケーラビリティーが悪すぎたので１００倍程度では心元ない
322:login:Penguin
08/03/30 04:13:47 GQ0aE0r7
ext4dev は早く正式なext4にならないかな
323:login:Penguin
08/03/30 11:01:12 IoGJIZKZ
ext4絡みでVFS廻り、相当変わってる？
324:login:Penguin
08/03/30 12:32:47 pKiGTBVm
>>323
変わってませんので安心してFUDをお続けください。
325:login:Penguin
08/03/30 14:13:24 o6yKIr3w
ext3はjbdが1スレッドしかいないおかげで、しばしばこいつがボトルネックになったけど、
ext4では改善されるんかね？
XFSみたくノード毎にほしいよね
326:login:Penguin
08/03/30 15:22:11 IoGJIZKZ
いや、最近のxfsのアホみたいな変更の量は、
VFSが変わったせいかと思ったんだが。そうじゃないのね。
327:login:Penguin
08/03/30 20:33:55 hAIGTsTG
>>326
どこも変わってないじゃん
328:login:Penguin
08/03/30 22:09:21 o6yKIr3w
XFSつながりで、話を脱線させると、最近David Chinnerの
Per-superblock unused dentry LRU パッチを評価してるんだけど、
これ、いいな。
だいぶ速くなる
329:login:Penguin
08/04/02 23:36:16 miBB8ivN
raid0とXFS組み合わせたらext2の1/7ぐらいしか性能でなかった。
ﾎﾞｽｹﾃ･･･
チューニングパラメタとかあんの？
330:login:Penguin
08/04/02 23:45:20 MwvMzT8M
>>329
何を書いたかによるんでねぇの
331:login:Penguin
08/04/02 23:47:09 miBB8ivN
>>330
dbenchでのスループット
332:login:Penguin
08/04/02 23:53:19 miBB8ivN
ちなみに本日の測定結果
ext2: 470MB/s
ext3: 150MB/s
XFS: 70MB/s
333:login:Penguin
08/04/02 23:57:54 ljKkX6tm
reiserfs…
334:login:Penguin
08/04/03 00:03:41 itZB1pzN
>>333
LKMLみててビルドエラーしたよん系以外の話題でreiserfsはとんとご無沙汰。
あれはもうダメじゃないか？
335:login:Penguin
08/04/03 00:16:25 5AUHYNuG
話題にならないということは、reiserfs3が安定しているということだ。
よいことではないですか。
336:login:Penguin
08/04/03 00:19:23 XQFAcyR9
多分、JFSも超安定してるんだろうなあ・・・
337:login:Penguin
08/04/03 01:06:02 Ztawo/Fi
>>336
JFSはサンプルが少なすぎるのかもねｗ
まあ、俺はext3に裏切られてから、IBMを信じて使ってたけど。
338:login:Penguin
08/04/05 14:39:51 CsBMf95s
正式ext4マダ～？
339:login:Penguin
08/04/05 17:01:10 gcliPWD0
たぶん福田総理の辞任→新総理誕生とタイミングが同じになると思う。
340:login:Penguin
08/04/05 22:37:23 BOqKZkDS
>>338
正直新FSを名乗るほどは変わってないという印象
341:login:Penguin
08/04/06 12:51:02 2TQbeNBN
ext2→ext3よりは変わってるだろ
342:login:Penguin
08/04/06 17:43:04 Wl/OXr5s
16TBを越えるストレージが必要になるまでは、reiserfs使ってたほうが良くない？
343:login:Penguin
08/04/06 17:49:50 u2gn5b5I
reiserは8TBまで
実際にハマってXFSにした。
344:login:Penguin
08/04/07 21:57:37 QCSgi87J
はよext4でないかなー。
Reiserやxfsはハードの進化に追いついてないし、JFSは死に体だし。
345:login:Penguin
08/04/07 22:04:07 W1D8Pi3p
>>xfsはハードの進化に追いついてないし
kwsk!
346:login:Penguin
08/04/07 22:04:21 jcVZQx+d
ext?がハードの進化に追いついてるかというとそれも疑問符が付くと思うのだが
reiser4の方が近代的でね？
347:login:Penguin
08/04/07 22:09:03 XafXBPQU
死んだ子の年を数えるのは止めようぜ
348:login:Penguin
08/04/07 22:14:16 pnasWVod
...zfs....
349:login:Penguin
08/04/08 08:05:49 vX51nrv+
>>332
＞ちなみに本日の測定結果
＞ext2: 470MB/s
＞ext3: 150MB/s
＞XFS: 70MB/s
ＪＦＳもやってくれー
350:login:Penguin
08/04/08 12:40:57 7jql+r0w
>>345
いまC2D対応やってます状態。xfs使うならPen4以前で。
351:login:Penguin
08/04/08 12:42:54 77bTVWBc
>>350
そのやってます状態のパッチは？
352:login:Penguin
08/04/08 20:06:46 t6pXtMUO
>>350
ああ、開発主体のSGIがスパコン屋さんなので、去年まではIA64メイン、
今年からはx86_64メインだからね。
x86_32 はどうしてもワンテンポ遅れるんだけど、正直それで困ってる人もいないという・・・
353:login:Penguin
08/04/08 21:59:28 kp2pJUVD
>>350
対応って具体的に何するの？
ちゃんとしたSMP対応した時点でマルチコア対応と変わらんし。
354:login:Penguin
08/04/09 11:03:15 XsC9hakW
>>353
普通そう考えるだろうが、そうじゃなかったのがXFSの凄い(?)ところ。
355:login:Penguin
08/04/09 11:21:07 irm1RyJp
ここまで具体的な数値またはコード、０。
356:login:Penguin
08/04/09 13:21:43 XsC9hakW
mm絡みのあのpatchとかlock絡みのあのpatchとか思い浮かぶのはあるんだが、
ゴミの山みたいなpatchの中から探し出してくるのがダルすぎ
定量的に比較したことは無いが、ext3はあれほどpatch多くない気がするがどうなんだ?
357:login:Penguin
08/04/09 13:29:32 P7VWxNnr
ext4でデフラグがようやく使えるようになると聞いたのですが。まだ未実装だっけか。
しないとパフォーマンス悪いってのはやっぱ、
linuxでは「必要ない」、ではなく「できない」の間違いだったってことですよね。
358:login:Penguin
08/04/09 13:42:10 KQOYg6Em
今時のHDDにデフラグって必要ないんじゃないの？
359:login:Penguin
08/04/09 13:48:54 XsC9hakW
ext4の本流にはまだmergeされてない。
が、NECの人が頑張っている流れで実装はある。ext3用のも。
ext2/3ではデフラグが必要ないというより、開発当時の環境では、
デフラグのコストが性能の低下より大きかった、という話じゃないかな。
最近のドライブの大容量化や高速化でそうも言っていられなくなっただけ。
360:login:Penguin
08/04/09 16:46:40 bJQ+WBXU
どんなに断片化に強かろうが、使っていれば少しづつ断片化していく訳だが
サーバ市場で普及が進んだおかげでLinuxを長期運用する例が増え
比例して断片化の進み具合やその影響も馬鹿にならなくなってきて
それを解消したがる顧客の声もそこそこの規模になり
更にext4は状況によってext2/3より断片化が発生しやすくなってしまった。
このような時代の流れによりNEC開発陣はデフラグツール開発の大義名分をゲット。
金庫番との死闘と末、開発費を捻出させることに成功したのであった。やったね。
こうですか？わかりません＞＜
361:login:Penguin
08/04/09 17:00:20 KQOYg6Em
HDD側のキャシュ増やした方がいいような？
362:login:Penguin
08/04/09 18:30:34 LVCZieeg
>>360
発想が昭和の人って素敵って感じだね。
363:login:Penguin
08/04/09 18:46:45 5v+cawCi
俺デフラグずっと眺めてるの好きなのでぜひグラフィカルなUIを用意してもらいたい。
364:login:Penguin
08/04/09 23:04:39 HmwSCQL2
>>363
win98のころのブロックが移動して色変わってくの好きだったのに2ｋぐらいから
ただの棒になって色変わるだけになってつまんなくなったな
365:login:Penguin
08/04/09 23:44:17 OcdXE9xM
ブロックのやつはそれこそDOSな時代からだよ。
あれは趣があった。
366:login:Penguin
08/04/09 23:57:02 MHOGD1vi
乗せたらダマス 魔法の絨毯 騙され続けて四半世紀だな
デフラグってプラセボつーか依存だよね。3日開けずにやっている香具師いる。
367:login:Penguin
08/04/10 00:23:32 A4V/r+Uq
デフラグを高速化するために最新のHDDを買い、
HDDがフラグメントしないようにデータをあまり書かない。
そんな時代も俺にはありました・・・
368:login:Penguin
08/04/10 00:40:21 sVUazSs4
神経質な奴ほどデフラグ中毒になりやすい。
デフラグ中の画面を延々見てる奴。
洗濯中にグルグル回ってるのを延々見てる奴。
両者は似ているようで少し層が違う。
369:login:Penguin
08/04/10 00:53:04 M4lYQAYA
defrag中毒のヤシはLFS系のfsつかえばいいのに
370:login:Penguin
08/04/10 01:30:53 NY5kJFee
デフラグの画面は人間の生産性を驚異的に落とす最悪のGUIなので
ライフハック（笑）的には真っ先に削除されるべき
371:login:Penguin
08/04/10 01:49:42 gvIBE6hj
LFSとか言われてもな
372:login:Penguin
08/04/10 04:06:43 Gfyr/fVJ
>>368
洗濯機のグルグルは気持ちが落ち着く
デフラグはイライラする・・真逆
373:login:Penguin
08/04/10 10:21:47 REpR0D1a
なんか洗濯機を眺めながら一人で酒を飲んでるって芸人がいなかったっけ?
374:login:Penguin
08/04/10 10:49:40 H34Gbw9O
麒麟の非公園生活者の方（川島）だったな。
ちなみに今は洗濯機そっちのけで眞鍋かをりに乗っかってるとか。
375:login:Penguin
08/04/10 15:59:42 AsPLT2gw
>>350
C2D対応のソースまだぁ？
376:login:Penguin
08/04/10 18:46:32 4oJRCPdx
デフラグはHFS+のように、
自動デフラグ解消機能をFSに埋め込むって案はないの？
良くアクセスするファイルを、HDDの先頭に移動して高速化するって案は？
377:login:Penguin
08/04/10 19:46:00 g/S3sRn9
vxfsﾏﾝｾｰ
378:login:Penguin
08/04/11 02:25:29 xdk7g0sU
>>376
＞良くアクセスするファイルを、HDDの先頭に移動して高速化するって案は？
そういう製品もあるよ
ただHDDの先頭は汚染されやすい
（プラッタ上のゴミ等は遠心力で外周に向かいやすい）
ってことを考えると労力の割には微妙だなあと俺は思う
379:login:Penguin
08/04/11 02:33:15 2V7teuhD
良くアクセスするファイルってほとんどの期間osのキャッシュ上にあるんじゃないかな?
ブート時の立ち上がりアクセスを連続化とかそういうのはlinuxじゃ難しそうだし、思想的に好かれなそう。
380:login:Penguin
08/04/11 10:18:34 gfqUbArl
>（プラッタ上のゴミ等は遠心力で外周に向かいやすい）
どんなファイルシステムだよ、と思ったら物理メディアの話か…
381:login:Penguin
08/04/11 11:50:29 NtcJovKM
HDDの中はクリーンでしょ・・・
382:login:Penguin
08/04/11 12:54:43 xdk7g0sU
>>381
プラッタとヘッダが接触する→破片が飛ぶ
あと誤解されがちだがHDDは密閉されていないので
埃等の進入も無いわけではない
383:login:Penguin
08/04/11 14:27:02 NtcJovKM
>>382
ヘッドが接触した時点でバッドセクタ発生で使用中止するでしょ。
気圧調整のために穴が空いているけど、フィルタシールされているから、
埃は外部から侵入しないよ。
384:login:Penguin
08/04/11 15:04:27 xdk7g0sU
フィルタがあるから進入しないというのは暴論だな
385:login:Penguin
08/04/11 15:32:21 EtOBVwEL
>>382
昔のHDDと違って今のはヘッドは接触してないでしょ。
といってもμとかそれ以下のオーダーで離れてるだけだけど。
386:login:Penguin
08/04/11 17:24:52 510mZMoh
しょっちゅうカコンカコンいってますが何か？
387:login:Penguin
08/04/11 20:26:13 2qIbW6EC
破片云々や遠心力云々、
ヘッドの接触を前提に語ってる奴の言葉など、何一つ信用できない。
ちなみに、ヘッドの浮く高さはよく煙草の煙より狭いと言われるが
だからこそ、そのサイズのゴミさえ侵入しないように作られている。
388:login:Penguin
08/04/11 20:31:20 2V7teuhD
てかもうSSDになるんだから、ランダムリードのアクセスはかなり無視できるだろう。
書き込みの遅さと読み込みの速さをどううまくカバーできるかとかやってるのかな?
なんとなくだが追記型のが相性良さそう。
389:login:Penguin
08/04/11 20:34:54 9r4cpd5H
よくわからんが
コンタクト・スタート・ストップとかで接触するんじゃないの。
390:login:Penguin
08/04/12 01:21:44 zKuK+tHg
非動作時等に接触するのは事実だが
そこが回転しているかどうか。
動いていない部分にヘッドが接触して破片がとぶって、
どれほどの衝撃でヘッドが着地するのかと。
391:login:Penguin
08/04/12 02:04:05 UJnKfLiT
>>388
現状ではランダムリードが遅いSSDなんて腐るほどある。
今のHDDでMemoryいっぱい積んだ方が安くて速い。
392:login:Penguin
08/04/12 03:55:16 ddANuM0+
>>390
>非動作時等に接触するのは事実だが
接触しない。今のHDDは電源が落ちると自動的にシッピングゾーンに
ヘッドがリトラクトされる。
現実問題として、実使用時においてゴミがとかヘッドが接触とかありえない。
一番可能性があるのが動作時に外部から強い衝撃を受けた時にヘッドがプラッタと接触し、
HDD内にマイクロな粒子が飛散する恐れがある。
この場合はバッドセクタが発生し、加速度的に増殖して壊れるだろう。
393:login:Penguin
08/04/12 09:44:05 B8KR3TA1
スレ開いて自作板かとオモタwwwww
394:login:Penguin
08/04/12 10:19:10 3VfCSwj0
ぐうぐる[しっぴんぐぞーん]→うぃきぺでぃあ
| ディスク停止時には磁気ヘッドとプラッタは接触しているが（この際の磁気ヘッド位置をシッピングゾー
| ンと呼ぶ）
395:login:Penguin
08/04/12 11:29:27 D6Z7h6V2
全然話についてけないんですけどぉ～＞＜
平常レベルに落としてよぉ～＞＜
396:login:Penguin
08/04/12 11:56:44 ddANuM0+
>>394
ううん、すまん。俺が分解したIBMのHDDはdiscから完全にヘッドが外れて
ヘッド格納部に格納されるタイプだったんだよ。
このタイプの方がより安全だしね。
スレ違いなのでこのへんで。
397:login:Penguin
08/04/12 13:21:02 3VfCSwj0
>>396
それはload/unload(ramp load)方式のドライブで、IBM/HGSTのデスクトップ及び各社のモバイル
向けドライブに採用されています。停止時の安全性と省電力が売りですが、反面load/unload機構は
アームがrampと接触するため耐久性に疑問があること、及びload時にヘッドがプラッタに衝突する
こと、このため結局プラッタ外周部にデータを記録しないランディングゾーンを設けなければならない
ことなど、良いことづくめではありません。
一方停止時にヘッドが着陸するcontact start/stop方式はエンタープライズドライブ及びseagateの
デスクトップに採用されています。古典的な方式なので十分な安全性が確保されていること、
エンタープライズドライブはそもそも回りっ放しが前提なこと、外周の高速な部分が利用できること
などが利点です。反面、モーターが停止するとヘッドは必ず着陸するため、スライダの摩耗や
摩耗による微粒子の飛散などの問題は避け得ません。接触部分は削れにくいようにタフにできて
いますし、プラッタの記録面はゴミが飛んで来てもさらりと受け流すようにコーティングされています
(ふさふさの毛が生えている感じ)。その上に潤滑材が流れていますからまるでマットプレイです。
というようにどちらが一方的に優れているというわけではありませんし、どちらも製品寿命の範囲では
十分な耐久性があるのでもはや信仰の領域です。
……だったのですが、最近load/unload方式に革命的な進歩があり、最新の製品ではついに外周部の
ランディングゾーンがなくなりました。これはついに悲願のヘッドとプラッタの完全非接触が実現したと
いうことであり、load/unloadが一歩前に出たという印象です。
398:login:Penguin
08/04/12 13:21:22 3VfCSwj0
>>390
ランディングゾーンはデータ記録部分と違い、停止時にスライダが吸着しないようにわざとデコボコに
作られています。スピンドルモータが完全に停止するまでスライダが魔法的作用で浮いていられれば
よいのですが、現実には回転数が低下した時点で着陸するため、停止するまでガリゴリ削られまくり
です。この状態からモータを回し始めれば、浮揚するまでの間また削られまくりです。
>>387
景気よく動いていたドライブの電源を落とすと急激に冷えて内部の気圧が下がり、あろうことか
外界の汚れた空気を吸い込んでしまいます。もちろんフィルタで異物の侵入を阻むのですが、
世の中完璧には行かないもので。ハードディスクは温度変化が大敵です。
>>378
確かに内周で発生した微粒子は外周に向かって飛散しますが、スライダより遥かに軽い粒子が
吹き飛ばされることなくプラッタに着地するのは極めて稀なことです。また、そういうことが起こっても
困らないように設計されています。ハードディスク30年の歴史の積み重ねはそう短いものでもありません。
というわけでディスクの先頭に重要なデータを置いても困らないぜ? というお話でした。
っていうかバックアップ取っとけ!
399:login:Penguin
08/04/12 15:40:45 EsTwxU42
おまえら、たまにはスレタイ読んでくれw
400:login:Penguin
08/04/12 15:58:09 1E/jpGQt
コメントアウトされているようです。
401:login:Penguin
08/04/12 15:59:16 EsTwxU42
なるほどw
402:login:Penguin
08/04/12 17:04:40 OZPQRFfQ
この前、夜中、コンパイルしている時、地震があったんだ。
目が覚めるほどの。
その時、ハードディスクから、
「スチュ、チー、チー、チー」と、異音が…。
俺、「うぉーーー」
けど、なす術もなく、夜中で何もしたくなかったから、放ったらかしで。
翌日、どうしたもんかと思いつつ、
パッケージシステムのファイルダイジェストを確かめるコマンドで
チェックしてみたけど、大丈夫だったみたいだから、気にしないことにした。
思い出したから、書いてみた。
403:login:Penguin
08/04/20 18:58:46 plVuI/pr
reiserfsck --rebuild-tree って対象パーティション上に reiserfs らしきものを
見つけるとそれを復元してしまうもんなの？man reiserfsck を見たらそうも読み取れるんだが。
説明下手だけど今起こったことを書く。
/dev/hda9 上に dd で吸い出した別の HD の NTFS パーティションのイメージがある。
まあ、dd if=/dev/hdb1 of=~/ntfs.img をやっただけ。
ntfs.img の中には vmware の Virtual HD の中に reiserfs パーティションがある。
シングルユーザモードで立ち上げて reiserfsck --rebuild-tree /dev/hda9 を
実行したら /dev/hda9 のディレクトリツリーが ntfs.img の中の vmware.vmdk の
reiserfs パーティションの中身に変わってた。
当然ツリーだけが置き換わったんで、ファイルの中身とかはめちゃくちゃなんだけど。
もう何が起こったのかさっぱりわからん。こんなことってありえるもんなのか？
404:login:Penguin
08/04/20 19:01:13 plVuI/pr
ちなみに、ntfs.img の中の vmware.vmdk の中は reiserfs に
Debian をインストールしてました。
reiserfsck --rebuild-tree を実行したらこうなってた。
$ df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/hda1 957M 400M 558M 42% /
tmpfs 502M 0 502M 0% /lib/init/rw
udev 10M 108K 9.9M 2% /dev
tmpfs 502M 0 502M 0% /dev/shm
/dev/hda8 1.9G 33M 1.9G 2% /tmp
/dev/hda6 12G 2.7G 8.6G 24% /usr
/dev/hda7 1.9G 1.6G 313M 84% /var
/dev/hda9 205G 79G 127G 39% /home
$ ls /home
bin dev initrd lib opt sbin tmp vmlinuz.old
boot etc initrd.img lost+found proc selinux usr
cdrom home initrd.img.old mnt root srv vmlinuz
405:login:Penguin
08/04/20 19:37:17 +sFhjnt6
Exactly（その通りでございます）
406:login:Penguin
08/04/20 19:47:37 plVuI/pr
追試してみたら再現したんで自己解決。
結論は、
reiserfs のパーティションを dd 等で吸い出したイメージを
置いてあるパーティションでは reiserfsck --rebuild-tree を
絶対に実行してはいけない。
あらかじめ gzip で圧縮したり、rm で消しておけば大丈夫っぽい。
rm で消した程度だと見つけられるんじゃないかと思ったけど平気だった。
# mkfs.reiserfs /dev/hda9
# mount -t reiserfs /dev/hda9 /mnt
# ls /mnt
#
# dd if=/dev/hda1 of=/mnt/hda1.img
# ls /mnt
hda1.img
# umount /mnt
# mount -t reiserfs /dev/hda9 /mnt
# ls /mnt
bin dev initrd.img media root sys vmlinuz
boot etc initrd.img.old mnt sbin tmp vmlinuz.old
cdrom home lib opt selinux usr
debootstrap initrd lost+found proc srv var
# /mnt/bin/bash
bash: /mnt/bin/bash: cannot execute binary file
407:login:Penguin
08/04/20 19:50:33 plVuI/pr
>>405
やっぱそうなのか…。
長々と書いちゃったけど、既出だったらスマソ。
408:login:Penguin
08/04/20 19:53:51 OEHN1Qvf
reiserfsのその辺の話は有名かと思ってたけど、そうでも無かったんだ。
どこかまとめページには載ってなかったのかな。
409:login:Penguin
08/04/20 19:56:00 plVuI/pr
>>409
作業ログの 8行目と9行目の間に
# reiserfsck --rebuild-tree /dev/hda9
が抜けてた。
大事なデータがなかったからバックアップも取らずに rebuild-tree
したけど、バックアップは取りましょうってことで。
410:login:Penguin
08/04/20 22:20:04 mzHdbzqB
>>408
長いことreiserfs使ってるけど知らなかったよ。
人柱乙。つーか、バグレポだしても問題ないレベル？