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使ってるけど知らなかったよ。
人柱乙。つーか、バグレポだしても問題ないレベル？
411:login:Penguin
08/04/20 22:37:01 XcEPoN04
Reiser4で直っているそうだよ。
この話はWikipediaに載っている。
URLﾘﾝｸ(en.wikipedia.org)
412:login:Penguin
08/04/29 11:05:23 VXus0Bh+
Hans Reiser Guilty of First Degree Murder
URLﾘﾝｸ(blog.wired.com)
25年の懲役刑を言い渡されたとあるけど、
アメリカって控訴とかできるの？
もうこれで刑確定なの？
413:login:Penguin
08/04/29 11:31:54 6biaRDGN
> defense attorney William DuBois aptly painted a picture of Reiser as
> a misunderstood computer nerd, so inattentive to social cues, and so
> slavishly devoted to logic, that his innocent behavior could be easily
> misinterpreted as evidence of guilt.
陪審員尋問で自ら疑惑を強化してしまったようだが、こんな弁護されても
うれしいかどうか・・・
414:login:Penguin
08/04/30 18:21:02 wqc5ADBb
xfsについて質問です
大きなパーティションに細かいファイルを大量に書き込むような
使い方をしてるのですが、df または df -iで空き容量、空きinodeが
あるように見えるにもかかわらず ENOSPCで書き込み失敗と
なる現象が発生しています。
調べて見たところ、statvfs()で取得した空き容量と xfs用の ioctl
(XFS_IOC_FSCOUNTS)で取得した空き容量が異なっており、
ioctlで取得した値のほうが正しい(?)と思われる結果になりました。
# ioctl()で取得した情報によると inode不足が原因で書き込みに
# 失敗しているようです。
そこで質問なのですが、xfs_vfsops.cにある xfs_statvfs()と
xfs_fsops.cにある xfs_fs_counts()で空き容量、空きinode数の
算出方法が異なるのは何故でしょうか。
また、正しい空き容量の取得方法についてガイドライン的なものが
あればご教示ください。
# xfsは inodeを動的に確保する仕様だから inode数と空き容量を
# その都度細かく計算する、というロジックに見えるんですが、
# 結果として正しい値が取得できないとしたら本末転倒な気が...
# reiserfsみたいに df -iして inode 0を返すくらいに割り切って
# しまったほうがいいような気もするんですが
415:login:Penguin
08/04/30 18:25:22 VvZpuE3V
>>414
大量ってどれくらい？
昔10TBほどに4億ファイルくらい置いたことがあるけど、
問題なかったけどな。
ファイルシステムは壊れてないの？あとバージョンは？
416:login:Penguin
08/04/30 18:31:36 VvZpuE3V
すまん。４億じゃなくて１億くらい。
417:414
08/04/30 19:24:11 wqc5ADBb
>>415
容量は約16Tで残り 3Gくらいの状況です。
ファイル数はそんなに多くなくて 900万くらい。
バージョンは kernel-2.6.19.7で確認しました。
環境の都合上、異なる kernelでの確認が困難なため、ほかのkernelでは
試していません。
(kernel-2.6.24.4でもソース見る限りはおなじような…)
xfs_dbの sb表示でも ifreeが 0になっているのに df -iだと
数%しか使用していないことになってます。
また、ためしに loopデバイス上に極小の xfs(100MByte)を作って
ddで限界まで zero埋めしたファイルを作成し、あとはひたすら
touchで細かいファイルを作ったところ df -iで 80残っているのに
書き込みできなくなりました。 (ioctlだと freeinoが 0に見えます)
# この例だと単純に空き容量不足(20kしかない)の可能性もありますが...
# ちなみに kernel-2.6.24.4@amd64です
418:414
08/04/30 22:17:46 wqc5ADBb
>>415
すみません。
1億くらいのファイルを作った xfsパーティションの
フォーマットオプションを覚えていたら教えてください。
あと、1億でやめたのは inode数と空き容量の
どちらかがいっぱいなったからでしょうか。
それとも 1億以上は必要なかったからでしょうか。
(限界まで書き込んだ結果が 1億だったのでしょうか)
419:login:Penguin
08/05/01 11:06:10 LTFh7Iqg
>>417
そういう最小再現テストが作れているのなら
TO: linux-fsdevel@vger.kernel.org,
CC: linux-kernel@vger.kernel.org, David Chinner <dgc@sgi.com>
あたりでバグ報告してみたらどうだろうか。
仕様だとしても返事ぐらいはくれると思うので悪い結果にはならんと思うよ
420:login:Penguin
08/05/01 13:18:14 t9uJxuIJ
>>419
うーん、やっぱり聞いてみるしかないのかな。
英検3級に落ちるくらいの英語力しかないから
質問しにくくて... orz
あと追加でバグ(?)発見。
100Mくらいの xfsパーティションに 10万個くらいの空ファイル置くと
statvfs()が EOVERFLOWになります。
df -iの値がおかしいから inode数が吹っ飛んでるみたいです。
よわった...
421:414&420
08/05/01 13:27:14 t9uJxuIJ
しまった、420の書き方だと xfs使ってる人が不安になるな。
エラーになるのは 10万個の空ファイルを xfsパーティションの
直下に 「ディレクトリを作らず」に置いた場合です。
普通はこんな使い方しないだろうし、「inodeが吹っ飛ぶ」と
いう表現もファイルシステムが壊れるわけではなく
df -iで表示される inode数がおかしくなるだけです。
422:login:Penguin
08/05/01 18:45:02 LTFh7Iqg
>>420
シリコンバレーの８割はノンネイティブなので、やつらはヘタ英語耐性非常に高いよ
423:login:Penguin
08/05/01 21:57:27 Vkwz20tA
ReiserFSで有名な米国人プログラマー、殺人罪で有罪の評決
米カリフォルニア州地方裁判所は28日、妻のニーナの殺害容疑で起訴されていた
ハンス・レイザーに対して第一級殺人で有罪の評決を言い渡した。
URLﾘﾝｸ(www.technobahn.com)
424:login:Penguin
08/05/01 22:07:31 ohqQ3Vxz
ええーーーーー
これネタじゃないの？
425:login:Penguin
08/05/01 23:07:36 V1OLORy4
>>424
実はビックリ・・・だったらよかったのに。
426:login:Penguin
08/05/02 00:22:38 Cb2wHMs4
スラドに上がってるかと思ったが、上がってないな。
427:login:Penguin
08/05/02 00:31:12 YW5TTcLV
スレ違だけど、Reiserがほんとに殺人犯かは別として、
アメリカの裁判って全然正義じゃないと思う。
マイケルジャクソンの時がいい例。
428:login:Penguin
08/05/02 00:36:39 Cb2wHMs4
しかし、状況から見れば限りなく黒だよなぁ。
429:login:Penguin
08/05/02 00:40:00 dkUYFm2d
>>426
あがってるよ
URLﾘﾝｸ(slashdot.jp)
URLﾘﾝｸ(yro.slashdot.org)
430:login:Penguin
08/05/02 04:25:06 PQoOJPga
>>427
検挙すらまぬかれる日本よりマシｗ
431:login:Penguin
08/05/03 21:54:30 +ggzsGlh
delugeでスペースを確保する時フルアローケーションより
コンパクトアローションの方が読み込みが速いんだけど
reiserfsの場合断辺化は多い方が読み込みが速いもんなの？
432:login:Penguin
08/05/03 22:40:42 A1deGZTu
ベンチマークってどのソフトが有名なの?
新しいhdd買ってちょい古めのhdd空いたから色々fsテストしてみたいんだがさっぱり。
433:login:Penguin
08/05/03 22:43:37 fC71zTdk
Iozone
434:login:Penguin
08/05/03 22:56:40 A1deGZTu
ふむ、それでちょっとやってみるわ。
435:login:Penguin
08/05/09 14:48:12 9yigZLhc
>>423
ヴォースゲー
そういやファイルシステム屋ってイッちゃってる人多いよな・・・
436:login:Penguin
08/05/09 22:36:24 XBsQ5sGw
>435
他の例も教えてくれw
437:login:Penguin
08/05/10 00:23:32 avOohQIM
XFSでディスク追加しつつgrowfsで増やしてたらagcount=48とかになった。
さすがに大杉て性能低下してるっぽい。READが圧倒的に多い用途だから、
探索コスト重視でagcount=1とかが良さそうなんだけど、
xfs_fsr使えなくなるみたいだし……いくつぐらいがいい？
438:login:Penguin
08/05/10 00:27:54 IAFdsD6t
新しいxfsprogsだとagcountのデフォルトが半分くらいに減らされてて
数GB～100GBのファイルシステムで全部agcount=4になってる
439:login:Penguin
08/05/10 02:44:21 avOohQIM
うちのxfsprogsだとデフォルトagcount=16っぽい
xfs_fsrが動く範囲で小さめの値をいろいろ試してみます。ありがとー
440:login:Penguin
08/05/11 22:53:41 wi9PMfW6
ext4にしちゃったら、ext2fsdとかext2ifs使ってWindowsから読めなくなるんですか？
ていうか他のファイルシステムもWindowsから使えるようにしてほしいです。
441:login:Penguin
08/05/11 22:57:39 uhEE1HnM
>>440
colinux + samba使えばいいんじゃね?
442:login:Penguin
08/05/12 17:33:47 XUuf2cul
思うのだが、Linuxのファイルシステムの多くがWindowsから読めないのはLinuxのせいにされるが、
あるLinuxマシンにたまたまfat32とかntfsのドライバが入っていなくてもそれはLinuxのせいにされるよな。
（以前は「書き込めないのはLinuxのせい」みたいな感じだったし）
損な役回りだなww
443:login:Penguin
08/05/12 18:19:47 tGJxYdMx
・後発のソフトは常に損な役回り
・Windowsに固執すると永遠に幸せになれない
444:login:Penguin
08/05/12 19:08:17 e+U0PNje
>>442
LinuxのfsがWindowsから読めないのはWindowsのせいだろ。
ext3とreiserfsが読めるようになればWindows買ってもいいかなと思う。
445:login:Penguin
08/05/12 20:34:03 VZVqJBQc
>>444
Windowsにext3が実装されたら、LinuxのVFSが…
446:login:Penguin
08/05/12 21:16:18 jZeC6gUE
ext3は前述ので読める
reiserfsは読み取り専用のドライバだけあったような
447:login:Penguin
08/05/12 21:32:25 ZIjl6UnX
つ samba
448:login:Penguin
08/05/12 21:33:40 Vi3d3nrS
LinuxDrive for Windowsってソフトが補論から昔出てたな
使ったことないから分からんけど
449:login:Penguin
08/05/13 14:17:27 B3PAG86a
>>444
おまい、かっこいいなｌ。
450:login:Penguin
08/05/15 04:35:46 g09JXgWn
Parallel Optimized Host Message Exchange Layered File System
URLﾘﾝｸ(kerneltrap.org)
4. POHMELFS vs NFS benchmark.
URLﾘﾝｸ(tservice.net.ru)
URLﾘﾝｸ(tservice.net.ru)
URLﾘﾝｸ(tservice.net.ru)
451:login:Penguin
08/05/18 22:06:34 n0FAfdxt
ReiserFSって本当に終了しちゃうの？
452:login:Penguin
08/05/18 23:41:42 8tQ4zrTk
終了しちゃうとしても、逮捕されちゃったんじゃ、しゃーないでしょ。
ところで、終了するってソースは？
453:login:Penguin
08/05/18 23:53:42 Kon4k1Vh
３はすでに機能的には旧世代のものだし（メンテはされるだろうが）、
４は周知のとおり、マージすらされてないから放置。
454:login:Penguin
08/05/19 00:01:29 ZzkuNU9W
3は別に旧世代じゃないし、4は3以下。
455:login:Penguin
08/05/19 00:08:09 EilDrdA2
>>454
reiser4はかなり前から-mmにマージされているがバグ報告とか見たことないので、誰も使ってないんじゃないか。と疑っている
456:login:Penguin
08/05/19 03:34:44 q1NfHESk
>>451
16TB越えのパーティションサイズが普通に使われるようになったら終了だろうね。
近い未来だろうけれど、それまでは主力のファイルシステムとして幅を利かせ続ける。
あと5年くらいか。
457:login:Penguin
08/05/19 08:09:47 094JTCHh
え、今Linuxの主力FSって、何があげられるんですか？
458:login:Penguin
08/05/19 08:28:05 /Waga8Mz
主力と呼べそうなのはext3しかないだろ
間違ってもreiserfsじゃない
459:login:Penguin
08/05/19 16:47:30 QIATkluX
普通にext3だね
URLﾘﾝｸ(ja.wikipedia.org)
期待はされたんだけどなぁ＞reiserfs
460:login:Penguin
08/05/19 18:05:47 x2MlYmix
普通にreiserfsだろ。ext3はおそすぐる。
461:login:Penguin
08/05/19 19:12:33 kGzpiLaP
>>455
一人だけreiser4使ってる人しっている。
>>460
今更reiserfsもないと思う。
suseも手を引いちゃったし。
462:login:Penguin
08/05/19 19:41:18 48/pRU4B
URLﾘﾝｸ(blogs.sun.com)
で、ZFSが載ってくれば、皆忘れていくさ・・・
463:login:Penguin
08/05/19 19:46:39 H0npQQv0
はいはいZFS最強ZFS最強
464:login:Penguin
08/05/19 21:15:56 ZzkuNU9W
ZFSは期待してたが遅すぎ。早く目を覚ますべき。
reiserfsは悪くない選択肢。マウントが遅いのに目を瞑れば。
ext3は無難。先も明るい。
465:login:Penguin
08/05/19 21:29:49 KfYOlogJ
無言でJFSを使い続ける。
466:login:Penguin
08/05/19 21:36:16 dpCUD8Xx
問題はライセンスなんだよなあ。
fuse経由では使いものにならないし。
あと結構ZFSって要求スペック高くね？
このへんは時間が解決してくれるかな(期待
467:login:Penguin
08/05/19 21:36:38 civQAuJU
OracleがZFSもどき作ってたな。
OCFSともども全く注目されてないけどｗ
468:login:Penguin
08/05/19 21:38:48 q1NfHESk
結局現状では、高速・高利用効率で実績も充分にあるreiserfsが選ばれやすいんだよね。
大きなデメリットもないし。
特に理由がなければreiserfsを選ぶのが無難かつ最適なケースが多い。
469:login:Penguin
08/05/19 22:14:36 qS/NQTMT
みなさん、今一度lost+foundの中を確認してください。
Reiserの嫁さんが居るかもしれません。
470:login:Penguin
08/05/19 22:40:34 q1NfHESk
うちのreiserfsにはlost+foundが無いんだけど。
Hansが証拠隠滅したのかな？
471:login:Penguin
08/05/19 22:53:02 ZzkuNU9W
俺のもない。Hansが捕まる前はあったのに…。
472:login:Penguin
08/05/19 23:19:48 Nka1lmTo
dumpで埋められたのかも
473:login:Penguin
08/05/19 23:25:14 X2D+O09h
で、無言の多数派はXFSと。
実際にはext系で大抵の用途は充分だしなぁ
474:login:Penguin
08/05/19 23:26:49 v0zMl1ni
500とか1GBなどの動画ファイルの格納先としては、やっぱりXFSが最適ですか？
475:login:Penguin
08/05/19 23:43:54 EilDrdA2
最近動画専用ファイルシステムが投稿されてたね。そういえば
476:login:Penguin
08/05/20 01:02:16 aN/Be4xB
>>475
kwsk
477:login:Penguin
08/05/20 01:16:16 pV7pmg2U
Windowsと共有用途とか case insensitive な file system だとJFSの一択になるな
vfatに保存するほどマゾじゃないし、NTFSは case sensitiveだし
478:login:Penguin
08/05/20 01:34:16 zYwOwEvw
今度hddを足すことがあったら、xfsとjfsを試してみるんだ。
いろんなファイルシステムが混在してるぜ。
winを使っていたころには考えられなかった楽しみだな。
479:login:Penguin
08/05/20 01:47:25 5p0mfIHX
JFSってwindowsから使えるの？
480:login:Penguin
08/05/20 02:15:39 D0FaA2M8
>>477
XFSにcase insentiveサポートを追加するパッチが投稿されてたけど、i18nかじったことあるやつが議論に加わると「caseってなにさ？」から始まるので話がまとまらない。
困ったものだ。
ところで、NTFSすらcase sensitiveなのに、なんでcase insensitiveが必要になるんだい？
481:login:Penguin
08/05/20 02:58:02 4paPLLL+
ここ(>>450以降あたり)でいってるreiserfsって3のこと？
482:login:Penguin
08/05/20 03:12:45 hx5NkZpC
yes
483:login:Penguin
08/05/20 05:35:26 CGOJLBT4
insensitiveなんてSamba側でやらせるよ
484:480
08/05/20 05:46:52 D0FaA2M8
>>483
たぶんそれが正解。
世の中で求められているのはバグも含めてWindowsと完全互換な挙動であって「正しい」 case insensitive ではないと思う
485:login:Penguin
08/05/20 15:52:17 7zhBv2ee
少し前に知ったんだけど
WindowsのNT系だと
"A"と"a"を同一視するのは当然だけど
"Ａ"と"ａ"も同一視するんだぜ。
(9xだと"Ａ"と"ａ"は別扱い)
NTFSで区別出来るかは知らないけど、FATだと当然区別できて
"Ａ"と"ａ"が両方あるディレクトリをNT系で読むと片方しか操作できないらしい。
たぶんディレクトリエントリの並び順とかによるんだろうが。
試してないが、samba上に"Ａ.txt"と"ａ.txt"を置いても
操作できるのは片方なんじゃないかね。
486:login:Penguin
08/05/20 15:57:55 Y/B6ib8Y
キリル文字とかギリシア文字がどうなるのかも気になるなwww
487:login:Penguin
08/05/20 17:05:38 R7fVkyDq
>>485
そりゃNT系が、っていうより、explorer とかの特定のアプリが、ってことなんじゃ？
ファイルシステムの問題じゃないような。
488:login:Penguin
08/05/20 17:13:34 1uNl2xi7
Explorer て変なことするよな。ドットで始まったり終わるファイル作れないし。
まぁ拡張子非表示にしていると見えないとかいう理由なんだろうけど。
489:login:Penguin
08/05/20 17:46:12 Aur5JlSq
>>485
ユニコードだからじゃね？
490:login:Penguin
08/05/20 17:57:39 z2v1aIzv
>>468
ext系、xfsなどと比べれば実績は少ない方なんじゃまいか
491:login:Penguin
08/05/20 22:24:57 pV7pmg2U
>>287
実はそれが問題でね、ちょっと古い(といっても大半のアプリが使用してる)WINAPIから
だとcase 違いのファイルが扱えない。むしろ積極的に困った動作をしてくれる。
NTFSは case sensitive だから、そういうファイルは作れる。
だから本末転倒だが、file system のほうで case insensitive にするほうが、
Windows OSを安全に使用できるという訳。
492:login:Penguin
08/05/20 22:45:22 Aur5JlSq
>>488
.で終わるファイルはcmd.exeからでも作れない。
493:login:Penguin
08/05/20 23:15:06 eaiw47c3
>>490
linux上での実績
ext3 > reiserfs >>> xfs
速度
reiserfs > xfs >>> ext3
ディスクの利用効率
xfs > reiserfs > ext3
494:login:Penguin
08/05/20 23:29:35 7zhBv2ee
>>487
特定のアプリの問題じゃない。
普通のAPI、例えばMoveFileが失敗するし
CreateFileでopen出来るのも片方だけ。
何が問題なのかと言うと、両方のファイルがあるディレクトリでは
一覧を取ると両方が見えるのに、操作(例えばopen)しようとすると片方のみが対象となるので
意図しないファイルを触ってしまう可能性があるから。
495:login:Penguin
08/05/20 23:33:30 7zhBv2ee
あ、もちろん、ファイルシステムの問題じゃないよ。
OSの扱いの問題なだけ。
わざわざ持ち出したのは、上のほうで「Windows互換」という話が出たから。
496:login:Penguin
08/05/21 00:36:25 J4TqOFWl
>>493
linux上での実績
ext3 > reiserfs >>> xfs
↑これほんと？
xfsは最古のジャーナリングFSって言われるし、SGIのIRIXから使われ始めたでしょ
reiserfsなんて色々もめて結局マージされたのって2000年以降じゃん
497:login:Penguin
08/05/21 00:44:54 CQPnoXR/
>>496
そりゃファイルシステムとしての実績なら
xfs>>>ext3>reiserfs
だろうけど、「Linuxでの」実績だし。
個人的には ext3>reiserfs>=xfs 位だと思う。あの xfs が割とすんなり
マージされたのに reiserfs がマージされないのはなぜだとか思ってたけど。
498:login:Penguin
08/05/21 08:10:15 5JD2ckh4
>>496
ヒント: suse
499:login:Penguin
08/05/21 14:17:21 g1UfGfjU
SUSEはもうreiserfsを見捨てたよ
URLﾘﾝｸ(opentechpress.jp)
500:login:Penguin
08/05/21 14:26:56 Y7uwz6Fw
今さら何を？
501:login:Penguin
08/05/21 14:37:05 J4TqOFWl
＞reiserfs がマージされないのはなぜだとか思ってたけど。
ハンスの性格的問題も多分に・・・（ゴホッゴホッ
502:login:Penguin
08/05/21 14:44:44 Ci3au8LA
はアァァァんす
503:login:Penguin
08/05/21 20:06:01 gLL5ZX1c
>>492
copy nul \\?\%CD%\nullpo.
504:login:Penguin
08/05/21 20:06:22 YO2Ssk3x
>>499
実績の話をしてるんだから、今まで採用されていた実績が議論の対象で、
見捨てられたことは関係ないだろう。
505:login:Penguin
08/05/21 20:18:17 /Z1sqvHT
reiserfsの流れをぶった切って質問
今、Sambaメインのファイルサーバ建てるとして、FSは何がお勧めなの？
2Tくらいで50MB～2GBくらいまで、さまざまなファイルサイズを扱うとして。
506:login:Penguin
08/05/21 20:27:17 5JD2ckh4
reiserfs
507:login:Penguin
08/05/21 20:48:10 b+9jifIY
>>503
ガッ
508:login:Penguin
08/05/21 21:19:28 Ci3au8LA
>>503
残念。
それだと、作られるファイルは、nullpoであって、nullpo.ではない。
509:login:Penguin
08/05/21 21:48:42 pWHvlEE4
>>505
マヂレスするとWin 2003 serverつかってNTFS
510:login:Penguin
08/05/21 21:56:42 Aej85mCI
>>509
ここはLinux板だというに。
Linux以外でいいのなら、NetAppのDataONTAP上のWAFLを使うだろ。
511:login:Penguin
08/05/21 23:55:34 /Z1sqvHT
レスさんくす。
Linux板ではSamba使ったファイルサーバのFSのお勧めが無い事を理解した。
512:login:Penguin
08/05/22 00:08:55 nmRfdow3
というか、fs云々以前にCIFS/SMBの実装ではレファレンス実装のWinのほうがsambaよりも圧倒的にいいから。
CIFS/SMBが主用途ならLinuxを使う意味はない。
NetAppはNFSではいいけど、CIFS/SMBではどうなのか知らん。
513:login:Penguin
08/05/22 00:24:47 oyxtcAu/
>>512
いや、もうわかったから。
質問する時に構成とか物理的な事情とか全部込みで記載して納得しないと
質問の内容に沿った回答はしたくないって事かい。
よかれと思って言ってるんだろうけど、そういうのはありがた迷惑だよ。
514:login:Penguin
08/05/22 00:26:01 RHUMboQ3
>>511
つか、2TBくらいの小規模ストレージならext3で普通にいいからお勧め。
一番利用者が多く一番テストされているので一番安定している。
515:login:Penguin
08/05/22 00:50:35 nmRfdow3
>>513
お前が非常識かつ恥垢臭の漂う生ける悪臭公害なのは理解できた。
頭のほうは手のつけようがないけど、包茎は治る障害だぞ。さっさと手術しろ。
516:login:Penguin
08/05/22 01:05:26 ygnClFlx
レス番号間違えてるんじゃね？文脈からして。
517:login:Penguin
08/05/22 01:09:53 BcXpovCg
>>513
勝手に納得してるとかホント笑える。
お前のママじゃないんだからちゃんと説明しないと分かんないって。
>>512は真摯に答えてるじゃん
518:login:Penguin
08/05/22 01:13:47 LED49E/n
程度の低い煽りは書けば書くほど恥さらしなんだが・・・
519:login:Penguin
08/05/22 01:13:51 oyxtcAu/
>>514
さんくす
ext3の例が一番多くみつかるね。
520:login:Penguin
08/05/22 01:15:37 +J7mssJ7
ファイルシステム詳しくないけど、ext3かreiserかxfsのうちから
好みで選べば良いと思うよ。
個人的にはjfsの感想が聞いてみたいけど。
なんで誰もjfsを使わないのかが気になったり…。
521:login:Penguin
08/05/22 01:27:07 xpIrNoHG
俺はシングルコアだから使わない。ただマルチコアの人がなぜ使わないのか疑問。
522:login:Penguin
08/05/22 01:40:40 OYg2rg/p
>>519
お前、本当になにも知らない馬鹿だったんだな…
523:login:Penguin
08/05/22 01:47:23 OYg2rg/p
>>520-521
とりあえず、このスレのログを読め。
>>522
蛇足的自己レスすると、ほとんどのディストリビューションでデフォルトfsの
ext3が一番多いのは当たり前
だいたい、上に乗っかるのがsambaだろうがなんだろうが、下のfs層にとっては
あまり関係なく、ファイルサイズ等についてはなにも触れていないし。
まあ、こういう頭の悪いヤシもときどき湧いてくるスレだけどさ…
524:login:Penguin
08/05/22 02:11:20 nmRfdow3
>>523
どうせ件の悪臭公害男は>>519以降はこのスレ読みもしないでしょ。
ってことで、悪臭公害男がいかに馬鹿なのかなんて説明せんでもわかることだし、
放置しとけ。ヲレが一度煽るだけで十分だ罠。
525:login:Penguin
08/05/22 02:26:58 LED49E/n
.>523-525
あのさー、教えてもらった事について>>513はまずいレスだと思うよ。
でも君らの対応はそれを遥かに下回って恥さらしだろ。
元質問の>>505は
・(Linuxで)sambaサーバー
・2Tのストレージ
・扱うファイルサイズは50MB～2GB
って出してるのに、それを無視して話進めるのはどうかな。
>>519
見てる事を期待して。ext3使っとけ。安定してる、情報が多いという利点がある。
526:login:Penguin
08/05/22 02:45:29 nmRfdow3
>>525
でも、>>513以前に>>511のような煽りをしている時点でキチガイ確定でそ、こいつ。
いい加減放置しようよ…
527:login:Penguin
08/05/22 04:05:56 FEtNCgqq
>>505
ファイルサイズ的にH264(SD/HD)あたりの動画ライブラリとか？
基本はext3一択でいいと思うけど、余裕があれば
巨大ファイルを連続して配置しやすい(→READ時のファイル内シークに影響)のと、
オンラインデフラグ(xfs_fsr)がほぼ標準で使えるXFSを検討してみるのも乙かと。
528:login:Penguin
08/05/22 07:15:31 oyxtcAu/
>>513はいいすぎだった。悪かった。
他の皆さんもスレの雰囲気悪くして申し訳ない。
これで消える事とします。
>>520>>525>>527
レスども。参考になります。ext3、xfsを試験的に使ってみます。
529:login:Penguin
08/05/22 09:27:44 itWQcnkn
よく分からんならとりあえずext3ってのが普通の考え方では
530:login:Penguin
08/05/22 15:16:32 gmG2tmnb
大きなファイルが主体ではなくて、作成/削除が多い使い方で、2Tぐらいならreiserfsだな。
sambaの設定の方が面倒くさい。
531:login:Penguin
08/05/22 17:50:22 CrQ6/Ptu
レイザーはでかいファイル消すのがなんか遅いから/home はxfsにしてるな。
/ はレイザー。
532:login:Penguin
08/05/22 19:13:37 2reFG8Md
巨大なファイルの扱いはなんといってもxfsだよな。
ところで/でreiserするときnotailつけてっか？つけててもきちんと動くことは動いたりするんだが・・・。
533:login:Penguin
08/05/22 20:54:15 35SUYurt
>>520
俺と一緒にJFS使おうぜ。
別に問題出てないし。PowerPC Ubuntuでも問題無しだぜ。
多分世界的に運用例少ないだろうけど。
534:login:Penguin
08/05/23 18:10:09 JvrXzXX6
>>533
以前も書いたけど、漏れはクラスタの共有ディスクに使ってたよ
中身はapacheのコンテンツやCGIやログ、postgresのDBなんかだった
以前、RH+apacheでコンテンツやログをext3においてたら、不安定
になって再起動した時にジャーナルがおかしくなったらしくて
ログの一部が別のファイルのケツに追加されていて絶望した！
ので、DirtyPageが少ないと解説されてたJFSに乗り換えた
かなり古いRHの話なんで、今のext3はダイジョブかもしれない
JFSには特に問題は起こってなかったよ、オレが辞めるまでは
535:login:Penguin
08/05/25 10:22:19 I72gntmD
で，Reiser はどうなっちゃったの？
ZFSは面白そうだなぁ。
でもチキンな俺は ext3 子か使わない。
536:login:Penguin
08/05/25 10:30:38 nRuClOB5
Reiserは檻の中
537:login:Penguin
08/05/25 11:02:31 I72gntmD
ん～結局殺人を犯していたってことなの？
事実が分んないなぁ．死体もないんでしょ？
538:login:Penguin
08/05/25 11:59:37 hIhEerJj
>>508
お前試してすらいねえだろ
539:login:Penguin
08/05/25 12:10:58 aGIQLT5K
>>537
でも、車の車内を水洗いして床に何センチも
水が溜まるとか普通はやらないよな
540:login:Penguin
08/05/25 12:37:17 +SiTZLz+
>>539
個人でファイル実用的なファイルシステムを開発して何万人にも
支持されるとか普通はやらないよな
541:login:Penguin
08/05/25 12:38:56 nRuClOB5
>>538
D:\home\test>dir /b
D:\home\test>copy nul > nullpo.
D:\home\test>dir /b
nullpo
D:\home\test>del nullpo
D:\home\test>dir /b
D:\home\test>copy nul > nullpo.
D:\home\test>dir /b
nullpo
D:\home\test>del nullpo.
D:\home\test>dir /b
D:\home\test>
これはどう見たらいいんだろ？
よくわからんけど、ファイルシステムかcmd.exeのどちらかが.を完全無視しているのは間違いないけど。
ちなみにファイル名をクォートしても結果は同じ。
542:login:Penguin
08/05/25 13:01:21 7C7oBPlF
試してねーじゃん。
ちゃんと試せよ無能。
ちなみにWindowsのAPIではUnicodeを扱ういわゆるW系において
パスの接頭辞に"\\?\"をつけることにより、
長いファイル名やunicodeファイル名を扱えるようになるんだけどね。
543:login:Penguin
08/05/25 13:06:31 MEYM67Vm
>>539
助手席を外して捨てた場所がわからないとかね
544:login:Penguin
08/05/25 14:51:39 bpSDnQ5H
殺人云々は置くとしてもreiserfsのVFSスルーっぷりが気になってやめた俺。
inode数報告しないとかね。
小ファイルの扱いなら神懸かったパフォーマンスをだすとか、良いところもあるけど
システムコンポーネントとしてはじゃじゃ馬に過ぎるというか。
545:login:Penguin
08/05/25 15:44:42 MEYM67Vm
誰が死んでも保守されることが確実なファイルシステムじゃないと
採用しにくいというのはあるな。
546:login:Penguin
08/05/25 16:41:49 00LY3qjW
Linux自体、Linusが死んだら世界大戦が勃発すると思うが
547:login:Penguin
08/05/25 17:11:38 XT6lz3z+
EXT4が安定するまでReiserFSだな
>>546
もっと(ry
548:login:Penguin
08/05/25 17:13:18 Gr8ncedA
りぃなすの後継者争いですか
549:login:Penguin
08/05/25 17:17:29 yrVgmu6i
たぶんFreeLinuxとOpenLinuxとNetLinuxに分裂すると思うよ
550:login:Penguin
08/05/25 17:23:19 3hC3VUUC
さらに
FreeDebianGnuLinux
OpenDebianGnuLinux
NetDebianGnuLinux
みたいに分裂するんだな
551:login:Penguin
08/05/25 17:54:13 00LY3qjW
三菱東京UFJ銀行みたいな名前だな
552:login:Penguin
08/05/25 18:14:40 kQ9Tlu2R
>>541
>>503
553:login:Penguin
08/05/25 18:19:19 XT6lz3z+
なぜDebianの名前が？
554:login:Penguin
08/05/25 23:49:01 MEYM67Vm
Linus v2 はすでにいるから大政奉還されて帝国の支配権は元に戻るオカン。
唯一RMSだけがforkして、GnuLinuxとLinuxの鼎立になる。
555:login:Penguin
08/05/26 07:56:54 zyBwtGrw
鼎立って三つないと立たないぜ
556:login:Penguin
08/05/26 08:07:19 tzMZRD7H
>>555
BSDのこともたまには思い出してあげてください。。
557:login:Penguin
08/06/07 07:23:29 1oYzBkua
ext4 へのマイグレーション
URLﾘﾝｸ(www.ibm.com)
558:login:Penguin
08/06/07 09:20:45 TxcsdFj5
結局、Softupdate と ジャーナリングはこれからもけんかし続けるの？
まぁ単なるユーザとしては壊れにくければそれでいいんだけど、
BSD マンセーの人がまわりに多いせいか Softupdate 最強、
ジャーナリング死ね、っていわれて Linux で ext3 ふだんづかいの
俺としては肩身が狭い。
559:login:Penguin
08/06/07 10:07:45 TbmHmjKk
LFS最強
560:login:Penguin
08/06/07 16:31:12 qH747CFp
softupdates って言ってる人も
安定したら ZFS に移行してくんじゃね?
561:login:Penguin
08/06/07 16:32:32 Hh1Fjp89
ZFSってメモリ喰うって聞いたんだけど・・・
562:login:Penguin
08/06/07 17:40:51 PzCBrHzD
>>557
extentsデフォになったのか
563:login:Penguin
08/06/08 11:18:17 mzjClCG0
>>561
その頃にはメモリ4GBが当たり前の時代に…
564:login:Penguin
08/06/08 11:52:38 1VgdzU6v
その4GBという数字はどこから？
565:login:Penguin
08/06/08 15:32:51 7Pl7kbXw
俺のマシンが4Gだからだな
566:login:Penguin
08/06/08 16:10:28 rMnT/LRY
32bit = 4GB だから．
って，いつの時代のプロセッサの話だよ orz
567:login:Penguin
08/06/08 16:19:30 wCe3B6xl
zfsは128bitだから、もっとたくさんのメモリを浪費しないと(何かが間違っている
568:login:Penguin
08/06/08 22:10:22 dcR6yqL8
>>558
人間関係から見直すことをお勧めする
569:login:Penguin
08/06/09 00:16:11 fjm8roW2
>>566
いまでも普通の Linux の多くは 32bit modeだろ。
4GBまでしか使えないぞ。
570:login:Penguin
08/06/09 00:31:56 LZZAH+e9
>>569
Windowsの話題はWindows板でよろしく
571:login:Penguin
08/06/09 00:43:44 tan2UJ3U
早くbtrfsが完成するかLVMやRAIDでもバリアが効くようになってくれないと
NCQとか怖くて使えねー
ていうかHDD側でflashでも積んで担保してくれよ
572:login:Penguin
08/06/09 00:44:07 dVITE62h
今時32bitなんてつかってんのか
573:login:Penguin
08/06/09 00:50:11 fjm8roW2
>>570
ごめん。俺普段ARMが主なので頭のなかが32bit時代で止まってた。
574:login:Penguin
08/06/09 00:53:23 iCnNmYcc
なんだ老害か
575:login:Penguin
08/06/09 01:45:09 HtDaA/1r
>>569
HIGHMEMを忘れないであげてください（；＿；）
576:login:Penguin
08/06/09 01:46:08 HtDaA/1r
>>571
いまってLVMだとバリア効いてないの？
なんかすごい致命的な気がするが
577:login:Penguin
08/06/09 02:22:09 tan2UJ3U
>>576
xfsマウントしてみればわかるよ
CQによる処理順番入れ替えが無ければ致命的にはならんでしょ
578:login:Penguin
08/06/09 06:05:54 Z1zzLOzE
Hans Reiser Offers To Lead Cops to Nina's Body
URLﾘﾝｸ(blog.wired.com)
579:login:Penguin
08/06/09 08:36:40 9VatEwGW
ん～ってことは本当にやってたのか？
580:login:Penguin
08/06/09 10:19:59 W1M4AtOH
linusの後継者ってあったけどどんな人？
581:login:Penguin
08/06/09 12:02:23 Hf6KgNmc
第1級殺人から第2級にしてもらう司法取引みたいだね。
第2級殺人になると刑期は最短15年で、その間に仮釈放がつき可能性も出てくると。
3年後にはメインストリームカーネルに組み込まれるReiser4とHansの姿が！
582:login:Penguin
08/06/09 15:16:48 p1b0HTc3
>>580
Linus v2.0
583:login:Penguin
08/06/09 22:42:28 Gf9zF/IJ
>>575
え、DEVICEHIGH=がどうしたって？
584:login:Penguin
08/06/09 22:44:29 tan2UJ3U
ちょっと待って今ウィングコマンダーインスコしてる所だから
585:login:Penguin
08/06/10 09:37:50 /q3V4mNG
懐かしいな。
そういやオリジンってどうなったんだろう？
弁当屋の方じゃないよ。
586:login:Penguin
08/06/10 12:41:06 wkVvFOgm
/varをext4にした状態で/var/runの中のソケットが閉じられないままrebootされると
次のfsckでextent flagが立ってるけどextentになってないぞみたいなエラーが
報告されるんだけど、どっかにパッチない？
587:586
08/06/10 22:15:42 wkVvFOgm
無いみたいですね。ウチだけかもしれないしこれ以上追う能力もないんでおしまい。
588:login:Penguin
08/06/11 15:58:02 D/uJqSrQ
The future is bright for Linux filesystems
URLﾘﾝｸ(lxer.com)
589:login:Penguin
08/06/11 22:00:37 KBH6CbFa
>585
SGI?w
URLﾘﾝｸ(www.sgi.co.jp)
590:login:Penguin
08/06/11 22:08:30 svM4gOVz
>>585
URLﾘﾝｸ(www.8stars.net)
591:login:Penguin
08/06/12 18:15:57 +3KxROOU
>>569
PAE有効にすれば32bitのx86でも64GBまでのメモリ扱えなかった?
592:login:Penguin
08/06/12 23:10:41 Un39g4k0
>>591
見えるようにはなるが…
扱えるいうには微妙な気がする。
593:login:Penguin
08/06/12 23:45:04 JMue5W9m
URLﾘﾝｸ(www.atmarkit.co.jp)
594:login:Penguin
08/06/13 00:38:54 7sXLnT7D
>>592
Windows(32bit)でもLinuxと同程度に使えるが、Server以上が必要だと思った
Professional以下だと精々RAMディスクにするくらい
595:login:Penguin
08/06/13 05:38:03 d5G5+rVP
話の流れを読まずに質問すみません。
今、ext4の「delayed allocation」について調べていたのですが、
これはHFS+の「遅延再配置」とは機能的に別もの、という認識で
正しいでしょうか。
というか、HFSの「遅延再配置」を「delayed allocation」と混同してると
思われし記事があったのですが、これって間違っていませんか？それとも
私の認識が間違っているのでしょうか。
ext4の「delayed allocation」の場合：
実際にデータをディスクに書き込む（writeback）直前まで、ディスク上の予約を遅延させる。
参考にしたのはこのURLです。URLﾘﾝｸ(ext4.wiki.kernel.org)
HFS+の「遅延再配置」の場合：
小さくて（20MB以下）、且つ激しくフラグメントしているファイルが存在する場合、
バックグラウンドでこっそり配置を換えることでデフラグする。
気になった記事はこれです。URLﾘﾝｸ(journal.mycom.co.jp)
遅延再配置は「hfs_relocate」のことで、HFS+は、これとは別に、delayed allocationを
してるんじゃないかと思うんですが。。。
596:login:Penguin
08/06/13 09:40:13 SmSLF865
情報元を確かめるべき
Mac OS X Internals: A Systems ApproachChapter 12 "The HFS Plus File System"
にははっきりとdelayed allocationとOn-the-fly Defragmentationとして別物とされてる
ついでに海上忍は仮想PCソフトのVirtualBoxが64bitゲストOSサポートと書いて未だに修正していないような奴だ
597:login:Penguin
08/06/13 12:07:16 d5G5+rVP
595です。
>596 さん
ありがとうございます。すっきりしました。
598:login:Penguin
08/06/13 12:19:26 mKVHjRTc
HFS+てそうなんだ…と思ってAppleの文書読んでみたけど、delayed allocというより
デフォでmmapにしましたー副作用はプログラム側で回避してくださいーみたいに見えた。
599:login:Penguin
08/06/14 00:39:18 nD9Jg0U1
>>537
お前試してすらいねえだろ
600:login:Penguin
08/06/18 13:27:20 ZwFEd7Po
ハードディスクがマウントされた回数を調べる方法を教えて！
601:login:Penguin
08/06/18 13:58:49 UC096jsW
tune2fs でそれらしいものは見れる気がする
602:login:Penguin
08/06/18 13:59:09 UC096jsW
しかし ext2/3 限定
603:login:Penguin
08/06/19 09:32:59 e4d86G//
>601
そんなものを記録しようという発想自体が斬新だった…
604:login:Penguin
08/06/19 10:33:19 cK/HYswF
テープだと普通。
605:login:Penguin
08/06/19 10:38:45 PBUCIgoJ
>>604
ああ、そうなんだっけ？
すでに mt なんてコマンドを忘れている俺。
606:login:Penguin
08/06/19 13:08:09 EIQbArXH
見積りにテープドライブ入れてると怒り出す客とかそんなんばっか
607:login:Penguin
08/06/19 13:18:27 qCoUXFkj
reiser4やりたいっていう人が出てきたぞ。
608:login:Penguin
08/06/19 13:27:31 aI6v805X
Resier4 Maintainer
URLﾘﾝｸ(marc.info)
これか
609:login:Penguin
08/06/19 14:01:01 06Y2v8AU
今、reiser4を引き継いで完成させればヒーローだな。
間違いなく、名が上がる。
610:login:Penguin
08/06/19 14:02:28 WPg1jSrK
もしくはreiser4にとどめをさした男として有名になれるかもしれないな．
611:login:Penguin
08/06/19 14:14:00 PBUCIgoJ
Reiser4って今の状況でどういう役割が期待されているの？
やっぱり ext3 なんかはたくさんのファイルを持つ
ディレクトリや深いディレクトリの探索はずっと苦手なままなの？
612:login:Penguin
08/06/19 14:14:47 e4d86G//
この際、バージョンも一つあげて5にしよう
reiser ってのもケチがついちゃってるから
別の名前にしますか。音がにてるからレーザーがいいかな?
ん? レーザーファイブ???
613:login:Penguin
08/06/19 15:28:41 pJJwK1qL
／￣￣＼
／ _ノ ＼ おっとそれ以上言っちゃダメだろ常識的に考えて
| （ ●）（●）
. | （__人__）＿＿＿_
| ｀ ⌒／ ─' 'ー＼
. | ／（ ○） （○）＼ ＜ reiser ってのもケチがついちゃ・・・
. ヽ ／ ⌒（n_人__）⌒ ＼
ヽ |、 （ ヨ |
/ `ー─－ 厂 ／
| ､ ＿ __,,／, ＼ ﾄﾞｽｯ...
| / ￣ i;;三三ラ´ |
| | | ・i;j： | |
614:login:Penguin
08/06/19 16:42:26 lGN9kxVi
Linuxの切り札としての意味を込めて、キラーファイルシステム
615:login:Penguin
08/06/19 18:35:19 06Y2v8AU
仮に本人の素行に問題があったとしても、偉業の偉大さは変わりない。
616:login:Penguin
08/06/19 21:11:33 cLRTipHS
>>608
ReiserじゃなくResierと言ってるのが気になる。
617:login:Penguin
08/06/19 22:20:45 wctiiru/
きっと名前もJasonFSになるな。
618:login:Penguin
08/06/19 22:26:23 cLRTipHS
妻殺しから皆殺しFSになりそう。
619:login:Penguin
08/06/20 01:01:25 WiM2+vka
KatoFS
30秒で瞬殺
620:login:Penguin
08/06/20 01:23:41 XuPRUqoi
エターナルフォースFS
ファイルは死ぬ
621:login:Penguin
08/06/20 20:40:15 lAILMKAr
カカクコムFS
622:login:Penguin
08/06/20 22:46:38 ZSShiYyM
やっぱり
NintendoFS
じゃね？
リソースフォークとデータフォークの
上下二つに分かれて(ry
623:login:Penguin
08/06/21 17:25:12 c8w9wDFZ
>>615
さすがに殺人までいくとアウトだろｗ
624:login:Penguin
08/06/21 17:45:56 dMw3ye29
聖人だろうと悪人だろうと差別しないのがオープンソースの精神だろｗ
625:login:Penguin
08/06/21 17:53:30 iqg+xYP9
犯罪者は別では。
ところで司法取引で遺体の場所を教えるかわりに減刑という話はどうなったんだろうか？
626:login:Penguin
08/06/21 18:06:24 0NLIq0g7
罪を憎んで人を憎まず
627:login:Penguin
08/06/21 18:39:44 4BxdZr7B
> 聖人だろうと悪人だろうと差別しないのがオープンソースの精神
初耳だわ
628:login:Penguin
08/06/21 18:58:39 dMw3ye29
うわぁ・・・
629:login:Penguin
08/06/21 20:54:59 ZUW9O2rb
まあ実際、nihonLinuxのGGPL騒動の時に、GPLのエヴァンジェリスト達は
鼻で笑ってたんだから、「正義と平和と環境問題」に背いているやつが
GPLのコードを書いても使っても、何の問題もないだろうｗ
630:login:Penguin
08/06/21 21:45:58 IubOjAtw
逆に「悪人は使っちゃダメ」みたいな条項を入れると
オープンソース認定がもらえない可能性がある
631:login:Penguin
08/06/21 23:05:01 5RuGuuxc
>>626-628
正しくは
ライセンスはある特定の分野でプログラムを使うことを制限してはなりません。
罪を憎んで人を憎まず、の反対だわな。
開発者に関することは何も触れてない
632:login:Penguin
08/06/22 00:00:59 TfGtUGnu
人を憎んでプログラムを憎まず。か。
633:login:Penguin
08/06/22 01:57:09 +fD2tnRS
殺意の波動に目覚めたLinux
634:login:Penguin
08/06/22 07:14:44 8GzXAXYz
人も憎めなくね(>>630)
635:login:Penguin
08/06/22 12:11:05 WFMLwJso
てかネタにマジレスすんのが流行りなのか？
636:login:Penguin
08/06/22 13:58:01 ARS4sLLG
他にネタが無くて暇・・・
fuse系も話に入れるか？
sshfsとか。
637:login:Penguin
08/06/22 14:17:59 6lmwYVMg
ネタも無いことだし、GmailFSみたいに2chに書き込みする2chfsでも作るか？
とか一瞬思ったが、あっという間にスレストされるだろうな。
638:login:Penguin
08/06/22 14:33:57 gHjccGW3
530 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2008/06/22(日) 13:55:43
URLﾘﾝｸ(apollo.backplane.com)
(Mattは「than」を「then」と書く癖があるので注意)
639:login:Penguin
08/06/22 14:48:04 YUcJKWz9
このパーティションのinodeは１０００を超えました。
もう書けないので、新しいパーティションを切ってくださいです。。。
640:login:Penguin
08/06/23 11:53:44 MNZnxf0C
なんというFAT12
641:login:Penguin
08/06/23 12:13:57 U8kY+Ez0
そういやスマートメディアってFAT12だったよな
642:login:Penguin
08/06/23 23:33:03 mZHbBLiO
このパーティションのレス量は500KBを超えました。
もう書けないので、新しいパーティションを切ってくださいです。。。
643:login:Penguin
08/06/24 00:58:49 cm1R/Sjl
罪を憎んで人を肉まん
644:login:Penguin
08/06/24 03:34:32 VW10j/WH
>>643
で、おいくら？
645:login:Penguin
08/06/24 12:06:12 Es1k3smv
29万。
646:login:Penguin
08/06/25 01:52:16 gfg0fk30
AdvFSってパフォーマンスはどうなん？
647:login:Penguin
08/06/25 02:46:38 gHKJW76m
HP-UXじゃなくてTru64とはこれまたマイナーな・・・
648:login:Penguin
08/06/25 04:09:44 528Rqoag
HP-UXのルートファイルシステムは、vxfsだからｗ
649:login:Penguin
08/06/25 05:06:41 4+yi9CIL
Tru64ってDECのOSF/1 -> Digital UNIXの系統でそ。まだ残っていたのかって感じだ。
>>646
パフォーマンス云々よりクラスタ対応FSというのが大きいかと。
650:login:Penguin
08/06/25 05:12:12 IWfMljif
>>649
AlphaマシンのOSがなくなっちまいますがな。
あ、OpenVMSがあるか。
651:潰されますた
08/06/25 09:51:42 GePkmjrG
×まだ残ってた
○もう残ってない… orz
652:login:Penguin
08/06/25 12:26:10 ImPXo0n4
>>646
これ貼っとけよ。
HP、Tru64 UNIXファイルシステムをオープンソース提供:ニュース - CNET Japan
URLﾘﾝｸ(japan.cnet.com)
653:login:Penguin
08/06/25 13:25:01 QXZIKQLf
Q. クラスタ対応fsってなにそれ?
A. iSCSIとかSANとか昔懐かしい二本足SCSIとかのSCSIレベルで共有可能な
ディスクに対し、複数台のPCが同時にmountできるありがたいfs
654:login:Penguin
08/06/25 22:12:06 eB6jIEmD
663 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2008/06/25(水) 09:50:02
dragonfly スレから転載
HAMMER file system の(本人)解説
URLﾘﾝｸ(apollo.backplane.com)
655:login:Penguin
08/06/25 22:30:07 1Szt9sc2
>>649
vanilla kernel に AdvFSが入ったとしても、Red Hat はGFSを持ってるから
サポート対象にはしないだろうし、ドライバも有効にしないだろ。
そうなるとHPがサポートするとしても、Red Hatの度重なるKernelのアップデート
に対して遅れをとれば、やっぱり使いにくいなということになって使われない。
まあ、そんな可哀想なFSになるのかな。
656:login:Penguin
08/07/07 20:18:56 6QaAszOU
ext4のdelayed allocationがとうとうLinusツリー送り
657:login:Penguin
08/07/07 20:22:58 xlUuXT+m
>Yes, this is much better.
これは ACK ということなのか？
最大の難関をパスしたところか。
658:login:Penguin
08/07/07 20:26:22 VMZVnsPK
ext4は早いとこ性能回復して欲しい…
新進気鋭のファイルシステムなのに、
気付いたらext3より性能下でしたってのは悲しすぎる
659:login:Penguin
08/07/08 03:04:14 N7zO8gfy
結局次世代のローカルファイルシステムはXFS,ZFS,ext4の争いになったか。
初代のXFSが王座を守るか、次世代のZFSが勝つか、伏兵のext4が横から
割り込めるかってとこか。
もっとも徐々に戦場はネットワークファイルシステムに移りつつあるような。
660:login:Penguin
08/07/08 06:38:26 A/iZhekx
また適当な事を。ZFSは遅すぎてダメ。ext4は順当。
伏兵はNTFSだな。
661:login:Penguin
08/07/08 06:42:06 po4gnuyX
ext4が伏兵？普通に本命だろ
662:login:Penguin
08/07/08 07:28:06 3bW0RrM3
XFSって王座なのか？
㌧だあと何も復旧できなかった経験があって怖い。
663:login:Penguin
08/07/08 07:32:48 sWD9sadT
クラスタファイルシステムはどれが勝つんだろうね？
LinuxだとやはりGFSか？
664:login:Penguin
08/07/08 07:59:34 zx/DWHE+
>>663
そもそもクラスタファイルシステム自体が普及するまでの道のりが遠いような。
特定のメーカーによらない独立したクラスタが当たり前、
っていう世界になるところからではないかと。
665:login:Penguin
08/07/08 10:58:22 udozm2p+
>>656
期待して見たけどいきなりStrong NACKだって
666:login:Penguin
08/07/08 14:22:28 IwKOZTVN
>>659
JFSのことも忘れないで下さい！(＞＜)
667:login:Penguin
08/07/08 14:32:27 ngbBJgyi
いまだに無難を選択となるとext3になるのはなんとかしてほしい。
668:login:Penguin
08/07/08 15:08:20 7o9fFsoN
最近、仕事中にふと手を止めてこう思うんだ。
「Reiserが無実だったらなぁ・・・」
669:login:Penguin
08/07/08 16:21:31 II4/+Uhu
今と何も変わらないと思うよ
670:login:Penguin
08/07/08 16:43:33 quavIXzi
URLﾘﾝｸ(www.technobahn.com)
> レイザー被告は、被疑事実を全面的に認めると同時に、見つかっていなかった妻の遺体の
> 隠し場所を捜査当局に教えることを条件に15年の懲役刑による実刑判決となる見通し
15年か……
漏れがぷらっとホームでJE2のCDROM買ってSlackware2.0入れたのが14年前だ。
長いなあ。
でも待っているよHans。
671:login:Penguin
08/07/08 18:30:55 WHMGc1ii
>>670
獄中で、reiser4のコーディングに専念するという選択肢は？
672:login:Penguin
08/07/08 19:30:28 II4/+Uhu
実はコードを紡いでいたのは殺された奥さん
この秘密の暴露を防ごうとしたのが殺害動機
673:login:Penguin
08/07/08 19:47:47 A/iZhekx
もしかしてコナンが子供にされたのも実は…
674:login:Penguin
08/07/08 23:09:51 N7zO8gfy
>>671
罰としてFAT16のジャーナリングFS化をさせるというのはどうだ。
675:login:Penguin
08/07/09 08:54:27 hal0SMTw
exFAT
676:login:Penguin
08/07/12 17:59:36 oJj3Jryk
誰かbtrfs使ってる香具師いる？
物になりそう？
677:login:Penguin
08/07/13 08:35:52 AL6mPOsw
俺も聞きたいw
678:login:Penguin
08/07/14 17:58:03 4vfD/at0
試さずに言うと本家にマージされた後4ヶ月程熟成されるまでは問題外だろう。
679:login:Penguin
08/07/14 18:42:43 ULtFNEHl
熟成っていったって、だれも使わなきゃ意味ないよねｗ
680:login:Penguin
08/07/14 23:20:49 9fV5ZnZS
と言ってもファイルシステムは何かあったときの被害がでかいからねえ。
再起動して何事もなかったかのように復帰してくれるなら試そうかという気になるが。
681:login:Penguin
08/07/15 21:02:20 2Td4kfvX
再起動して何事もなかったかのように
ＨＤＤ購入時点まで復帰してくれます
682:login:Penguin
08/07/15 23:55:48 zxFIxOek
>>681
セキュリティは完璧だなwww
683:login:Penguin
08/07/16 01:02:57 vwN5urnw
真のタイムマシン・コンピュータ登場
684:login:Penguin
08/07/17 10:43:01 cZuSJMBj
URLﾘﾝｸ(en.wikipedia.org)
> Oakland homicide detective Lt. Ersie Joyner recalled that Reiser led them directly to the exact site,
> without any hesitation or confusion.
さすがReiser。fsckは速くて正確！
> Reiser said he hoped a cherry tree would be planted to mark the grave site.
桜の木の下に死体、ってのは梶井基次郎が元ネタだと思っていたのだけど
アメリカでも一般的なのかなあ？
685:login:Penguin
08/07/20 05:44:11 1/y/LlXW
やってたのか…reiser
686:login:Penguin
08/07/20 12:31:33 GKdtyC24
殺人にの際にGPLなものを使用してたからだろｗ
687:login:Penguin
08/07/22 13:09:51 oK7AzMUW
DragonFly-2.0 がリリースされ、一緒にHAMMERファイルシステムもリリースされたようだ
URLﾘﾝｸ(www.dragonflybsd.org)
688:login:Penguin
08/07/22 16:12:57 VOG6EVJj
>>685
アメリカなんかだとホントは無罪なんだけど裁判でああなった以上
どうしようもないから減刑求めて取引に応じたりもする。
さっさと戻ってこいreiser
689:login:Penguin
08/07/22 16:37:19 sLuOyJLa
なるほど。ってことは妻の遺体は超能力で見つけたのだろうな。
690:login:Penguin
08/07/22 22:38:35 z5KcTQ8y
いや、やったのはロシアの機関なんだっていうことにも出来るかも。
691:login:Penguin
08/07/22 22:44:06 Z2YesIa9
B*-Treeのもとで見つけたに決まってるじゃまいか
692:login:Penguin
08/07/22 22:46:05 AFv/tj1S
無罪の場合、妻の埋められた場所は知っていたが殺人も死体遺棄もしていない、となる。
では裁判で妻はロシアかどこかで生きている説を主張していたのは何故か。
事実が奇妙奇天烈過ぎて話しても信じてもらえそうにないから、ではなく
真犯人に繋がる証言をすることで自分に危害が及ぶことを恐れた、と考えると素直だ。
次回
名探偵の登場により次々と明かになる事実
謎に包まれた真犯人の意外な正体とは！
693:login:Penguin
08/07/22 23:43:51 41XqpPs5
>>692
いやいやいや
死体遺棄罪ってのは遺体を意図的に放置した場合にも適用される
つまり普通に遺体の場所をゲロっただけでヤヴァイ
694:login:Penguin
08/07/24 00:03:13 /rSNYCK8
Proposing Read-Only ZFS
URLﾘﾝｸ(kerneltrap.org)
>A recent thread on the lkml discussed a blog entry stating that minimal ZFS support for GRUB was available under the GPL license, "we could now use that code to implement support for ZFS in the Linux kernel."
695:login:Penguin
08/07/24 10:57:29 2UVyAh2t
URLﾘﾝｸ(journal.mycom.co.jp)
とんぼ始まった？
696:login:Penguin
08/07/24 11:04:03 qLdaFHCx
SSD専用FSの決定版まだぁ
697:login:Penguin
08/07/24 11:35:59 JrTy/m7u
なんか来ましたよ。
URLﾘﾝｸ(lkml.org)
698:login:Penguin
08/07/24 11:41:20 DW3VlEdg
ここでいつものVFSが糞君の登場です
699:login:Penguin
08/07/24 15:22:17 SCv49sC5
(bugに)当たらなければどうということはない。
700:login:Penguin
08/07/24 19:05:59 uws0Q46E
>>697
現在の実装の程度は知らないが、
目指しているところはおもしろそうだ。
701:login:Penguin
08/07/25 19:41:06 WWjs91oU
デバイスドライバから直接ファイルを操作できる実験的な取り組みについて
以前に記事かなにかで見たことがあるのですが、そのファイルシステムの
名称をご存知の方がいれば教えてください。
702:login:Penguin
08/07/25 19:53:04 pZIqqXcD
Proposing Read-Only ZFS
URLﾘﾝｸ(kerneltrap.org)
703:login:Penguin
08/07/26 11:59:23 jNXTtp70
>>697
DragonFlyのHammerにも触れてるよ
URLﾘﾝｸ(tux3.org)
DragonFly kernel@ のスレでの対談(?)
URLﾘﾝｸ(leaf.dragonflybsd.org)
お互いいい影響があるといいけど