06/12/10 02:52:33 0gb/zk4T
開発もしてないのに趣味でカーネルビルドしたり
ファイルシステム変えたり
奇特な若い衆ですね。
176:login:Penguin
06/12/10 03:10:45 /uFKb+GK
>>170
もう二度と湧いてくるな
177:nautilusの人
06/12/10 03:46:13 TgXM1Sad
>>171 >>174
しょせん俺は何も知らない馬鹿だよ。でもおまえらの人を見下げたような文章もあまり知性が感じられないぞ
アホタレどもめ
>>176
おまえに言われなくても二度とこねえよw このお子さまランチめ
最後に一言
このスレで色々と情報をくれた方々に、ありがとうございました
178:login:Penguin
06/12/10 03:50:27 88+w2rhZ
>>175
んー？それに関しては別に問題ないんじゃない？
学生さんでインストールマニアだったらカーネルビルドとか
気に食わないfs捨てたいから変えるくらいするだろ。
むしろ最近の学生はそれすらできない香具師しか多そうだし、
良い方の奇特な香具師だと思うぞ。
179:login:Penguin
06/12/10 09:34:16 jHWNrXu/
そうだそうだ、オプション変えてカーネルのビルドを繰り返すうちに
カーネルの内部構造に興味をもっていくもんなんだ。
てなわけで、ガンガレ>>177
180:login:Penguin
06/12/10 10:08:51 CiyFfnIL
まぁ，がんばって欲しいところではあるね。
ただ，他の人が理解の仕方がおかしいと指摘していることに関しては，
もう少し努力する必要があると思うけれど。
181:login:Penguin
06/12/10 12:06:52 WasA3VVH
残り少ない今年の目標
若い奴は生温かく谷底に突き落とせ!
182:login:Penguin
06/12/10 13:19:59 XLohVbNm
>>180
努力はしてほしいけどな。
ただ、>>177みたいにキレて捨て台詞吐いて逃げるってのはやめた方がいいな。
183:login:Penguin
06/12/10 14:29:45 jHWNrXu/
>>182
今頃の若者にしては、捨て台詞の後に礼をしているあたりが
見所がある。
184:login:Penguin
06/12/10 16:35:52 2HNgBmx6
どう見ても精子です。
本当にありがとうございました。
185:login:Penguin
06/12/10 17:20:16 sXlQ0bnD
知らないこと・わからないことを公の場で聞けるのは立派
それを見下す連中こそ馬鹿 おまえ達だって知らない時期があったでしょ
わざわざ暴言書く暇があるならどっか参考になるURLでも示す方が生産的。
でもどんな理由があってもキレ台詞はやめたほうがいい。品性が落ちる。
186:login:Penguin
06/12/10 17:49:38 TNoYmltu
少なくとも匿名掲示板で何か教えてもらったというのは記憶に無いな。
187:login:Penguin
06/12/10 17:56:35 hIevwezh
ググればわかる情報は教えてもらえないだろう
質問されたほうはムカつくもんな
188:login:Penguin
06/12/10 20:51:36 /uFKb+GK
>>185
教えてクンを肯定するのもなぁ。
189:login:Penguin
06/12/10 21:03:49 b8muUvr3
>>185
罵倒することも立派な教育だよ。 無視するよりはずっと良い。
190:login:Penguin
06/12/10 21:26:54 aQAOhBxb
馬鹿ばっか。
191:login:Penguin
06/12/10 21:27:47 AaJ/gQWg
と馬鹿が申しております。
192:login:Penguin
06/12/11 02:11:53 WQUWzS9F
>>185
>わざわざ暴言書く暇があるならどっか参考になるURLでも示す方が生産的
ということで
っ URLﾘﾝｸ(www.linux.or.jp)
いやこっち(も)だな w
っ URLﾘﾝｸ(www.linux.or.jp)
>>178
>むしろ最近の学生はそれすらできない香具師しか多そうだし
今は学生に限らず社会人までそうだもんな。「そんな事聞いて無いからしませんでした」ってばっかり・・・
まあとにかくガンガレ
193:login:Penguin
06/12/13 00:48:25 bqgQBo7n
Solaris10 11/06出た。RAID-Z2(RAID6)とホットスペア機能が使えるようになった。
194:login:Penguin
06/12/13 18:51:41 b8bVQzXm
はやく移植されないかなー
195:login:Penguin
06/12/14 19:38:33 DclqJgck
ext2fsdってどうですか？安定してますか？
196:login:Penguin
06/12/15 07:46:57 YAtgT/AF
うん。
197:login:Penguin
06/12/16 06:30:03 KNwmu5Y4
サイズの大きなパーティションにファイルシステムのイメージごと dd などでコピーして
その後ファイルシステム自体も成長させられるようなファイルシステムってありますか？
縮小はさらに難しそうだなぁ
198:login:Penguin
06/12/16 07:19:02 KNwmu5Y4
うぉ、mdadm で linear なアレイ作って
後でいくつかディスク追加しようと思ったら
--grow は linear では使えないって orz
199:login:Penguin
06/12/16 07:32:43 +S1DoSTm
loopbackデバイスを使ってLVMとかできるんじゃねえ？
やったことないし縮小も無理だけど。
200:login:Penguin
06/12/16 08:56:25 h5sW2mHZ
linearってなんだっけ？
コンカチネイト（JBOD）だっけ？
それともストライプ（RAID0）？
201:login:Penguin
06/12/16 09:49:45 ozfgfRrw
>197
そこまで具体的に言われたら FreeBSD の ufs だって出来る...
Linux の FS も含めてどれだけ実用的・安全に出来るかどうかは
たぶん全然別の問題という気がするけど
202:login:Penguin
06/12/16 10:15:07 +S1DoSTm
>>197
スマソ
ddでイメージファイル作って、イメージファイル内のファイルシステムを成長させる話と勘違いしてた。
GNU Partedを使う場合
URLﾘﾝｸ(nobumasa-web.hp.infoseek.co.jp)
ファイルシステム付属のユーティリティを使う場合
URLﾘﾝｸ(pantora.net)
FreeBSD のufsもgrowfsがある
203:login:Penguin
06/12/16 11:48:37 KNwmu5Y4
>>200
madam --cretae --level linear は JBOD っす。
余った小さなディスク（60GB）くらいのがちょこちょこ
集まってくるんで、くっつけて作業用にでも使おうと思って。
>>201-202
ufs ってのは成長させられるんですね。
いままで ext2 ext3 くらいしか使ったこと無かったんで
今から手探りでいろいろ試してみようかと思ってます。
OS は Linux 。何かあってもいいように VMware 上の
Debian か Fedora Core で実験予定。
204:netadesu
06/12/16 15:05:21 SIzSeUHT
growだったらできないfsの方が稀じゃないか？
ただ、hot expandできるかどうかは別。
やらないにこしたことないから常用してはないけど、
ext2(3だったかも), reiserfs, xfs ではやったことある。
205:202
06/12/16 17:18:02 +S1DoSTm
GNU Partedも現在はufsのリサイズサポートしてるみたい。
URLﾘﾝｸ(www.gnu.org)
growfsのラッパーだろうけど。
206:login:Penguin
06/12/16 17:23:46 XtbPeLaZ
ext2/3はpartedよりresize2fsの方が確実
parted、拡張に追いついてきてないし
そして名前も出てこないjfs(-o remount,resize)かわいそす
207:login:Penguin
06/12/16 17:26:19 FC6GU6Ut
みんなぶっちゃけ、jfsなんて使ってないんだろ？
208:202
06/12/16 18:18:47 +S1DoSTm
>>206
> そして名前も出てこないjfs(-o remount,resize)かわいそす
> ファイルシステム付属のユーティリティを使う場合
> URLﾘﾝｸ(pantora.net)
ちゃんとでてるだろｗ
209:netadesu
06/12/16 19:52:23 SIzSeUHT
>>207
トップ３以外はあまり使ってもらえないのが実情だから。
reiser*の開発がBSD訴訟された*BSDみたいに遅延しそうな気配があるから
数年後にはext4,xfs,jfsの３強になってるかもね。zfsも期待。
210:login:Penguin
06/12/16 20:05:37 82ULKkhv
>>209
またまた冗談を(AA略
zfs,reizer*,ext*の3強に決まってる。
211:login:Penguin
06/12/16 20:13:37 b3Zossa2
zfs(raidz,2)のハード実装ってどれくらいで出てくると思う？
誰かが作ってると思うんだ。
どういう感じのデバイスに見えるのか分からんけど・・・・
212:login:Penguin
06/12/16 20:23:39 FC6GU6Ut
CDDLで成功したソフトウェアってないんじゃないの。
オープンソースなのはありがたいけど、CDDL読んだあとにパッチを
コミットしようと考えるボランティアはあんまりいないんじゃない。
jfsはGPLなのにボランティア少なそうだけど。
213:login:Penguin
06/12/16 20:53:55 rOPtoKv8
>>212
なので、OpenSolarisのGPL化なんて噂はある。JavaもGPL化って噂だし。
214:netadesu
06/12/16 21:44:56 SIzSeUHT
>>213
旦那旦那、噂じゃないですよ。それは去年の話。
215:login:Penguin
06/12/16 21:52:53 KoFH3LYy
キリンさんのOS
Nexenta OS
URLﾘﾝｸ(www.gnusolaris.org)
216:login:Penguin
06/12/16 21:59:32 qYQjoEYU
>>215
銀河麒麟をもちだしてきたのかと思った。
217:login:Penguin
06/12/17 00:23:09 Q2xF4z7Q
URLﾘﾝｸ(www.drk7.jp)
> Server File Cache → Storage の解説によれば、
>
> ext2 は複数のバグが絡み合って、 結果として同期的書き込みが全く保証されない。
> user data の disk への書き込みは、 write システムコールに対する O_SYNC フラグを付与しても、 fsync システムコールを呼び出しても、
> sync システムコールを呼び出しても、 保証されない。
> umount によってのみ、dirty page は 100% 反映される。
> と言うことは、 ext3 層が ext2 に Journal を書いてくれと頼んでも、 Journal 記録が disk に書き込まれる保証はない という事を意味する。
> さらには、ext2 は書き込み順序にエレベーターシークアルゴリズム などを用いるので、 Journal ファイルへの > Journal 記録の反映順序保証さえない事になる。
>
> だそうです。
詳しい人この辺のことどうよ。
ext3のジャーナルはどれくらい信用できる？
218:login:Penguin
06/12/17 02:01:49 iXfl1BVU
キチガイの書いた文章を読むとキチガイが伝染るよ！
うんこに触ると手にうんこ付くよ！
ﾊ_ﾊ
('(ﾟ∀ﾟ∩ つくよ！
ヽ 〈
ヽヽ_)
219:login:Penguin
06/12/17 02:26:58 Q2xF4z7Q
> Server File Cache → Storage の解説によれば、
URLﾘﾝｸ(www.dd.iij4u.or.jp)
ここの事なんだけど、何のことだかさっぱりわかりませんです。
220:login:Penguin
06/12/17 02:29:31 iXfl1BVU
ウンコ臭いリンク貼るのやめてください。
それとも本人ですか？
221:login:Penguin
06/12/17 02:31:55 Q2xF4z7Q
本人が、「何のことだかさっぱりわかりませんです。」とか言いますか？
で、２つのリンクともキチガイが書いたと？
222:login:Penguin
06/12/17 02:34:53 iXfl1BVU
yes
yes
223:login:Penguin
06/12/17 02:37:30 Q2xF4z7Q
そうですか。
少し興味を持ったので貼ってみたんですが、騙された私がアホだということでしょう。
224:login:Penguin
06/12/17 05:16:30 RV23LfOh
散々既出のネタだから過去ログでも漁ってこい
225:223
06/12/17 07:18:22 Q2xF4z7Q
>>224
過去ログ一応その2から読んだ。（丁寧に読んだのはその２だけ）
ついでに、「何のことだかさっぱりわかりませんです。」と思ったリンク先も読み直した。
まあ、確かにうんざりするくらい語られてるねえ。
後、奥山氏がいわくつきの人物なのもわかった。
で、結局ジャーナルファイルのsyncは保証されてるのかどうかはよくわからなかった。
ジャーナルファイルがvfsレイヤを使わず、独自ルーチンを使ってるって反論もあったけど、
独自ルーチンがsyncを保証してる説明はなかったよ。
Linuxは当初から性能重視で非同期書き込み、*BSDは信頼性重視で同期書き込みを志向してたはず。
どちらが正しくても、正直構わないけどここの住民はもうちっと骨のある反論しろよ。
226:login:Penguin
06/12/17 11:15:48 OfbsfsR3
>225
つ URLﾘﾝｸ(www.drive.ne.jp)
その内容を読み取ってなにが正しいか判断するのはお任せする。
227:login:Penguin
06/12/17 11:25:23 hhbkxu9f
また奥なんとかかよ
飽きねえ奴だな
228:login:Penguin
06/12/17 12:46:25 23TZod3p
ID:iXfl1BVUのように発狂しているだけの包茎くん。
HIVに感染しやすくなるんだから、とっとと手術しろよ。しかも臭いし。
お前、生きる公害だぞ。
229:login:Penguin
06/12/17 13:50:10 iXfl1BVU
>>228
本人キター！
230:login:Penguin
06/12/17 14:50:56 edSVj54I
ID:iXfl1BVU はちょっと黙っててくれないかなあ。
231:login:Penguin
06/12/17 15:33:19 iXfl1BVU
じゃ黙ってるから存分に有意義な議論をしてくれ
232:login:Penguin
06/12/17 15:51:41 gBsLzMH4
つか奥屋マンコのスレでも立ててそっちでやれってかんじー
233:login:Penguin
06/12/17 15:58:34 PCiXBd2b
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――‐┬┘
|
＿＿＿＿.＿＿＿＿ |
| | | |
| | ∧＿∧ | |
| |（ ´∀｀）つ ミ |
| |/ ⊃ ﾉ | |
￣￣￣￣'￣￣￣￣ |
| ext3
234:login:Penguin
06/12/17 17:54:13 Q2xF4z7Q
>>226
メーリングリスト一応全部読んだ。
議論の余地がないでしょ。
LinuxのsyncはHDDのバッファをフラッシュしない。
235:login:Penguin
06/12/17 18:51:54 eRUWixex
そして、FreeBSDでも6以降はフラッシュしない…
236:login:Penguin
06/12/17 19:22:58 6nMM/n3x
次の展開はわかっている！
こうだ！
NetBSDマンセー (35歳 会社員)
237:netadesu
06/12/17 19:29:46 Df4Nxwhq
BSD vs Linux って考えてみれば UNIX の最下層でどちらが下か
やってるだけなんだよな。
Solaris/AIX/HP-UX/SUPER-UX... とかの世界のファイルシステムってどうなんだろう。
238:login:Penguin
06/12/17 20:22:16 7CL4+VjT
NetBSD + LFS最強説
239:login:Penguin
06/12/17 21:16:34 xnDjwphy
いずれにせよLinuxのソフトウェアRAIDでは
grow ができないので、あんまりメリットか無い気がする。
LVM を使ったことが無いので外しているかもしれない。
240:login:Penguin
06/12/17 23:38:46 BpKCD3FA
>>239
dm,mdは適宜使い分けるべし。どっちを上にも出来るから。
241:netadesu
06/12/17 23:39:16 Df4Nxwhq
growさせるつもりならLVM-on-RAIDにして、ディスクを追加するときは
独立したRAID-1/5セットをPVとしてLVMに追加してgrowさせるよ。
見せ方は違っても、これは他のOSでも同じじゃないの？
物理デバイス冗長を取る部分と可変長な論理デバイスを実現する部分は
直行してるはず。
242:login:Penguin
06/12/18 01:53:56 5CjTidJ8
めちゃくちゃパフォーマンス悪そうだがｗ
243:login:Penguin
06/12/18 02:05:56 Nty7XqwY
俺もLVMにしてる。
244:login:Penguin
06/12/18 02:24:08 BgGwtA55
>>237
SolarisなどはOSのコアな部分ではLinuxや*BSDの二歩も三歩も先に行っているからねぇ。
fsにせよ、I/O周りにせよ、SMPにせよ、スケジューラにせよ、ネットワーク周りにせよ。
>>238
そういえば、最近のLFSはそこそこ安定してきているみたいですな。
ただ、NetBSDのLFSが磐石になる前に、ZFSが各OSにportされそうな雰囲気だけど。
そういえば、LinuxにもgcがないすさまじいLFSがあったな…
>>243
LVMはトラぶったときのことを考えるといやなんだよなぁ。
245:login:Penguin
06/12/18 03:11:56 F98nsRY8
>>241
あれ？俺いつのまに書いたっけ？
246:login:Penguin
06/12/18 05:49:01 lBfvMR/v
ふむ、md でも JBOD できるけど、grow する事を考えれば
LVM 使えってことですか？そもそもソフトウェアRAIDの枠組みの中で
JBOD できる Linux が変態？
247:login:Penguin
06/12/18 07:27:40 oHr+ULas
頭悪そうだね
248:login:Penguin
06/12/18 08:14:37 sqlaZvsB
本家HP-UXのように、md（ソフトウェアRAID）とLVMって調和が取れてないから、
組み合わせて使うのはためらうんだよな。
ZFSはソフトウェアRAID、LVM、ファイルシステムのLinuxが弱い部分を一気通貫でカバーしてるからな。
249:login:Penguin
06/12/18 08:34:26 etiTNDak
>>248
なんで前半は HP-UX なのに、後半は ZFS?
ZFS みたいに一体化したものは置いとくとして、
Linux の LVM 自体は良くできてると思うけどなあ。数十台、数十TB
使ってるけど、構成情報のバックアップだけ残しておけば、そうトラブル
復旧も難しいわけじゃない。
250:login:Penguin
06/12/18 15:13:18 8QMqXAUL
LVMについで一文
ZFSについてでもう一文
251:login:Penguin
06/12/18 18:30:49 Y/ed09i4
ファイルシステム変換がうまくいきません…。
誰かお教え下さい。
ファイル システムの種類は FAT32 です。
ドライブ H: の現在のボリューム ラベルを入力してください ******
ボリューム ****** は 2006/12/05 17:26 に作成されました
ボリューム シリアル番号は ...... です
ファイルとフォルダを検査しています...
ファイルとフォルダの検査を完了しました。
ファイル システムのチェックが終了しました。問題は見つかりませんでした。
244,136,352 KB : 全ディスク領域
76,320 KB : 115 個の隠しファイル
26,784 KB : 833 個のフォルダ
69,861,888 KB : 22,810 個のファイル
174,171,328 KB : 使用可能ディスク領域
32,768 バイト : アロケーション ユニット サイズ
7,629,261 個 : 全アロケーション ユニット
5,442,854 個 : 利用可能アロケーション ユニット
ファイル システムの変換に必要なディスク領域を調べています...
全ディスク領域: 244196001 KB
ボリュームの空き領域: 174171328 KB
変換に必要な領域: 347074 KB
基本ファイル システム構造を作成できません
変換に失敗しました。
H: は NTFS に変換されませんでした
252:login:Penguin
06/12/18 18:31:51 pj2+GtGf
>>251
Windows は板違い。
PC初心者
URLﾘﾝｸ(pc7.2ch.net)
253:251
06/12/18 18:31:58 Y/ed09i4
すいません
誤爆しました
254:login:Penguin
06/12/18 22:50:45 7eT6c4q7
ちょいと、お聞きしますよ。
自宅のメールサーバをPPCにしようかと思ってるんですよ。
で、ファイルシステムの実績を見てたんですがイマイチ分からない。
エンディアンが違ったときの使用実績がわからんのです。
SGI、IBMが作ったxfs、jfsはそのあたり何とかなってそうですがどんなもんでしょう。
非intelアーキテクチャで動かしてる人もみんな大体ext3なんですかね？
ま、壊れても困るのは家族くらいなんでドレでもいいという話はありますが。
興味ひかれてということで。
255:login:Penguin
06/12/19 09:53:23 8O8QeZf3
>>254
ユーザが多いのにしておくのが無難ね？
玄箱すれで聞いてみるとか。
256:login:Penguin
06/12/19 10:43:37 LR+FoNiH
実際のところ、エンディアンは関係あるのかなあ？
俺はないと思うが。
エンディアンで変わるのはファイルの中身だけじゃねえ？
257:login:Penguin
06/12/19 10:52:00 XzW6MizV
file attribute の意味が変わったり
ファイルの大きさが 1600万倍になったりしてもビックリしないの?
258:login:Penguin
06/12/19 10:58:10 8O8QeZf3
異なるエンディアン間でディスクを移動したりすると
やばい聞いた。特にextXとか、mdのメタデータとか。
259:login:Penguin
06/12/19 12:12:40 JTMTN/tV
>>257
それはVFSレイヤの話でないの？
ファイルシステムに直接依存するのだろうか。
260:login:Penguin
06/12/19 12:23:30 JTMTN/tV
それは、ビッグエンディアン環境⇔リトルエンディアン環境を移動させればまずいよなあ。
まさに>257の言う事が起こる。
しかし、そうでない場合に>257が言うようなことが起きればVFSの問題と思うんだが。
261:login:Penguin
06/12/19 12:28:02 JTMTN/tV
とここまで書いておいて気がついた。
何も考えずに書き込み、何も考えずに読み出しても同一環境では問題オコラネー。
VFSもファイルシステムも関係ネー。
違うか？
262:login:Penguin
06/12/19 13:04:19 TnIoz1+9
>>258
んなことねえよ
ちゃんと考えて設計されてるよ
角度とか
263:login:Penguin
06/12/19 13:23:33 8O8QeZf3
>>262
URLﾘﾝｸ(www.ussg.iu.edu)
うひひ
264:login:Penguin
06/12/19 13:31:26 qiS7ynEf
何このレベル低下っぷり？
以前はキチガイも多いがここまで低レベルじゃなかっただろこのスレ。
265:login:Penguin
06/12/19 13:57:36 1t2/+nmt
ext3はOKだと言われているが、他は知らん。
SolarisだとUFSはバイトオーダ依存で、ZFSはバイトオーダ非依存。
266:login:Penguin
06/12/19 14:21:29 skFd6jjj
ext2をi386と～ebな環境で使いまわしてるけど、
いまのところ問題は起きてないな。
ただe2fsprogsは全部試していないので、そのへんに
地雷が埋まってるかもしれん。
267:login:Penguin
06/12/19 14:30:12 O6QzCkRT
>>264
ツマンネ
268:login:Penguin
06/12/19 14:51:31 LBOK3XqF
>>265
今月のSDにZFSの記事があって、
ZFSは書き込みはマシンバイトオーダ、
読み込み時に変換してると書いてあったな。
269:login:Penguin
06/12/19 15:52:09 wh6OROKj
>>268
ってことは、ファイルシステムにバイトオーダが記録されてるのかな？
別のマシンにディスク持って行っても使えるけど
バイトオーダが違うマシンに持って行くと動くんだけどパフォーマンスが落ちる、と。
おもしろいかも
>>255
すまね。
ひねくれてるのでext3とjfsで作ってみた。
jfsがどれくらい頑丈か、かな・・・・
取りあえずディスクを直接持って行っての物理的な共有はしないようにします
環境できたらpostmarkでもやってみるよ
270:login:Penguin
06/12/19 16:34:14 LBOK3XqF
>>269
全くの推測だけどどっかのビットで判別してるんじゃないかな。
0だとLEとか。
記事ではsparcマシンのHDDをintelマシンに持っていっても読める
と書いてあったが、パフォーマンスに関しては書いてあったか忘れた。
変換のオーバヘッドはほんの少しだろうけどあるだろうな。
271:login:Penguin
06/12/19 16:42:59 I6Be52hp
>>269
このスレで大人気の奥山氏曰く
「ついでに言うと、JFSの信頼性のなさも問題があるので、それに修正を当て
ても、『XFSに追いつく』程度でしかない」とのこと。
あくまでもLinuxとFreeBSDとのsync時の挙動の違いについての話の中で
余談としてでてきた話題でソースがないのであれだけど、このスレでも
XFSに比べてJFSって特に信頼性高いとも思えないしメリットないなぁという
のは何度も出てきているね。
272:login:Penguin
06/12/19 16:45:46 DJKXWzFE
チキンな俺は常にext3
273:login:Penguin
06/12/19 16:48:06 WLeCaQbI
いまんとこlinux用はext3中心に回ってるんでおk
274:login:Penguin
06/12/19 17:25:19 JTMTN/tV
普通にupdatedbとかたたくと、ext3遅すぎねえ？
ReiserFSの何倍もかかる。
アクセス時のシーク音は明らかに違う。
275:login:Penguin
06/12/19 17:39:09 DJKXWzFE
ReiserFSは作者の動向が怪しい
276:login:Penguin
06/12/19 17:44:01 qiS7ynEf
怪しいのは作者が住んでる町の警察の動向だろう
277:login:Penguin
06/12/19 17:44:48 5KfKfe1m
あれからどうなった
278:login:Penguin
06/12/19 17:44:55 JTMTN/tV
確かにナorz
将来乗り換えが必要になる可能性大
279:login:Penguin
06/12/19 18:07:21 JTMTN/tV
ext3って皆が使ってるから何か起こっても豊富な情報がある。
それにツール類もまずはext3を前提に作られてると思う。
使うのに十分な値打ちがあると思う。
でも、ツマラネーんだよな。
ext3使っててこのスレ読んでても楽しみ少なくない？
280:login:Penguin
06/12/19 18:10:57 TnIoz1+9
楽しみより安定性
281:login:Penguin
06/12/19 18:17:58 JTMTN/tV
まあ無難な選択を否定することは、誰にもできないな。
282:login:Penguin
06/12/19 18:18:42 GWNB1OAW
住んでいるまちの警察の動向が怪しいなら
結構長くでてこれないかもね。
283:login:Penguin
06/12/19 20:14:25 b8knrZg8
>>280
もっとも、安定性を求めるのならLinuxなんか使うなって話もあるわけで。
284:login:Penguin
06/12/19 20:17:30 qiS7ynEf
hahahahahahahahahahhahahahahahahaha
285:netadesu
06/12/19 20:37:18 oCGBR2+N
>>270
各ファイルシステムとも4byteのマジックコードを定義してるので
それで判別できる。ただし実際に判別してちゃんと読み書き時に
変換してるかは別。
FSじゃないけど0xCAFEBABEとか0xDEADBEEFとかが有名。
0xCAFEBABE 0xBEBAFECA 0xBABECAFE 0xFECABEBA
と読んだ時に違いが出るので判定できる・・・んだけど64bitの
足音が近いから変態なアーキテクチャが出たりしたら8byteマジックが
必要となる日も近いかも。
286:login:Penguin
06/12/19 20:44:56 WLeCaQbI
>>283
そんな話いつどこで聞いたんだ。捏造するな。
287:login:Penguin
06/12/19 20:57:01 azfMKvlf
ID:WLeCaQbI発狂中
288:login:Penguin
06/12/19 22:27:06 //1HgQEi
sun386i と sun3 の disk の繋ぎかえはダメって話だったな
289:login:Penguin
06/12/19 23:12:48 LR+FoNiH
結局のところ、>>260-261が的を射ているんだな。
で、ビッグエンディアン環境⇔リトルエンディアン環境のディスク移動ってLinuxではほとんどないんじゃねえの？
SunとかMacとかなら要望は多いだろうけど。
290:login:Penguin
06/12/19 23:40:54 leiixtBd
スラッシュドット ジャパン | LeopardはZFS対応か?
URLﾘﾝｸ(slashdot.jp)
刻はZFSの鼓動を見る。たぶん。
URLﾘﾝｸ(blog.ninth-nine.com)
291:login:Penguin
06/12/19 23:56:10 LBOK3XqF
>>289
i386 <-> ppc ならありえるレベルだと思う。
というか自分では使っている。
まあalpha,sparcあたりも死んでは無いしな。
292:login:Penguin
06/12/20 00:06:07 K8chhcW1
>>291
i386 <-> ppcって
Vineでも使われてるんですか？
293:login:Penguin
06/12/20 00:09:26 K8chhcW1
まあディス鳥はどうでもいいけど、実際にディスクつなぎ変えるの？
294:login:Penguin
06/12/20 00:19:13 MV22v5Iu
PPCはNAS使ってる一部の勘違いさん御用達。
295:login:Penguin
06/12/20 07:45:13 yU/fzyFw
>>285
> 各ファイルシステムとも4byteのマジックコードを定義してるので
ソース希望
各ファイルシステムで定義するというのはOSのデザインがおかしいと思う
VFSで定義して、各ファイルシステムで実装というのがあるべき姿と思うんだが
296:login:Penguin
06/12/20 07:56:57 yU/fzyFw
というかパーティションテーブルでも同じ問題は起こる
ここを読めないとファイルシステムも読めない
つまり、ファイルシステムを読む段階ではKernelはバイトオーダーを知っていないといけない
こういう問題もあると思うんだが
297:login:Penguin
06/12/20 08:14:22 NEgx20b5
そういえば玄箱とかもPPCだっけ。
298:login:Penguin
06/12/20 10:42:29 TN7cgs5A
>つまり、ファイルシステムを読む段階ではKernelはバイトオーダーを知っていないといけない
linux/fs/* を見ると le32_to_cpu とか be32_to_cpu とかかいてある。
ほとんどはLEだけど、メジャーどこだとxfsがBEだな。
299:login:Penguin
06/12/20 10:53:47 biQx0lWY
>>295
スマソ。全部がというつもりではなくて、fsの多くは独自に
マジックコードを持ってるというつもりで書いた。OS/VFSとかが
マジックがないとダメと規定してるわけではないです。
300:login:Penguin
06/12/20 11:16:07 yU/fzyFw
>>298
> linux/fs/* を見ると le32_to_cpu とか be32_to_cpu とかかいてある。
？
何か勘違いしてるみたいだけど、もう一度言いますよ
パーティションテーブルはファイルシステムを使わず直接ディスクに書き込んである。
ファイルシステムが読めてるって事は、その前に既にバイトオーダーを正しく読んでいるって事が言いたいんですが。
301:login:Penguin
06/12/20 15:42:40 CiR8D7Mp
>>292
Vineは使っていない。
>>300
基本的かもしれないが質問。
パーティションテーブルに書くときのバイトオーダはnative？
302:300
06/12/20 15:49:05 yU/fzyFw
>>301
> パーティションテーブルに書くときのバイトオーダはnative？
多分そう言われるだろうなと思った。
まあ、>>300の内容は当然そう思っているから。
詳しい人よろしく頼む。
303:300
06/12/20 15:59:29 yU/fzyFw
１つ忘れてた。
x86の場合はネイティブだったと思う。
ちょっとサイト探してみる。
304:login:Penguin
06/12/20 15:59:35 3ugUm6GB
パーティションテーブルって一口に言っても
305:300
06/12/20 16:10:54 yU/fzyFw
URLﾘﾝｸ(www.ata-atapi.com)
これMS-DOSのブートセクタ。
当然FDだけど。
バイナリエディタでちゃんとアスキー文字が読めているので、バイトオーダはnativeなはず。
まあ、パーティションテーブルだけ反対とか、HDがFDと違う方法を使うとかありえない訳じゃない。
あくまで参考。
306:300
06/12/20 16:56:18 yU/fzyFw
HDの場合
URLﾘﾝｸ(www.ata-atapi.com)
01 01 00が第一パーティションのスタートCHS
URLﾘﾝｸ(www.ata-atapi.com)
実際のパーティションは先頭セクタがMBRなのでCHS=0,1,1から始まる。
01 01 00が0,1,1を表しているからリトルエンディアン。
x86の場合はネイティブ。
ビッグエンディアンの場合がわからない．．．
307:login:Penguin
06/12/20 17:40:47 iqnu0UKk
>>306
さあ、bigなマシンを調達してくるんだ。
308:login:Penguin
06/12/20 17:42:33 fcZO1G6Z
そこでqemuですよ
309:300
06/12/20 17:52:46 yU/fzyFw
>>308
サンクス
310:300
06/12/20 22:52:54 yU/fzyFw
誰か技量のある人、ビッグエンディアンの検証頼む。
俺もやるけど、簡単じゃない。
パーティションテーブルの仕様もよくわからない。
Qemuもまだ動いてるだけだ。
311:300
06/12/20 22:59:15 yU/fzyFw
多分Sparcの方が資料は多い。
パーティションテーブルは先頭セクタでBSD流のスライスが書いてある。
でも、それ以上の資料が無い。
312:login:Penguin
06/12/20 23:13:46 npYLopAO
XFSはビッグエンディアンのマシンとリトルエンディアンのマシンではジャーナルログの互換性が無いからxfs_repair -Lでログを消す必要があるとドキュメントに書いてある。
元々はIRIXに接続されていたストレージをＡｌｔｉｘに接続するためだったんだけどね
313:login:Penguin
06/12/21 00:40:44 LN3BUO6p
zfs importってやるとSPARCで作成したZFSファイルシステムをx64のマシンで
使えるようになるんだってさ。
314:login:Penguin
06/12/21 13:11:34 1QKYJ/dy
伝統的な dump/restore でのバックアップを
MySQL などの RDBMS が動いているマシンで
行ううえでの問題点は何でしょうか？
データベースのファイルは随時更新されているので
dump/restore ではまったく意味がないのでしょうか？
315:login:Penguin
06/12/21 13:46:14 5fo5L+zb
mysqlのバックアップをわざわざdump/restoreで行う必要はないだろう。
tarなどのファイル単位バックアップでOK。
＞データベースのファイルは随時更新されているので
DBのバックアップはDBを止めて行うのが基本。
dump/restoreにしろ、tarにしろDBを止めないと整合性のとれた状態でのバックアップは不可能。
要件的に止められない場合に、DBMSに用意されているオンラインバックアップなどを検討する。
316:login:Penguin
06/12/21 14:39:14 +wTFdS6A
>>314
> データベースのファイルは随時更新されているので
> dump/restore ではまったく意味がないのでしょうか？
URLﾘﾝｸ(dev.mysql.com)
RDBMSの設計者もバカではないから、随時更新されている程度の事はわかってるよ。
-F, --flush-logs
ダンプを開始する前に、MySQL サーバ内のログファイルをフラッシュする。
注意: このオプションを --all-databases（または -A）オプションと組み合わせて使用した場合、
ログは各データベースのダンプごとにフラッシュされる。
-l, --lock-tables.
ダンプを開始する前にすべてのテーブルをロックする。
テーブルは READ LOCAL でロックされ、
MyISAM テーブルの場合は同時挿入が可能になる。
注意: 複数のデータベースをダンプする場合、--lock-tables は各データベースを個別にロックする。
したがって、このオプションを使用した場合、
データベース間でのテーブルの論理整合性は保証されない。
異なるデータベースのテーブルは、
完全に異なる状態でダンプされる可能性がある。
更新中なのが、前提なのがよくわかるだろう。
実際のところどうしたらいいかは、経験が豊富な人間に聞くしかない。
このスレで質問しても大した事は聞けないよ。
DBの板で質問するべき。
317:login:Penguin
06/12/21 14:49:40 wTdtL7fh
dump違い
318:login:Penguin
06/12/21 14:59:03 +wTFdS6A
MySQLは更新関係にはやはり少し弱い。
Oracleでバックアップコマンドを発行すると、全データベースがロックされ整合性が保証される。
319:login:Penguin
06/12/21 15:12:58 +wTFdS6A
URLﾘﾝｸ(dev.mysql.com)
こっちの方が基本かも。
こちらもちゃんと、更新中であることを前提に書かれている。
320:login:Penguin
06/12/21 16:55:40 5fo5L+zb
＞Oracleでバックアップコマンドを発行すると、全データベースがロックされ整合性が保証される。
思いっきり間違い。
321:login:Penguin
06/12/21 17:23:46 +wTFdS6A
>>314
> 伝統的な dump/restore でのバックアップを
マジ勘違いすまそ
>>320
> 思いっきり間違い。
確かに間違ってますハイ
漏れの場合は表領域デフォルトしか使わなかったので、全データベースのロックもできたけどこれはレアケース
322:login:Penguin
06/12/21 17:29:36 WSqxjtJx
>>316
そりゃDBのダンプやん。スレ違いってことが認識できない知能の持ち主の314が
言っているのはfsのdump/restoreでそ。
>>318-320
スレ違いだから、知能障害者の314は放置してもう止めませう。
323:login:Penguin
06/12/21 19:19:12 gemQUBxV
>>321
全データベースか、特定表領域かの違いではない。
ロックしてしまったら、サービス継続上の問題になる。
ブロックの変更情報がREDOログに書き込まれるようになり、
表領域がホットバックアップ可能状態になるってことだと思う。
324:login:Penguin
06/12/21 19:50:34 5fo5L+zb
話を少し戻すと、DBMSなどのバックアップを
ストレージの3rdミラー（TimeFinderやMRCFなど）を使用することを想定すると、
「Linuxのsyncコマンドでは同期の保証がされない？」ってのは少し気になる問題ではある。
通常、3rdミラーバックアップは、本番機側でsyncを掛けた直後にミラーをスプリットするので、
スプリットされたボリュームのファイルシステムがきちんと整合性取れるのかどうか、ちと不安。
いままで、UnixとWindowsでしか、3rdミラーを使ったシステムを手がけたことがないから、
Linuxリプレイスが基幹系に及んできたらどうなるんだろうか。
325:login:Penguin
06/12/21 19:53:34 4grny1OI
またsyncコマンドか
奥なんとかさん、出番ですよ。
326:login:Penguin
06/12/21 20:02:32 BadC1Qip
>>325
包茎くん乙
もう二度と湧いて出てこないでね。臭いんで。
327:login:Penguin
06/12/21 20:56:54 eQeBXR6E
>>324
> Linuxリプレイスが基幹系に及んできたらどうなるんだろうか。
東証と富士通は Itanium+Linux で行くらしいよ。取引システムの
処理能力がさんざ問題にされたから、そちらを重視なんだろうけど。
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
328:login:Penguin
06/12/21 21:03:57 WbIkO1iK
>>324
> 「Linuxのsyncコマンドでは同期の保証がされない？」ってのは少し気になる問題ではある。
Oracleもこの事の真偽ぐらいは当然知っていると思うから、
もし保証されないのであれば、放置はしていないと思う。
umountで同期できるんだから、同期できないはずはないと思う。
rawデバイス使用時の問題も、含めて。
329:login:Penguin
06/12/22 16:04:30 WqL6S9ur
妻の殺害容疑で勾留中のHans Reiser、Namesysを売却方針
URLﾘﾝｸ(slashdot.jp)
330:login:Penguin
06/12/22 16:13:04 DsPvjvvV
これはもうだめかもしれんね
331:login:Penguin
06/12/22 16:36:02 /iCqG6bS
ReiserFSのためにはむしろいいことかもよ。
彼は優秀な技術者だけど、トラブルメーカーだった。
332:login:Penguin
06/12/22 17:42:56 /1j0azIV
天才が抜けた穴が簡単に埋まるとは思えんがな。
333:login:Penguin
06/12/22 19:00:59 Co7/GRNn
無実を証明するからだれか金を援助してくれ。
一応形式的にだが会社をやるよ。
無実を証明したらまた俺が開発してやるよ。
魅力的なプランだろ？
こんな感じだと思う。
開発するのはアナルだけど。
334:login:Penguin
06/12/22 19:03:52 opUYRnYx
>>333
(;´Д｀)ﾊｧﾊｧ
335:login:Penguin
06/12/22 22:41:01 2mRPP6sE
話ぶった切って悪いんだけど
分散ファイルシステムの話題はここでおｋ？それとも別の場所あるのかしら。
336:login:Penguin
06/12/22 22:43:42 LHAWvpAd
>>335
ここでやっちゃっていいんじゃない？
337:login:Penguin
06/12/22 22:51:33 /iCqG6bS
> 天才が抜けた穴が簡単に埋まるとは思えんがな。
Reiser4はもう基本はできてるだろう。
後は若いPGの仕事でしょ。
Reiser5以降の事は知らない。
これは彼が捕まっていなくてもわからないし、会社を売ってなくてもわからない。
338:login:Penguin
06/12/22 23:32:19 2mRPP6sE
ここでいいか。ではとりあえず・・。
分散ファイルシステムにはAFS（OpenAFS，Arla），Coda，InterMezzoとあるみたいなんだけど，
現状では機能面だとこうで
InterMezzo ＞ Coda ＞ AFS
安定性でみるとこう
AFS ＞ Coda ＞ InterMezzo
こんなんであってる？
あと，NFSv4とかも比較にいれたほうがいいんだろうか。
339:login:Penguin
06/12/23 01:59:13 v667gEsO
>>338
Cleversafe は?
340:login:Penguin
06/12/23 02:20:21 lNb3tcYl
LFSすげーな
4倍以上はやい
NetBSD-current i386
LFS
time tar zxf ~/pkgsrc-2006Q3.tar.gz -C /opt
tar zxf ~/pkgsrc-2006Q3.tar.gz -C /opt 2.06s user 17.66s system 86% cpu 22.773 total
FFS
time tar zxf ~/pkgsrc-2006Q3.tar.gz -C /opt
tar zxf ~/pkgsrc-2006Q3.tar.gz -C /opt 1.94s user 25.83s system 26% cpu 1:43.08 total
341:login:Penguin
06/12/23 10:07:11 pzaVswcy
未だに、NFSv3をUDPで使ってます。
342:login:Penguin
06/12/23 10:43:55 yHT154ws
UDPはUDPでメリット無いのかな？
負荷分散とかしやすそうなイメージがある（イメージだけで裏は取ってない）。
343:login:Penguin
06/12/23 11:09:44 Z2SBvvTY
UDPだから、転送速度が上がるとかｗ
これもあてずっぽう。
344:login:Penguin
06/12/23 11:54:29 /zNuBneV
>>339
Cleversafeって実用に耐えるの？
345:login:Penguin
06/12/23 21:55:41 MNgpS4hJ
メリットがあるから UDP 使ってた訳だが
346:login:Penguin
06/12/24 12:25:32 QbyLMMQt
>>340
softupdateは効かせてある？
それとuser timeに違いがあるのが気になる。同じになるはず。
347:login:Penguin
06/12/24 12:28:30 QbyLMMQt
UDPだとTCPをおしのけて通信できる
でもGbEを使いきろうとするとTCPのような細かい制御が必要。
348:login:Penguin
06/12/24 15:03:41 VUeVRThv
>でもGbEを使いきろうとするとTCPのような細かい制御が必要。
ォィォィ
349:login:Penguin
06/12/24 15:05:47 VUuQmegh
>>347
> でもGbEを使いきろうとするとTCPのような細かい制御が必要。
ウソつくな。
350:login:Penguin
06/12/24 15:17:50 lyOxSAlM
使いきりたいならUDP一択だろ
351:300
06/12/24 15:24:13 xYVNmyrQ
ちわ。
お久しぶりです。
ビッグエンディアンの検証ですが、途中で止まっています。
QemuにPPC版Debianのインスコまでは終わりましたが、アップルパーティションマップの仕様が全く見つからず。
仕方がないので、カーネルソースの中を探していて面白いものを見つけました。
352:300
06/12/24 15:25:54 xYVNmyrQ
linux/fs/partitions/mac.h
struct mac_partition {
__be16signature;/* expected to be MAC_PARTITION_MAGIC */
__be16res1;
__be32map_count;/* # blocks in partition map */
__be32start_block;/* absolute starting block # of partition */
__be32block_count;/* number of blocks in partition */
charname[32];/* partition name */
chartype[32];/* string type description */
__be32data_start;/* rel block # of first data block */
__be32data_count;/* number of data blocks */
__be32status;/* partition status bits */
__be32boot_start;
__be32boot_size;
__be32boot_load;
__be32boot_load2;
__be32boot_entry;
__be32boot_entry2;
__be32boot_cksum;
charprocessor[16];/* identifies ISA of boot */
/* there is more stuff after this that we don't need */
};
353:300
06/12/24 15:28:25 xYVNmyrQ
linux/fs/partitions/mac.h
#define MAC_PARTITION_MAGIC0x504d
354:300
06/12/24 15:29:44 xYVNmyrQ
linux/fs/partitions/mac.c
if (be16_to_cpu(part->signature) != MAC_PARTITION_MAGIC) {
put_dev_sector(sect);
return 0;/* not a MacOS disk */
}
355:300
06/12/24 15:38:08 xYVNmyrQ
ちょっと、読みづらくてすまそ。
>>352の
__be16signature;/* expected to be MAC_PARTITION_MAGIC */
は
__be16 signature; /* expected to be MAC_PARTITION_MAGIC */
がコピペでつぶれてしまった。
これってマジックバイトがパーティションテーブルに書き込まれているように思えるんだけど。
それなら、fsが読む事と、パーティションテーブルを読むことの後先のつじつまが合うんじゃね？
後、アップルパーティションマップの仕様を知っている人は情報を希望。
356:300
06/12/24 15:51:34 xYVNmyrQ
すまそ。
>>353の
#define MAC_PARTITION_MAGIC0x504d
は
#define MAC_PARTITION_MAGIC 0x504d
がつぶれたもの。
ついでだけど、>>354
if (be16_to_cpu(part->signature) != MAC_PARTITION_MAGIC) {
これだとIntel Macは読めない？
357:300
06/12/24 16:29:15 xYVNmyrQ
マジックバイトの話よりこちらの方が重要かな。
>>352を見るとデータはほとんど __be16 か __be32 で渡されている。
マックのパーティションを読む場合に限ればパーティションテーブルの読み込みは、
ビッグエンディアンの決めうちで行われているように見える。
358:300
06/12/24 20:12:13 xYVNmyrQ
その他
fs/partitions/msdos.h
#define MSDOS_LABEL_MAGIC 0xAA55
fs/partitions/sgi.h
#define SGI_LABEL_MAGIC 0x0be5a941
fs/partitions/sun.h
#define SUN_LABEL_MAGIC 0xDABE
359:300
06/12/25 21:38:37 u5v64fWw
今日も連投マジすまそ。
アップルパーティションマップの仕様を見つけた。
URLﾘﾝｸ(developer.apple.com)
内容はほぼ>>352と同じ。
対象ディス鳥のインスコは
URLﾘﾝｸ(www.ne.jp)
ここを参考に行った。
以下、検証資料を載せる。
360:300
06/12/25 21:40:28 u5v64fWw
f-disk -l /dev/hda
/dev/hda
# type name length base ( size ) system
/dev/hda1 Apple_partition_map Apple 63 @ 1 ( 31.5k) Partition map
/dev/hda2 Apple_Bootstrap untitled 1954 @ 64 (977.0k) NewWorld bootblock
/dev/hda3 Apple_UNIX_SVR2 untitled 3941407 @ 2018 ( 1.9G) Linux native
/dev/hda4 Apple_UNIX_SVR2 swap 250879 @ 3943425 (122.5M) Linux swap
Block size=512, Number of Blocks=4194304
DeviceType=0x0, DeviceId=0x0
361:300
06/12/25 21:44:48 u5v64fWw
dd if=/dev/hda of=part.map bs=512 skip=1 count=63
hexdump part.map > part.txt
0000000 504d 0000 0000 0004 0000 0001 0000 003f
0000010 4170 706c 6500 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
0000030 4170 706c 655f 7061 7274 6974 696f 6e5f
0000040 6d61 7000 0000 0000 0000 0000 0000 0000
0000050 0000 0000 0000 003f 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200 504d 0000 0000 0004 0000 0040 0000 07a2
0000210 756e 7469 746c 6564 0000 0000 0000 0000
0000220 0000 0000 0000 0000 0000 0000 0000 0000
0000230 4170 706c 655f 426f 6f74 7374 7261 7000
0000240 0000 0000 0000 0000 0000 0000 0000 0000
0000250 0000 0000 0000 07a2 0000 0033 0000 0000
0000260 0000 0000 0000 0000 0000 0000 0000 0000
362:300
06/12/25 21:45:28 u5v64fWw
続き
*
0000400 504d 0000 0000 0004 0000 07e2 003c 241f
0000410 756e 7469 746c 6564 0000 0000 0000 0000
0000420 0000 0000 0000 0000 0000 0000 0000 0000
0000430 4170 706c 655f 554e 4958 5f53 5652 3200
0000440 0000 0000 0000 0000 0000 0000 0000 0000
0000450 0000 0000 003c 241f 0000 0033 0000 0000
0000460 0000 0000 0000 0000 0000 0000 0000 0000
*
0000600 504d 0000 0000 0004 003c 2c01 0003 d3ff
0000610 7377 6170 0000 0000 0000 0000 0000 0000
0000620 0000 0000 0000 0000 0000 0000 0000 0000
0000630 4170 706c 655f 554e 4958 5f53 5652 3200
0000640 0000 0000 0000 0000 0000 0000 0000 0000
0000650 0000 0000 0003 d3ff 0000 0033 0000 0000
0000660 0000 0000 0000 0000 0000 0000 0000 0000
*
0007e00
363:300
06/12/25 21:48:02 u5v64fWw
0000000-0000060の解析
--------Sig--Pad--MapBlkCnt-PartStart-PartBlkCnt
0000000 504d 0000 0000 0004 0000 0001 0000 003f
--------PartName
0000010 4170 706c 6500 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
--------ParType
0000030 4170 706c 655f 7061 7274 6974 696f 6e5f
0000040 6d61 7000 0000 0000 0000 0000 0000 0000
--------DataStart-DataCnt--PartStatus-BootStart
0000050 0000 0000 0000 003f 0000 0000 0000 0000
--------BootSize--BootAddr--BootAddr2-BootEntry
0000060 0000 0000 0000 0000 0000 0000 0000 0000
364:300
06/12/25 21:49:58 u5v64fWw
以上、PPCの場合もネイティブで間違いないと思う。
もう一度謝ります。
連投すまそ。
365:login:Penguin
06/12/25 21:53:17 A+i14brz
さてここで>>300に問題です。
macパーティションの上にext3ファイルシステムを作った場合
どうなるでしょうか？
366:300
06/12/25 22:02:09 u5v64fWw
誤り訂正
アップルパーティションマップの仕様のリンク
URLﾘﾝｸ(developer.apple.com)
f-disk -l /dev/hda → mac-fdisk -l /dev/hda
>>365
どうなるって、とり方次第でどうにでもとれて意味がよくわからん。
現状は/dev/hda3がext3でマウントされていて、読み書きできてる。
確認不足な点があるなら、追加するよ。
367:300
06/12/25 22:10:13 u5v64fWw
もう一度誤り訂正
リンク先は>>359が正しかったorz
マジ申し訳ない。
368:login:Penguin
06/12/25 22:16:50 xhvW4o8W
謝りすぎすよｗ
369:login:Penguin
06/12/28 20:16:52 11msnvQ0
URLﾘﾝｸ(www.atmarkit.co.jp)
370:login:Penguin
07/01/04 23:31:25 krLFR/+F
Linux: Chasing Down Data Corruption
URLﾘﾝｸ(kerneltrap.org)
Linux: Data Corruption Bug Fixed
URLﾘﾝｸ(kerneltrap.org)
371:login:Penguin
07/01/05 23:50:17 9EtcSPvI
gfs興味あるけど、資料少ないなー
372:login:Penguin
07/01/06 09:56:21 RHHwlQBc
GFS使ったことあるけど、Maildir形式のメールサーバ×４台に使ったら、
ファイルアクセスが遅すぎて使い物にならなかった。
大容量ファイル向きだわ。
GFS2でどこまで進化してるのに興味あるな。
373:login:Penguin
07/01/06 12:01:58 iH08ipQn
使ったことあるならちょっと聞かせてくれ
gfsって、LVMで分割したブロックを他のPCに持って行ってネットワーク経由でアクセスするって考え方でいいんだよな？
（もちろん、冗長化とかでA+AとかA+B+P+Qとかのモデルを取る場合もあるだろうが）
で、LVMってのは、MMUのディスク領域版だよな？
ブロックに分割した領域が、セクタアドレスの再配置を伴って、見かけ一続きのブロック領域としてファイルシステムに提供されるという
なんか根本的に間違ってるかな
374:login:Penguin
07/01/07 12:14:00 kV7nDToe
>>373
セットアップ人任せだったし、結構前だから、もうあまり覚えてないなー。
でもファイル読み書きはSANや共有SCSIで読み書きして、
ファイルロックを専用のネットワークでやるんじゃなかったっけ？
クラスタ組んでる内の１台がロック管理用のサーバになって、
他のホストがそのクライアントみたいな。
で、LinuxのLVMって、まだSistina GFS時代の頃にSistina社が
オープンソースで提供したものだったから、
LVMもGFSも管理方法が似てるとかだったような…。
昔はググってもほとんど情報なかったけど、今はググれば情報あるんじゃない？
375:login:Penguin
07/01/09 01:43:47 1r/HKlFu
鯖運用するのにFSを何にするのかついつい迷ってしまう。
面倒だから ext3 でいいよね?
376:login:Penguin
07/01/09 07:37:31 pFKWUuBq
ファイルがぶち壊れるの、fsのせいかと思ったら、原因はmmap()だったのか…
URLﾘﾝｸ(kerneltrap.org)
377:login:Penguin
07/01/09 08:09:00 8ySvgupC
こんどはgetdentsが遅いって話になってるな。
378:login:Penguin
07/01/13 00:17:35 hhd3ra9J
ジャーナリングファイルシステムが保証するのはメタデータだけらしいですが、
逆にいうとタイムスタンプとかファイルサイズのメタデータが更新されてれば
ファイルの中身は正しく更新されたと考えていいんでしょうか？
379:login:Penguin
07/01/13 00:18:27 /hTyXuuv
んなわけない
380:login:Penguin
07/01/13 08:50:01 LPgOApau
メタデータの何を保証してると思ってるんだ?
381:login:Penguin
07/01/13 13:50:32 7SZBdiSI
保証されるのはメタデータの一貫性じゃね？
データそのものはロストしてもファイルシステムの
健康は損なわれないってことでしょ。
382:login:Penguin
07/01/13 14:40:37 /ysw0X03
希望と中途半端な理解がごたまぜになった妄想
383:login:Penguin
07/01/14 11:07:16 NA5ZaSYQ
chattr コマンドでは dump コマンドによるバックアップ対象に
含めるか否かなどのフラグを操作することができますが、
これらのアトリビュートは ext2/3 特有のフラグです。
xfs や jfs でも同様のアトリビュートの仕組みはあるのでしょうか？
384:login:Penguin
07/01/17 10:59:30 XCRonxTk
>>217
古いネタになりますが..
ext3におけるジャーナル情報の記録はJournaling Block Device Layerを
通して行なわれるのであって、Generic Block I/O Layerが用いられるわ
けではないため、リクエストのソーティングなどは行なわれないのでは
ないでしょうか?
385:login:Penguin
07/01/17 11:29:42 83gvpb7N
>>382
つまりlost+foundにバックアップを取っておけば
いざというとき幸せになれるということですね？
いい意味で
386:login:Penguin
07/01/17 12:45:07 wR6IvIw/
>>384
今は奥山はジャーナリングの不整合っていうのは取り下げていたような気が。
387:login:Penguin
07/01/17 13:20:07 NH1vWgwK
>>386
ソース希望
388:login:Penguin
07/01/17 16:06:16 wR6IvIw/
「書き込み順序にエレベーターシークアルゴリズム などを用いるので、
Journal ファイルへの > Journal 記録の反映順序保証さえない」というのは
最近言わなくなって、その前の「sync システムコールを呼び出しても、
保証されない」というのを声高に主張するようになっているんだったかな。
syncしても書き込まれなのは事実だし。
389:login:Penguin
07/01/17 16:07:15 wR6IvIw/
あ、syncしても書き込まれないから、ジャーナリング不整合になるという結論は変化なしか。
390:login:Penguin
07/01/17 16:11:06 dKhI4BNe
で、その結論は正しいの？
391:login:Penguin
07/01/17 16:19:09 l/++G+GY
奥なんとかさんに聞いとけ
392:login:Penguin
07/01/17 16:36:28 XCRonxTk
最近のXFSはデータを準備してからメタデータを書くという噂を聞いたのだけど
ホント?
393:login:Penguin
07/01/17 18:07:01 BxDmthED
ext3のデフォと同じじゃん
394:login:Penguin
07/01/17 21:49:32 5iSAbmWu
BSDのsoftupdateもヤバくなるから取り下げたんじゃないのん？
395:login:Penguin
07/01/17 22:28:40 +AGvt5ET
>>394
ディスク側に持ってるキャッシュフラッシュのタイミングが気にいらん
ってな、話だっけ?
396:login:Penguin
07/01/18 01:21:11 QSNRktCd
>>395
あと、FreeBSD 5.x以降ではLinux同様syncしてもflushされないのがわかったのもある
397:login:Penguin
07/01/18 02:01:10 jUaHNsmy
>>395
> タイミングが気にいらん
そういう話じゃないだろう
ジャーナルに書き込んだがディスクはまだフラッシュしていない
この状態でクラッシュすると、OSはジャーナルを書き込んだと思っているが実際には書き込まれていない
398:397
07/01/18 02:03:10 jUaHNsmy
あ、すまん
>395はソフトアップデートの話だったな
スルーしてくれ
399:login:Penguin
07/01/18 02:13:17 4qrnvGep
キチガイって伝染するんだな
400:login:Penguin
07/01/18 10:40:41 vfB3lZBF
400
うん
401:login:Penguin
07/01/18 21:07:25 jUaHNsmy
ついでだが、>397の状態でも常に問題が起こらないとする
そうすると、ジャーナルは無用の長物だということにならないか？
402:login:Penguin
07/01/18 22:08:12 fQv5Q68V
問題では歩けど解決策が...ってことだろ
403:login:Penguin
07/01/19 02:41:03 6XfomkSC
ヒント：再起動
404:login:Penguin
07/01/19 12:31:32 T0ADJeSd
まさに伝家の宝刀
405:login:Penguin
07/01/19 20:39:33 4t6qqCPq
ジャーナル破損→再起動→ファイルシステム破損
>>403-404
本当にどうも有難うございました
406:login:Penguin
07/01/20 11:26:20 UaLVa0QY
壊れるのは書き込みの順序が原因で、syncしないことは別問題
407:login:Penguin
07/01/20 11:35:29 gfquQKqH
先生、質問！
１．書き込みの順序の問題が起こっているのはなぜですか？
２．syncしないことで起こる別問題って何ですか？
408:login:Penguin
07/01/20 12:10:54 KTOxmzQl
２は、データ自体が不正になってしまうことだな。
チェックポイント自体は正常に通過したけど、実際にデータが書き込まれていないってことだ。
チェックポイントを正常に通過しているから、ファイルシステム自体が壊れているわけではない。
これは、パフォーマンス上は有利であるが、非常に深刻な問題をもたらすことがある。
１は、媒体エラーによってもたらされるものだろう。
ジャーナルの再作成、fsckが必要になる。
lost+foundに前回のチェックポイント以降の更新データが保存される。
409:login:Penguin
07/01/20 12:17:24 gfquQKqH
返事がないようなので、もうひとつ
３．自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか？
410:login:Penguin
07/01/20 13:45:07 gfquQKqH
返事ぐらいしろよ
つまらないのでWindows2000の話
[書き込みキャッシュを有効にする] 機能を有効にすると、データが失われる
URLﾘﾝｸ(support.microsoft.com)
書き込みキャッシュが有効な場合の遅いディスク パフォーマンス
URLﾘﾝｸ(support.microsoft.com)
「この修正プログラムは、実装に伴うリスクのレベルを理解および承諾し、
適切なハードウェアの電源保護によってこのリスクを軽減できるという確信がない限り、
実装しないでください。」
411:login:Penguin
07/01/20 14:47:24 UaLVa0QY
書き込み順序の問題はディスクのcacheが原因
URLﾘﾝｸ(slashdot.jp)
412:login:Penguin
07/01/20 15:01:37 UaLVa0QY
>>２．syncしないことで起こる別問題って何ですか？
ディスクに確実に書き込まれたことを保証しないといけない場合に困る。
syncの呼び出し後にネットワークで書き込み終了を通知したが、
実際に書き込まれる前に電源が落ちるといったケースが考えられる
>>３．自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか？
syncによって順序を保証する手法もある。
詳細はlinux/Documentation/block/barrier.txtを参照。
但し、処理によっては実用にならない程遅い可能性もある。
413:409
07/01/20 15:15:27 gfquQKqH BE:454855493-2BP(0)
>>412
> >>３．自由なタイミングでsyncできても、書き込みの順序の問題は解決できませんか？
> syncによって順序を保証する手法もある。
実はここが聞きたかったわけで、そうすると
>>406
> 壊れるのは書き込みの順序が原因で、syncしないことは別問題
別問題とは言えないことを自ら返事されたわけです
414:login:Penguin
07/01/20 15:54:53 UaLVa0QY
>>413
確かにそうだけど…
softupdateなんかで依存の発生する場所全部にsyncを入れるのが
現実的？非現実的である証拠のデータが出せなくて申し訳ない
ですが…
415:login:Penguin
07/01/20 16:16:11 gfquQKqH BE:1078176588-2BP(0)
いえ、データ出すのは大変ですから
Windows2000でさえ両方の含みを残している
難しい判断なんでしょうね
416:login:Penguin
07/01/20 17:08:10 UaLVa0QY
ついでに、これも転載
URLﾘﾝｸ(lists.freebsd.org)
417:login:Penguin
07/01/20 17:25:35 snxMEiUl
>>416
そのスレを読んでいくと、ジャーナリングでもsoftupdate同様に
todays desktop drives can lie about writing data.
の影響を受けるっていう、このスレの流れと同様の話になっていっていますな。
418:login:Penguin
07/01/20 23:02:52 SqdA4hO3
ハードディスクが独自に高性能化を辿った結果、
書き込み順についてはどんなに直接sync命令しても確実に保証されるものではないってことかな?
今のhddじゃエレベーターシークアルゴリズムとかは意味がないか逆効果かもとどっかで見たことあるし。
419:login:Penguin
07/01/21 02:52:54 hY5qL1VD
>>418
SCSIとSerial ATA 2.5はFUAによってwrite cache有効時でも書きこみの完了を保証できる。
ので、ドライバがまともに実装されていればOK。
ATAはcache flushを保証する手段が用意されていないので何をやっても無理。
420:login:Penguin
07/01/21 20:35:19 4gtXWK3A
ZFSではwc対策はどうなっているの？
421:login:Penguin
07/01/21 23:48:40 AqF7ihH/
しかし、ジャーナリングファイルシステムって、電源断とかのトラブルでも
ファイルが壊れないようにするものじゃないのか。
実験室での使用なので、けっこう動作環境が良くないのは分かるけど
今日、ext3 また壊れてしまった。フォーマットからやりなおし。
土曜にバックアップとっていて良かった。
やっぱりXFSに移行するかな。
422:login:Penguin
07/01/21 23:55:06 xsvOt/km
ext3が何度も壊れ、
reiserfsの大パーティションのマウントの遅さが嫌になり、
XFSに行き着いて幸せになった俺
423:login:Penguin
07/01/22 00:14:17 ppnVbPRo
たしかに reiserfs はでかいパーティションのマウントに時間がかかるね
424:login:Penguin
07/01/22 00:19:23 RyHURUu7
ちょっと気になったのは、このスレの過去ログ読むとLinuxのVFSのせいで
XFSでもファイルシステムが壊れるって聞いたけど、どうなの?
425:login:Penguin
07/01/22 00:34:54 Mwx+Gzyg
XFSはファイルシステムが壊れるよ
ext3はファイルは守ってくれないが
ファイルシステムは守ってくれるので
まだ安心
426:login:Penguin
07/01/22 00:56:30 RyHURUu7
それじゃ、ダメじゃん。
427: ◆IIiDC8JS7w
07/01/22 00:59:28 v/DQ0Ap0
ZFS to the FUSE
まだα版だけど。。
つ URLﾘﾝｸ(developer.berlios.de)
428:login:Penguin
07/01/22 02:58:08 4mh5V91p
まぁいろいろ悩む前にUPS買えってことで。
あとは日々のバックアップ。
429:login:Penguin
07/01/22 04:59:17 g7VFvdpY
FUSEじゃ読み書きできますよっていう程度で、本格的に使うのには
全然向かないな…
430:login:Penguin
07/01/22 19:52:31 aXULs4Jv
GFS使ってる人、手ageて。
431:login:Penguin
07/01/22 19:54:33 I6ul0rfb
デスクトップでJFS使い始めました。
前はReiserFSでした。
今のところ無問題。
432:login:Penguin
07/01/22 21:44:43 CllrhvyS
>>421
どんなFSでも、ジャーナルにしてもRAIDにしてもファイルが壊れない
(壊れ難い)という認識は止めたほうが安全。
復旧を早くする方法論と割切ったほうがいい。
大切なデータはきちんとバックアップすること。
433:login:Penguin
07/01/22 21:46:12 vkPy7i3I
>>431
毎日cvsでgcc取ってきてビルドしてみて。
漏れは3年前emacsでそれやってたらfs壊した(XFS)。
434:login:Penguin
07/01/22 22:03:40 +MxoKgNb
XFS ってそんなに弱い子なのか。
435:login:Penguin
07/01/22 22:11:02 gyatXghJ
gentooでほぼ毎日何かしらをコンパイルしたり、
時々動画をエンコしたり、
毎日えろまんがを読み漁っていますが、
XFSは元気です。
436:login:Penguin
07/01/22 22:18:21 6fw9D8r3
ファイルシステムを何にしてもHDDガリガリさせるのは
寿命を縮めるだけだから、できることならあまりやりたくないね。
437:login:Penguin
07/01/23 00:06:35 yhm1O3f9
>>436
それじゃlocateが動くLinuxは使えんがな。
438:login:Penguin
07/01/23 10:58:00 SMWMFAIy
locate は使えば便利なんだけど
知らない人とか使わない人にとっては負荷が無駄過ぎるな。
デフォルトで動くディストリも結構あるんじゃないの。
439:login:Penguin
07/01/23 13:21:33 Dh6zD8CC
HDDの代わりにi-RAMとかフラッシュディスクを使えば解決
440:login:Penguin
07/01/23 13:28:42 dy5DSgJl
ガリガリ使えばHDDよりフラッシュのほうが寿命短いんじゃないの？
441:login:Penguin
07/01/23 14:18:58 Qe3f9h84
そこでMRAMとか相変化RAMとかですよ！
442:login:Penguin
07/01/23 14:32:40 L6fiHwdO
HDD の寿命とか気にしてたらまともに使えんだろう
443:login:Penguin
07/01/23 15:01:52 5Whe9XEV
フラッシュの方が圧倒的に短いわなｗ
444:login:Penguin
07/01/23 16:30:58 JInqPF8n
ハイブリッドハードディスク楽しみだよねえ。っと。
URLﾘﾝｸ(www.itmedia.co.jp)
# スレ違い。
445:俺用メモ
07/01/23 16:48:37 JpiPeEcZ
<kernel-src>/Documentation/filesystems/ext4.txt
NOTE: The "extents" mount flag is temporary. It will soon go away and
extents will be enabled by the "-o extents" flag to mke2fs or tune2fs
URLﾘﾝｸ(www.die.net)
For kernels after 2.3.3 there is no such limitation
URLﾘﾝｸ(www.die.net)
the maximum size is just under 1 TiB.
446:login:Penguin
07/01/23 17:00:50 xbr0LMQ0
FUA 関係なくデータのロストが防げるなら
フラッシュは大歓迎なんだけど、
そういう目的じゃないようなので
Intel の Robson でいい気もする。
447:login:Penguin
07/01/23 17:14:46 0oMO9Ojw
>>446
> FUA 関係なくデータのロストが防げるなら
ハイブリッドディスクはデータロストしないんじゃねぇ？
ライトキャッシュが不揮発性というのは大きいと思うんだが
448:login:Penguin
07/01/23 17:34:03 0oMO9Ojw
もちろん、ソフト側が正しく制御する前提だけど
449:login:Penguin
07/01/23 21:19:21 SMWMFAIy
フラッシュメモリってライトキャッシュに使えるほど
書き込み耐久性あるの？
450:login:Penguin
07/01/23 21:27:38 xbr0LMQ0
フラッシュに入る前にも当然8MB程度の
RAMがキャッシュメモリとして確保されていると思われ。
なのでその部分はやはり揮発すると思う。
451:login:Penguin
07/01/23 21:44:21 L4TUXWzd
>>450
揮発するといってもトランザクションを実行するくらいの
コンデンサ容量は確保されてるでしょ・・・・
452:login:Penguin
07/01/23 21:51:03 0oMO9Ojw
>>450
ハイブリッドハードディスク
URLﾘﾝｸ(www.google.co.jp)
どこにも8MB程度のRAMのキャッシュメモリの話はないですが
自分で確認してください
453:login:Penguin
07/01/23 22:17:31 xbr0LMQ0
>>452
DRAM のキャッシュと不揮発のキャッシュを
併用することになっている。
URLﾘﾝｸ(pc.watch.impress.co.jp)
454:login:Penguin
07/01/23 22:23:32 0oMO9Ojw
>>453
URLﾘﾝｸ(japanese.engadget.com)
ハードディスクドライブのバッファを大容量NANDフラッシュメモリに置きかえたハイブリッドHDD
455:login:Penguin
07/01/23 22:35:32 8K+SLyEi
開発者の発表スライドにengadgetの記事で反論する珍行動
456:login:Penguin
07/01/23 22:52:33 xbr0LMQ0
>>454
そうは言うが、Samsungのホワイトペーパーでも
First, Hybrid HDD has flash memory playing a supplementary
role to DRAM in order to dramatically reduce the boot time
and improve system capacity.
URLﾘﾝｸ(www.samsung.com)
とあるので、DRAMによるキャッシュも積んでいるんだと思う。
DRAM→NVRAMはいきなりの電源断でも書ききれるという意味で
データが失われないという仕組みは可能だと思うが、
DRAM無しというのは難しいんじゃないか？
そもそも上に出したWinHEC2006のスライドも元は
Samsungの描いた絵だし。
457:login:Penguin
07/01/23 23:51:46 0oMO9Ojw
>>456
>>453の図と>>456の図はほぼ同じなんだが、どちらの図にもI/O両方の矢印がある
この両方向でDRAMをスルーしてNVRAMにアクセスしている
ハイブリッドディスクはブート時に1-2KBのRAMにブートセクタをコピーするんだが、このDRAMキャッシュはその部分の事ではないのか？
>>456を翻訳しても、ズバリ、キャッシュに使っているというようには訳せないんだが
458:457
07/01/24 00:17:56 vzigmnXE
× NVRAM
○ NANDフラッシュメモリ
459:login:Penguin
07/01/24 00:38:31 uMM8sw+h
だから MRAM,FeRAM とかの高速不揮発メモリに
期待って話だったんじゃねーの?
460:login:Penguin
07/01/24 01:39:30 Wx+4qs1R
耐久年数と揮発/不揮発は関係あるの？
461:login:Penguin
07/01/24 02:19:19 OH8//z4U
耐久年数が多いと揮発しにくいので、一度書いたら
上書きがとても大変
462:login:Penguin
07/01/24 08:32:43 vzigmnXE
>>460
現行のフラッシュメモリは耐久年数は低いとされている
しかし、>459のMRAMは耐久年数のみならずスピード自体も揮発性メモリより高い
FeRAMもMRAMに準ずる
463:login:Penguin
07/01/24 15:27:52 fll6hQgJ
フラッシュメモリが高い耐久性を持ってなきゃいけない必要性はない。
ハミング符号なりで保護して不良部分を置き換える下のレイヤーを一
層設ければ耐久年数は無視できる問題ではないか?
464:login:Penguin
07/01/24 16:04:57 vzigmnXE
URLﾘﾝｸ(webleverage.jp)
Intel Macのマルチブートっておもしろいねえ
OSX用と全く同じ内容のMS-DOS用のパーティションテーブルを作ってるよ
465:login:Penguin
07/01/24 16:17:28 mEXlFMcS
>>463
そういうのも含めての耐久性じゃない？
466:login:Penguin
07/01/24 16:22:03 vzigmnXE
>>463
現状すでにやられてる話でしょ
467:login:Penguin
07/01/26 03:11:35 9ovjxSc8
現状でも、書き込み寿命の均一化はやってあるよ。
それでやっと今の寿命になってる。
個人的には、停電時にファイルを確実に守る方法は
UPS以外に有効な方法は無いと結論をだしてる。
468:login:Penguin
07/01/26 15:45:58 S6wJxTFd
確実な方法なんてないと知るところから全ては始まるんだがな。
# ようは何処まで守りたいか、という話
469:login:Penguin
07/01/26 21:20:42 LxxsiSqP
そういうこと
どこまで妥協できるかだね
470:login:Penguin
07/01/27 02:04:17 hzYyrGKz
俺は大切なデータは石に彫って埋めてる。
471:login:Penguin
07/01/27 06:38:54 E9E1wd6D
>>463
NAND型フラッシュメモリ
URLﾘﾝｸ(ja.wikipedia.org)
一般的なデータ書き込みおよび消去後、
不良ブロックの検知処理を行い、
不良ブロックを管理するロジックが組み込まれている。
．．．
各ブロックの書き込み消去回数が平均化するようにする手法が広く用いられている。
472:login:Penguin
07/01/27 09:08:22 u9/4vZC9
>470
ちゃんと3か国語位は並べておけよ
473:login:Penguin
07/01/27 09:57:51 4NCB46QC
Hans Reiser、近況
URLﾘﾝｸ(opentechpress.jp)
「Hansを陥れるための罠」を仕掛けたのは
ロシアのスパイ組織じゃなくてext4の中の人じゃないか？
474:login:Penguin
07/01/27 10:21:57 NEv34+KY
ロシアとはまた厄介な
475:login:Penguin
07/01/28 21:50:55 Znedwxfp
SDなんかだとうすっぺらいですが、あの中にそんなロジックが入ってい
るんですか? 知らんかっただけにちょっと驚き。
476:絶対☆妹至上主義
07/01/29 02:05:06 ncjfs3KH
>>471
NANDでも、何度でも書き込めるわけでは無いんだな
477:login:Penguin
07/01/29 02:33:50 dIKGkRrE
誰がうまいｋ（ｒｙ
478:login:Penguin
07/01/29 13:41:07 siKMYi/7
そのツッコミがなければボケの存在に気付かなかったよ。
479:login:Penguin
07/01/29 22:12:15 aMwlfPuf
>>475
それはデバイスドライバの仕事
480:login:Penguin
07/01/30 22:33:33 ysSJZIzG
ここならlusterやってる人いるかな
1.4系と1.6系があるんだが、どっち使ってる？
481: ◆IIiDC8JS7w
07/01/30 22:40:38 gRlPMLvw
今はLustre 1.6Beta7(2007/1/15付近にでたもの)
482:login:Penguin
07/01/30 23:07:08 ysSJZIzG
サンキュー>481
余ってるPCが4台ほどあるので、試しにluster組んでみるよ。
483:login:Penguin
07/02/01 12:33:57 AuhPSHSf
LinuxのVFSがダメだって何度もこのスレで見たけど、
具体的にどこがどのようにマズイの？
484:login:Penguin
07/02/01 12:40:05 z56kQWBE
syncを発行しているのに実際にディスクに書かない、と言うのが通説
(ちと古いか)。
485:login:Penguin
07/02/01 16:31:34 d0gGLI0t
>>484
最近のはFreeBSDもそうらしいね
486:login:Penguin
07/02/01 17:04:59 lF996rlo
(OSが)syncを発行して(書き込みOKもらって)いるのに実際に(HDDが)ディスクに書かない
487:login:Penguin
07/02/01 17:07:38 KD9t2gZH
1月版 ext3でデータが破損！？ メモリ管理で不整合
URLﾘﾝｸ(www.atmarkit.co.jp)
>Debian独自のパッチの影響
ZFS progress.
URLﾘﾝｸ(blogs.freebsdish.org)
>98% functionality is implemented and work.
488:login:Penguin
07/02/01 17:23:14 DApPY+KS
>>486
>>376でガイシュツ。あと、読み間違えてないか? 2.6.18ではDebianパッチの影響だけど、
2.6.19では標準のカーネルでも発生するぞ。
んで、ZFSはFUSEだから正直問題外。
489:login:Penguin
07/02/01 17:32:32 sGGvNr2g
誰も、2.6.19では起こらないといってないんじゃないかw
490:login:Penguin
07/02/01 17:35:04 RxKMsyN1
そもそも、ZFSなんてlinuxで使うやついないだろ
491:login:Penguin
07/02/01 17:38:25 lF996rlo
>using Linus' test-program the data corruption has been reported
>as far back as the 2.6.5 kernel. "It's not actually a new bug at all,"
URLﾘﾝｸ(kerneltrap.org)
実は2.6.5以降から問題は発生してたらすぃけど、どうなんでしょ。
それと486はSoftupdate vs Journalingの話かな、どっちかというと。
492:login:Penguin
07/02/01 18:04:36 z56kQWBE
>>491
問題はあったけど、2.6.19で表面化したと書いてあるだろう。
URLﾘﾝｸ(www.atmarkit.co.jp)
493:login:Penguin
07/02/01 18:15:01 9sgJPste
>>484
ATAだとwrite cache無効に設定しないとあんまり意味ないし。
# 一回デフォルト無効にしたら遅すぎるっていう苦情だらけで
# デフォルト有効に
SCSIは問題無し。
494:login:Penguin
07/02/01 18:16:32 9sgJPste
>>484じゃなくて、>>485だった。
495:login:Penguin
07/02/01 18:18:17 DApPY+KS
うが、>>486じゃなくて>>487だ。
>>489
>>487の書き方は誤解を招くような代物だったので。
>>490
NTFSの場合はデュアルブートの際やUSB HDDつなげた際に読み込めるというメリットが
あるけど、ZFSにはそういうメリットないものねぇ。きちんとkernel空間で実装して
ext4、JFS、XFSなどと同様に標準fsとして使えるようになっているのなら話は全然別だけど。
ZFSに関してはFreeBSDやOS Xにどうportされるのか注目かなぁ。
>>491
とりあえず、大きなファイルをmmap()するようなアプリを使う際は2.6.19.2に
しておいたほうがいいというのは確かかな。>>487の記事では2.6.20rc3以降なら
fixとは書いてあるけど、2.6.19.2でもfixされたことは書いていないのがアレだ…
496:login:Penguin
07/02/01 18:23:42 z56kQWBE
>>493
ファイルシステムの下には ATAやSCSIのディスクだけじゃなくて、
SAS,バッテリバックアップされたRAID,iSCSI,AoEなどなど
いろいろあるんですが、そのへんはどうなんすかね？
497:login:Penguin
07/02/01 18:31:16 DApPY+KS
>>496
各種デバイスの仕様と、そのデバドラのつくりによるとしか言いようがない。
SCSIやSATAだとFUAが使えるからデータをディスクへ書き込んだ時点で
終了通知をホストへ返すことができるわけだけど、デバドラがきちんと
作られていないのなら、デバイスレベルでFUAをサポートしていても
無意味なわけで。
498:login:Penguin
07/02/01 18:35:46 MMx52a8R
ストレージクラスなら、キャッシュへの書込みが終了した時点で返す。
もっとも、それは電源がちょっと落ちたところでキャッシュの中身が消えることがないようになっているわけだが。
499:login:Penguin
07/02/01 18:40:06 eaIr3GB1
>484 が言っているのは >486 のより手前の
OS に責任があるレイヤでの問題
ただし、結局その説が正しいのかどうかはよくわからん
500:login:Penguin
07/02/01 18:52:05 z56kQWBE
>>499
だから、そんなレベルでOSが責任をとってもデータがダメになる
ケースは多数あるわけで、それなら始めからベストエフォートに
してページキャッシュをいろいろ最適化したほうがマシ、というのが
Linuxの設計方針だろ。Linuxカーネル解読室とか読めよ。
501:login:Penguin
07/02/01 18:53:40 8hEfCwF0
>>499
このスレでも何回か出ている話題だけど、>>384-419あたりの議論でだいたいの結論がついてないか?
502:login:Penguin
07/02/01 20:50:11 n6dF5ODI
>>500
それはおかしくないか？
ユーザーによってニーズは違うだろう
スピードへの最適化と信頼性への最適化の２つの選択肢を与えるべきじゃないのか？
503:login:Penguin
07/02/01 21:04:29 8kIqyObB
Linuxカーネル解読室ってオライリーのunderstanding the linux kernel 3rd edition より良いの？
504:login:Penguin
07/02/01 22:04:54 bacTwvVC
>>501
長すぎるからサマライズキボン。
キチガイは伝染する？
>>502
信頼性欲しければ違う実装使えってことだろ。
それか自分で作るか。作ってもLinuxにはマージしてもらえない気がするが。
>>503
後者の2版和訳を読んだ限り上っ面の説明しかできていない。
前者は読み込んでないから知らぬ。
505:login:Penguin
07/02/02 02:15:32 LHpcI4XW
>500
そんなヌケサク説明を本気で信じてるの?
解決策にもなんにもなってないし...
506:login:Penguin
07/02/02 21:15:48 FrGCgZny
結局、まっとうな批判に対して「キチガイ」と罵ることしかできない
ということでFAか？
507:login:Penguin
07/02/02 21:24:00 zNdISUUI
はいはい
508:login:Penguin
07/02/02 21:28:42 T7lvryZy
いや、大したことのないレスにキチガイって返す方がおかしいよ
509:login:Penguin
07/02/03 03:37:04 kg/qeKbc
>>491
その情報が正しいとなると、RHEL4.5で修正入るのかな?
510:login:Penguin
07/02/03 14:58:47 5bzUz2co
とりあえず、504は放置しとけ
511:login:Penguin
07/02/04 12:40:11 SIrUcCus
XFSとext3とReiserFSだとどれが安全?
512:login:Penguin
07/02/04 12:43:34 I1zy8FgT
どれも危険極まりない。
お前が使えば。
513:login:Penguin
07/02/04 16:27:09 VendWddW
>>511
今からならReiserFSがいい。
状況は今がドン底。逆にこれ以上悪くなる心配がない。
後は這い上がるのみ。
514:login:Penguin
07/02/04 17:21:58 J2syga+J
>>511
つかちょっと上のレスも見らんないのお前は？
JFSだけはガチってのがこのスレの総意だろ。
515:login:Penguin
07/02/04 17:33:06 OnmEjYbp
ガチ、か…
516:login:Penguin
07/02/04 18:34:37 e+PaBkqY
スルーされ具合についてはガチだな
517:login:Penguin
07/02/04 18:38:09 KaQxELcg
今からならＲｅｉｓｅｒ４だろ
518:login:Penguin
07/02/04 18:41:31 OUXrG2xd
俺はせっせと Solaris に移行中
519:login:Penguin
07/02/04 22:08:15 SIrUcCus
JFSのトラブルの報告が無いのは誰も使っていないからだろ?
520:login:Penguin
07/02/04 22:10:05 /f4Jfrib
Yes, SIr!
521:login:Penguin
07/02/04 22:12:54 6B5J03Tx
使ってますが何か
522:login:Penguin
07/02/04 23:07:54 BkRpNHOD
>>521
お前だって、最悪飛んでもいいパーテーションでしか使ってないだろ。
523:login:Penguin
07/02/04 23:15:37 wTKNJ/kp
>>518
Solarisって使いやすさはどうなの？
パッケージ管理が簡単なのかどうかと、パッケージ数が豊富なのかどうかが気になる。
昔はGCC入れて、各種アプリを自前コンパイルしないといけない時代があったよね。
524:login:Penguin
07/02/04 23:24:50 I1zy8FgT
今も基本的にはそうだが。
Sunfreewareのビルドが気に入らなければ、自分で作るしかないから。
パッケージ管理そのものについても、RPMやdebほど洗練はされていない。
パッチとか当てると普通に設定ファイルを上書きしたりするから、注意がいる。
525:login:Penguin
07/02/04 23:34:10 9s1+/enK
JFS はハードディスクが壊れただけでファイルシステムがぐちゃぐちゃになったので糞。
あと、NLS でちゃんと変換出来ないファイル名のファイルを作るとロストするときがあったので糞(相当昔の話だが)。
526:login:Penguin
07/02/04 23:45:28 ScyYaqVx
> JFS はハードディスクが壊れただけでファイルシステムがぐちゃぐちゃになったので糞。
527:login:Penguin
07/02/04 23:53:20 l/38o1m3
ちゃんと書かないとつたわらないだろうな
528:login:Penguin
07/02/05 00:10:05 xJuCgkva
HDD が壊れても大丈夫な FS 欲しいなぁ
529:login:Penguin
07/02/05 00:11:54 yquMgini
>>528
ひょっとしてそれはギャグで言ってるいるのか？
530:login:Penguin
07/02/05 00:18:06 rnFpdWND
ネットワークファイルシステムならHDDに書かないから安心。
531:login:Penguin
07/02/05 00:21:47 BjEiAhlg
サーバ側のローカルファイルシステムが(略
532:login:Penguin
07/02/05 00:51:26 TwCWVt0g
ネットワーク上に不良パケットとして放流するファイルシステム。
寿命が尽きる前に再放流。
常にネットワーク上をさまようデータたち。
533:login:Penguin
07/02/05 00:57:12 3z2RfYJO
Winnyファイルシステムかよｗ
534:login:Penguin
07/02/05 01:06:37 ikYVMwPI
>533
セキュアさが技術的に担保されるなら大アリ。
というか、似たものは既にある。
535:login:Penguin
07/02/05 02:16:43 3k+6xyTA
XFS使い始めて、もう１年になるがこの間、FSごと壊れたのは
まだ３回しかないが、これは運が良かったのか?
536:login:Penguin
07/02/05 02:32:05 B8r6Q64G
3回も壊れてるとかチョーウケル。
537:login:Penguin
07/02/05 02:34:35 1UIejfif
HDDが壊れたんだよな？
538:login:Penguin
07/02/05 04:49:19 3k+6xyTA
>>535 のHDDは物理的には全然平気だった。
そのHDD、別のPCに入れてWindowsXPで
使っているけど、普通に動いている。
539:login:Penguin
07/02/05 07:08:06 FEECW1nx
チキンは俺は ext3
540:login:Penguin
07/02/05 11:36:52 dxgxznv4
一度 RAIDコントローラが発狂して全滅したことはあったけど、
8年間使っててext2|3,reiser3,xfs,jfsいずれも問題ないな。
もちろん適材適所だよ。
541:login:Penguin
07/02/05 16:16:34 1UIejfif
>>538
情報thx
3度もというと結構多い感じするけど、どういう状況でそうなったの？
電源プチとかブレーカー落ちたとかそういうH/Wまわりしか思い浮かばなかったんだけど
IRIXでXFS使ってたときはFS壊れたことっていうのが無かったので
542:login:Penguin
07/02/05 17:09:15 kXNVJxPh
IRIXも最初のころはFSに限らずしょぼいしょぼいといわれていたけどね！
543:login:Penguin
07/02/05 22:41:56 xJuCgkva
最後までショボイまま終わったと?
544:login:Penguin
07/02/06 23:35:16 wGCOby4y
Excelが同期書き込みを使っているように感じているのは俺だけなのだろうか？
545:login:Penguin
07/02/08 21:38:43 yfGJF1IC
Excelってそれどんなfs？
546:login:Penguin
07/02/08 21:49:46 xdYwexjj
NTFS
547:544
07/02/08 22:00:34 xdYwexjj
１．セーブアイコンをクリック
２．ハードディスクがガリガリいいはじめる
３．マウスポインタは砂時計表示に
４．ステータスバーの進捗状況が作業中を表示
５．ステータスバーの進捗状況が作業終了を表示
６．ハードディスクがガリガリ音が止まる
７．マウスポインタが通常に戻り、Excelに制御が戻る
いつもこのような状況なのでそう思っただけ
ちなみにハードディスクはパラレルATA
548:login:Penguin
07/02/08 22:09:56 9ICUpqjJ
>>547
最近はLinuxでもExcelが動くようになったんですね。
是非、方法を教示していただきたいのですが。
549:login:Penguin
07/02/08 22:14:14 yfGJF1IC
>>547
(・∀・)・・・・・・・・こ、これは・・・・
ゴメンいい釣られ方思いつかなかった
550:login:Penguin
07/02/08 22:22:51 xdYwexjj
>>548
>>549
Excelの例をだしたのは悪かった
言いたいことは一つで、パラレルATAが同期書き込み不可なのが
正しい根拠があるのか疑問をもっただけ
FUAがないだけでは根拠にならないから
551:login:Penguin
07/02/08 22:24:56 xI5jKKjE
有るし
552:login:Penguin
07/02/08 22:26:01 xdYwexjj
>>551
ソース希望
553:login:Penguin
07/02/08 22:38:19 xdYwexjj
ATA
URLﾘﾝｸ(community.osdev.info)
ちなみにここでATAのコマンドを調べると、
0xe7に
0xe7 No-Data FLUSH CACHE
これはPIO制御なのでUDMA時は発行できないのかもしれないが
0xe8 PIO-Write WRITE BUFFER
こういうのもあるんだが
554:login:Penguin
07/02/09 00:41:33 Zb41PA+h
>>548
wine
555:login:Penguin
07/02/10 23:48:20 DJ1EsE63
今日、USBメモリを挿入した瞬間OSがフリーズした。
リセットボタン押して再起動したら、ファイルが lost+found に
大量に送り込まれた... orz
ext3 お前もか...
FC6やめた方がいいかな?
556:login:Penguin
07/02/10 23:52:49 rfqyKqr7
pugya-
557:login:Penguin
07/02/11 00:34:30 LZDtKzf8
>>553 ディレクトリ操作中に電源を落とした場合の典型的な症状だ
と思うけど。まさかそういうのも含めて「ファイルシステムが壊れた」
とか言ってるの？
558:login:Penguin
07/02/11 00:47:04 ukTcRXps
＞USBメモリを挿入した瞬間OSがフリーズした。
が一番Linuxのダメさを表わしてるわな。
559:login:Penguin
07/02/11 00:52:07 CJAQk2DO
>>558
俺もその光景を目撃した経験があるな．．．
エンジニアが若いSEに必死で弁解してたよ
560:login:Penguin
07/02/11 01:01:56 3+IsEM3X
俺iPodをWindowsマシンに接続した瞬間にブルースクリーンになったことある。
同じマシンに入ってるLinuxではちゃんとiPod使えたのに。
で、そういうトラブルのときWindowsでは対処法を探すのが難しいんだよな。
561:login:Penguin
07/02/11 01:02:23 /aD5Y840
脳内で fs 障害が発生しているようで、ご愁傷様です。
562:login:Penguin
07/02/11 01:14:56 ukTcRXps
まあ、USBはChipが悪いのが原因てことも多いからな。
563:login:Penguin
07/02/11 11:24:35 t4TvBlHe
いきなりリセットかけたときの、ファイル or FS へのダメージに
関して言えば、最近はLinuxよりもWindowsの方が安全なように
思えるようになってきた。
564:login:Penguin
07/02/11 11:42:26 P7PjeCmr
>>563
今ごろ気付いたのかよ
565:login:Penguin
07/02/11 12:56:32 iSwVn+BM
>563-564
この間LinuxとWindowsをVMwareのゲストで動かしてる最中に停電でホストが落ちちゃって、
再起動後どっちのゲストも起動しなくなっちゃったんよ。
Linux(ext3)の方は仕方ないからシングルユーザモードで起動してfsckかけたんだけど、
Windows(NTFS)の場合は一体どうしたらよいか分からなくて、現在進行形で途方に暮れてる。
何度スキャンディスク掛けても復活しないし。
566:login:Penguin
07/02/11 13:28:42 OboOTrcF
pugera
567:login:Penguin
07/02/11 13:53:58 itbL0uDG
>>562
チップじゃなくて外付けの回路かもな。
ろくにテストも出来ない検査が駄目なのか、
検査基準を甘々にしなけりゃならない程、
ハード屋がだらしないのか知らんけど。
568:login:Penguin
07/02/11 18:05:38 4xgL+aKM
>>565
たまたまだろ
Linuxだって死ぬときゃ復活もクソも無い
569:login:Penguin
07/02/11 23:11:39 t4TvBlHe
うちの会社では最近では、逆に Windows鯖も置くようになってきた。
昔のようなLinuxに対する神話というか盲信がなくなってきたからね。
570:login:Penguin
07/02/11 23:23:04 4cTo2V09
>Linuxに対する神話
ナニソレ?
571:login:Penguin
07/02/11 23:53:13 t4TvBlHe
Linuxは安定している。Linuxは安全である。Linuxは高性能である。
Windowsはその逆、っていう話のことを言った。
572:login:Penguin
07/02/12 00:02:21 CJAQk2DO
>>571
確かにそういう神話はあった
Linux関係の雑誌は特にひどかった
とりあえず褒めておけば売れるだろうという姿勢がみえみえだった
573:login:Penguin
07/02/12 00:08:28 ehOYrnXS
Xを使うと、Linuxは非常に重かったが、Windows95はPentium160Mhz,32MBでサクサク動いた（不安定だが）
このあたりの事は一切ふれられず、Linuxは軽いと言われてた
かくいう漏れも信じていたが
574:login:Penguin
07/02/12 00:18:36 c1CrXUSo
そんなに性能あれば X 使ってもサクサク動くね。
575:login:Penguin
07/02/12 00:22:43 vlEBE2dx
なぜかSolaris鯖復活。x86版だけど。
576:login:Penguin
07/02/12 00:37:24 ehOYrnXS
>>574
実際使った事あるのか？
32MBのメモリじゃXはスワップしまくって実用に耐えなかった
サービス止めまくってウィンドウマネージャにAfterStepなどを使っても無理
topでメモリ使用量見るとXだけで100MBぐらい使ってた
Xを使わなければ快適だったよ
577:login:Penguin
07/02/12 00:47:48 pKQ9EzWP
>>576
AfterStepじゃだめだ、tvtwm(twmよりも何故か軽い) とかにしないと...
578:login:Penguin
07/02/12 00:50:45 HIG9qOky
はて？
うちのdebianくんは、KDE3.2をスタートした時点で、トータル100MBも使ってないけど。
しかも、SendmailやらApacheやらいろんなサーバが起動した状態で。
579:login:Penguin
07/02/12 00:53:19 ehOYrnXS
>>577
tvtwmは使わなかったがtwmは使ってみたよ
結果は全くだめ
問題はX自体のメモリ消費量なんだよ
> AfterStepじゃだめだ、tvtwm(twmよりも何故か軽い) とかにしないと...
こういう事言ってる事自体が重い証明だろ
580:login:Penguin
07/02/12 00:56:02 tKkO1evC
フォント読み込みすぎだったんじゃね。
あとtwmよりfvwmのほうが軽かったような。
581:login:Penguin
07/02/12 00:59:08 ehOYrnXS
>>578
> うちのdebianくんは、KDE3.2をスタートした時点で、トータル100MBも使ってないけど。
それは異常だよ
漏れは256MBのVine機を持ってるが、Xを使ってしばらくたつと必ずスワップする
俺もLinuxは好きだが、神話はうんざりだ
582:login:Penguin
07/02/12 00:59:32 gH4+PeS3
もうコンソールでいいよｗ
583:login:Penguin
07/02/12 01:02:56 pKQ9EzWP
でもFSが壊れるのは神話じゃなくて事実だよね。
VFSが安定しない限り、この状況は続く...
584:login:Penguin
07/02/12 02:21:48 ue41F/Co
昔 166MHz 32MB で X と windowmaker と emacs と kterm 同時に使ってたけど
普通に使えてたよ。XFree 3.x 時代ね。
さすがにネスケとか立ちあげる時は emacs 落とす必要があったけど。
ただ、その後 update していくなかで X はどんどん重くなっていったので、
最新の X 入れたりしたらさすがに32MBじゃ足りないんじゃないかな。
585:login:Penguin
07/02/12 02:36:22 CD7jXCIx
はて？
うちのUbuntuくんは、Gnome2.16.1をスタートした時点で、600MBも使ってないけど。
586:login:Penguin
07/02/12 02:47:55 xmU+xA4+
793876 tty1 SL Feb11 37:31 Xgl
88540 ? Ssl Feb11 4:19 java v2c
76460 ? Sl 02:35 0:21 fx2
食いすぎだよな。
Xgl単独で800Mってもうあふぉかと。
beryl再起動直後でも458780。
587:login:Penguin
07/02/12 02:50:36 ue41F/Co
>>581
スリープ中のバックグラウンドプロセスじゃないの？
588:login:Penguin
07/02/12 02:52:51 PeW+mj3q
サーバでGUI常時動かす時点でどうかしてる。
ところがwindowsはGUIにOSがくっついていてGUIを止めれない。
スレ本来のFSに注目すると、
windowsのFSが逝きにくいのは事実。
だけれども、書き込み時のバッファフラッシュが強烈に重い。
linuxはVFSの段階でアクセスを最適化しようとするので重くなりにくいが、
その反面電源落ちクラッシュしやすい。
589:login:Penguin
07/02/12 02:55:18 s17apHnG
昔のは本当に軽かったんだよ
最近のは Window Manager に何を使っても重い
長年 fvwm だったが beryl にしてエフェクト使いまくっても
その差が体感できなかった
590:login:Penguin
07/02/12 03:02:39 ehOYrnXS
>>584
実用に耐えなかったというのはあくまで自分の主観で、遅くても動いていたことは間違いない
これを使えると思うかどうかは、各自の主観によると思う
しかし、後でWindows95とデュアルブートにした際にWindows95の軽さに驚いた
実機で16MBでも快適動作するのを確認している
591:login:Penguin
07/02/12 10:54:39 m2mmtgAx
ここって何のスレ?
592:login:Penguin
07/02/12 11:10:27 dthoHvZf
Windows9x系はさすがに話にならんだろ。
しかしNT系になって実装もそうだけど、設計でもUNIXは抜いたと思う。
MSは実装だけでなくアーキテクチャ設計能力も高い。
特にサードパーティによる新デバイス対応やOS拡張ができるようにする
モジュール構造は実世界で揉まれてるだけあって先を行ってるし、
どのOSでも一番問題を起こすドライバ系の安定度を高めるための
検証フレームワーク整備や教育といった面でも抜かりない。FS面でもNTFSは
安定してること以上にマルチストリームとかトランザクション対応とか
新機軸を着実に導入してるし、ユーザランド側でもPowerShellとかWSHと
いった洗練された仕組みがここ１０年で着実に入ってる。
元ネタが○×でコピっただけとか厨が煩いことがあるけど、設計・実装は
NT登場以来驚異的に高くなってるし、そもそも他の会社が対抗できてない。
上から下まで、技術・非技術面までひっくるめて整備してくるMSのこの底力が
一番すごい。
正面からNTFSに対抗できる存在としてReiser4に超期待してたんだけど・・・
まあReiser4が駄目でもZFSとかFUSEとかGFSとか面白いものはたくさん
あるけど、MSは侮れんよ。
593:login:Penguin
07/02/12 13:19:52 pKQ9EzWP
Reiser4、漏れも期待していたけど、あの様子では主流にはなれないだろうな。
いろいろな意味で...
結局、Linuxカーネル開発者な連中は、Reiser4を闇に葬るんじゃないだろうか?
594:login:Penguin
07/02/12 13:56:34 1qjVTFhI
> ここって何のスレ?
top の出力眺める誰でも出来る仕事の人が、日頃妄想していることを書く場所。
595:login:Penguin
07/02/12 15:52:05 DZj/9zPx
>>593
確かにいい口実にはなったよな。
596:login:Penguin
07/02/12 16:33:24 ehOYrnXS
カーネル開発者たちはReiser4が独自IOルーチンを実装していることを非難してるが、
ReiserFS側が一方的に悪いとも思えないな
597:login:Penguin
07/02/12 16:36:32 V8V5NCDB
>Reiser4が独自IOルーチンを実装
XFSは良くてReiser4がダメな理由ってなんだろ？
598:login:Penguin
07/02/12 16:39:03 DZj/9zPx
>>597
開発者の性格
599:login:Penguin
07/02/12 16:39:15 ehOYrnXS
Hans Reiserが嫌われてるからだろ
600:login:Penguin
07/02/12 16:52:04 9DGMw6Vy
ユダヤの陰謀
601:login:Penguin
07/02/12 18:18:43 fU0muqJg
lustre1.6beta7を入れてみたのだが、OSTをmkfs.lustreしたあとmountするところで
カーネルパニックしてしまう。
beta7ちゃんと使えてる人いたら教えて下さい。
602:login:Penguin
07/02/13 04:46:11 IyOcykyK
しかし、Reiser4の開発者の性格がいくら悪くても、
漏れ的には、今まで一番トラブルの無かったファイルシステムが
ReiserFSなんだよな。
というぐらい今まで、LINUXのFSには酷い目にあっている。