11/09/21 14:08:17.55 kwbX5VAJ
>>429
そういう環境じゃZFSなんて使い物にならないから、
ZFSをシュリンクしてFATクラスまで機能削減したzFSが必要と言いたい？
431:login:Penguin
11/09/21 16:03:23.32 Of/LX3Jt
個人用途だからこそRAID1という贅沢はできない、RAID5は危ないからRAIDZ使いたい、という需要はあるんじゃね？＞ZFS
数？十数TBのストレージだと全部非同期バックアップというわけにもいかんし
コストまで考えてもRAIDボード買ったりWinでオンボRAIDやるより安上がりだし
432:login:Penguin
11/09/21 16:16:07.04 a1Hj+Tf0
>>431 何十TBあろうと、バックアップが一番安上がりじゃないかな
電気代とか・・・
2TBx18の36TB を同じく2TBｘ18の36TBで週1でバックアップ取ってるよ
バックアップはミラー(更新上書き)で平均数時間で終わるので月に20～30時間程度稼動する感じ
バックアップが終わると勝手にシャットダウンする
何がいいってどんなOSでもHDD単体でリストア・アクセスできるので、RAID系のトラブルとは無縁な点かな
433:login:Penguin
11/09/21 19:19:11.76 7RVPFeqF
zfs、メモリ消費とraid zしたときのcpu負荷がきついな。
434:login:Penguin
11/09/21 19:30:45.07 e/hLzBp7
でも、メモリも安くて手に入るしなー。
435:login:Penguin
11/09/21 20:20:59.31 m3wbiRtN
>>430
あれは 128MB のメモリで動くように ZFS もチューンされてるのよ
日の目を見ないのは実に勿体無い
436:login:Penguin
11/09/21 21:23:27.92 F0TO9L3v
ID:8iMA/1Y2はたぶん、ものすごいバカ。おまけに包茎。関わると恥垢臭がうつるので
放置推奨。
437:login:Penguin
11/09/22 12:08:37.19 BL2XoA4T
>>435
まじか、それは知らなかった。しかしZFSの仕組み的に、
10TB単位のストレージをそのメモリ量でハンドルできるとは到底
信じられないのだが、どういう魔法的な技術が使われているんだ？
438:login:Penguin
11/09/22 13:19:20.82 ZpYKl2c/
>>437 いや、理想はそうでも実際はそんなメモリでは動かないからね
10TBだと最低OS抜いてZFSだけに5GBは無いと死ぬだろ
まぁ今は16GBまで積めるから30TBぐらいはいけんじゃね
439:login:Penguin
11/09/22 13:58:17.20 4PDiV5It
zfsがメモリがたくさんいるのはわかったけど、
それじゃホームサーバに10TB,30TB必要な時にzfs以外で最適解はなに？
2TBディスク5本で10TBだから簡単な時代だからねぇ。
fsck走って1日2日っていうのは勘弁だし。
440:login:Penguin
11/09/22 14:08:37.02 m9bnXgpH
xfs
441:login:Penguin
11/09/22 14:35:43.34 QAmCAelX
>>440
だな
442:login:Penguin
11/09/22 17:20:07.52 ZpYKl2c/
>>439 DrivePoolかな二重化しかないけど、メモリは要らないよ
443:login:Penguin
11/09/22 18:33:11.00 2PnZcMLv
＞fsck走って1日2日っていうのは勘弁だし。
なんかext3が最新だった辺りの時代から来てるのがいるな
444:login:Penguin
11/09/22 19:02:48.16 ZpYKl2c/
>>443 おまえ10TBという物理サイズ舐めてないか？
HDDの転送速度を超えることはないんだぜ？
445:login:Penguin
11/09/22 19:06:09.70 DMao/mOM
ふつーtune2fs -c 0だろ
446:login:Penguin
11/09/22 21:52:28.06 QAmCAelX
>>444
24TB+xfsで10分かからん
447:login:Penguin
11/09/22 22:19:55.31 so8FuAcc
fsck.xfsに10分もかかったらビビるわ
448:login:Penguin
11/09/22 22:52:50.06 xtcIORqq
fsck.xfsは時空を超越してるからな
449:login:Penguin
11/09/22 23:02:15.32 GH4Uv3vp
おっとmain関数よりコメントの方が多いfsck.xfsさんの悪口はそこまでだ
450:login:Penguin
11/09/23 00:27:17.18 xynqWG6o
まあ悩んでいる間に底辺のメモリ量も増えて ZFS の時代が来ると
451:login:Penguin
11/09/23 00:30:43.56 Vgb1Rjqv
そこで颯爽とZAFSが登場
452:login:Penguin
11/09/23 10:41:40.95 jkv92p1m
zfsかいいなぁ
おらも高速なマシンがほしいだ
453:login:Penguin
11/09/23 11:10:42.60 XuoYeMN7
btrfsは何をしておるんじゃ
454:login:Penguin
11/09/23 11:57:07.24 TCNR5ivD
今日も人のマシンのファイルを破壊しながら実験中。
455:login:Penguin
11/09/23 11:59:47.73 TCNR5ivD
メタデータのcrcやmd5はファイル破損を検出できるだけで、
修復できないんだよね？
456:login:Penguin
11/09/23 23:09:52.36 jkv92p1m
で結局zfsはひゃいの？
457:login:Penguin
11/09/24 00:05:14.80 b8VyZz6F
速さの方にチューニングしてないと解釈するのが妥当かと
458:login:Penguin
11/09/24 00:05:27.96 CAT4jfZb
自分で試せよ
459:login:Penguin
11/09/24 02:15:39.86 5FxCZPf9
UFSに比べるとZFSは遅い
でも管理の楽さを考えたら許せる
460:login:Penguin
11/09/24 02:22:11.27 YadKppkO
mdadm+ReiserFS+LVM2の方がZFSより良い
461:login:Penguin
11/09/24 04:54:06.74 afYV5Af2
LVM2のスナップショット機能はあんましイケてない印象がある。
462:login:Penguin
11/09/24 20:04:28.90 dgSFexL+
スナップショットはファイルシステム側でもサポートしてないと安心出来ないな。
その点、NILFSなら絶対の安心を提供してくれるけどね！
463:login:Penguin
11/09/24 22:26:17.94 jh+Xip6z
gitサイコー
464:login:Penguin
11/09/24 23:19:50.42 JYVRKTtb
もう端数みたいな価格で8GB積めるんだからメモリ食うは関係なくね？＞ZFS
ローカルで使うならメモリ食いは困るけど大体ZFS使うのなんてNAS/SAN専用機でしょう。
465:login:Penguin
11/09/24 23:29:27.89 RQzuGj/J
>>464
メモリは問題ないがCPU喰いが困る
466:login:Penguin
11/09/25 01:15:50.04 80e20/8S
ノートで使っとるが
467:login:Penguin
11/09/25 05:13:25.47 IwW/FzQG
URLﾘﾝｸ(www.allbsd.org)
FreeBSD での事例の様だけど
業務ではもう少し待ちかねー
468:login:Penguin
11/09/26 19:07:21.49 CbKQ315J
>>467
FreeBSDへのportingはしらんが、oiやその他のSolarisを無料、簡単に使えるので
不安定なFreeBSDにする必要はないんじゃないかなぁ。
俺も5年前くらいはSolaris(Nevada)のzfsでもよくデータを飛ばしたけど今は安定と
思うけど。
469:login:Penguin
11/09/26 19:27:09.90 u/XPB+E1
少なくともバターFSより全然まし。
470:login:Penguin
11/09/26 19:32:23.21 e5m2HaP3
ベットリfsじゃね
471:login:Penguin
11/09/27 13:33:35.52 zwGArpBP
>>464
x64ならそうだが、最近沸いてるarmでサーバーとか言ってる連中には無理だろ
量と帯域の両方で無理だ、それに帯域増やすと消費電力の利点が消える
472:login:Penguin
11/09/27 14:23:21.04 0qLeAjii
なら、exFATしかないか．．．
473:login:Penguin
11/09/28 00:24:04.77 W78OUf+j
NILFS
微妙に使いどころに悩む
474:login:Penguin
11/09/28 01:01:54.89 zX8lTRZB
>>471
そういう奴はRAIDｰZ使わずにファイルシステムとしてZFS使えばいいんじゃね？
どうしてもRAID必要なら別途ハードウェアで
475:login:Penguin
11/09/28 15:50:52.94 Jmh5TnDt
ext4、なんかもっさりする
気のせいか？
476:login:Penguin
11/09/28 16:19:25.16 81rQN3R+
気のせいじゃね、うちではキビキビ動いてる気がする
477:login:Penguin
11/09/28 18:04:36.41 xrEKABkR
ext4は開発途上だからカーネルが新しい方が良いぞ
新しすぎるとバグ入りになりかねんけど
3.0だけど、今のところext3より挙動は良い
478:login:Penguin
11/09/28 18:07:49.19 fWC/EOuJ
>>477 何を持って良いんだ？
479:login:Penguin
11/09/28 18:11:18.19 2ZCg0OML
同じHDDで比較した他のFSを言ってないからコメント出来ないよな。
ext4はもう良い感じで枯れて来てる気がしてたが……。
480:login:Penguin
11/09/28 23:08:20.37 AjWI8pSv
>>479
五年位xfs使ってて試しにext4にしてみたけど、随分こなれてるね
相変わらずlost+found最初から作るのは頂けないけど
ext2の頃からは隔世の感があるなあ
481:login:Penguin
11/09/29 00:06:37.86 3LlZxr4a
zfs on linuxはいつになったら0.6.0stableが出るんだ
482:login:Penguin
11/09/29 00:17:17.12 3qB2B6jL
なんぞこれ
URLﾘﾝｸ(www.allbsd.org)
> こ の へ ん の記事、かなりでたらめなので信じないほうが良いと思います。
URLﾘﾝｸ(gihyo.jp)
> ここで取り上げた内容を補完する素晴らしいドキュメント
483:login:Penguin
11/09/29 14:14:43.28 ZjuJY5oi
>>480
lost+foundはマウント済みの目印に使ってるから
いまさら無くなられると困る
484:login:Penguin
11/09/29 14:24:18.49 XCVk6YPQ
そんな使い方するなよｗ
485:login:Penguin
11/09/30 09:12:30.04 rcdHUGPg
>>484
するだろ。noautoの時は特にそれでマウント忘れに気づくことが多い。
vfatは困るんだよね。
486:login:Penguin
11/09/30 09:52:29.52 uyfCFfv/
ねーよｗｗ
487:login:Penguin
11/09/30 09:55:01.16 ngaR99T7
>>483
/proc/mounts とかじゃ駄目なんか?
488:login:Penguin
11/09/30 10:33:43.33 WYy/QVqU
おれは lost+found は見たくないなぁ。
マウント忘れとか言ってるけど、そもそも >>485 はいちいち手動でマウントすんのかよ。
そもそもマウントしてるかどうかなんて、
ディレクトリが空っぽならマウントしてないわけだし、
空っぽじゃなければマウントしてるということだろ。
それともなにか?、空じゃないディレクトリにマウントしてんのか?
いったい、どんな使い方すりゃそういう発想ができんの?
489:login:Penguin
11/09/30 11:50:02.61 ACR7fMHR
まあいいさ、今度>>485のディレクトリに片っ端からlost+found掘っておいてやるから。
490:login:Penguin
11/09/30 12:15:50.39 rtApsSqF
>>488
> ディレクトリが空っぽならマウントしてないわけだし、
そこで判定はしたくないなぁ。
491:login:Penguin
11/09/30 20:59:24.89 uArDJlFs
>>488
パーティションの再構成中は手でmountして書き戻してる。自動でマウントするのは全作業終了後。
492:login:Penguin
11/09/30 22:21:37.32 iokNb/Mi
>>482
ツンデレなんだよ、言わせんな恥ずかしい。
493:login:Penguin
11/09/30 22:28:02.84 J2pm6fHD
>>485
おまいはdfとかmountコマンド打つ気すらないのかw
494:login:Penguin
11/10/01 01:47:47.13 McvhjrXL
自分は、bind mount してる場合など困るから、
487 と同じように /proc/mounts みてるな～
495:login:Penguin
11/10/01 21:10:14.31 zMBMsVkH
シェルスクリプトで考えると確かにlost+found有無を見るだけってのは非常に簡単で合理的だと思った
496:login:Penguin
11/10/01 21:17:08.87 rOV5RHi3
判別する必要ないぞ実は
497:login:Penguin
11/10/01 21:30:13.90 OkXJrPqL
>>495
/etc/mtabとか/proc/mountsとかmountの出力見るほうがよっぽど合理的じゃないか
498:login:Penguin
11/10/02 00:34:02.92 c0DcHtK6
>>497
mountの状況がprocessごとに違う可能性がある以上、
/etc/mtabやmountの出力見るなんて、lost+foundと五十歩百歩の合理性しかない
499:login:Penguin
11/10/02 00:45:37.65 mEShoWvB
>>498
そういう状況が起こりうる場合を思いつかんので
もう少し詳しく説明してくれ
500:login:Penguin
11/10/02 01:00:37.89 Mw9MOLk6
NTFSパーティションとかの場合はどうすんだろ？
意地でも/proc/mounts見ないのかな。
「俺はそんなFS使わんから知らん」かな。
個人的環境の使い方を一般論として語るからこうなったんじゃ？
501:login:Penguin
11/10/02 02:23:26.58 KF5vOJuy
NTFSはどうかわからんがvfatの時は困っているようだな。
>>485 によると。
「判定に困るケースが出るなら、その判別法は使うべきではない」
とまあ俺は先達に言われたことがあったような記憶があるが、
そういうことなんじゃないのかなあと思ったり。
502:login:Penguin
11/10/02 15:35:34.93 GCf9YY+5
/proc/mountでは不適切である理由を以下に述べよ(10点)
503:login:Penguin
11/10/02 16:40:14.25 1vfXVKII
>>499
起こりうるもなにも、そういう状況を起こすアプリ/設定使ってれば起きるし、
起こしてないことを確信できるなら問題ない、つう意味で、
/etc/mtab or mountとlost+foundの合理性なんて同程度でしょ
504:login:Penguin
11/10/02 16:46:36.45 Cj7o/yLg
シェルスクリプトで -d で簡単に判断できるのはやっぱり便利じゃね？
lost+foundは見ないけど固有のディレクトリでよくやる
505:login:Penguin
11/10/02 17:45:55.35 8Jjlea2R
「そういう状況を起こすアプリ/設定使ってれば起きる」というのは自明で情報がない
我々が知りたいのは、そういう状況はどれくらい起こり得るのかという定量的な問題
問題が起る状況を仮定すれば、問題が起るのは当然だし
問題ない状況を仮定すれば、問題がないのは、あたりまえ
無意味なことを言って、何か言ってるつもりになるのは何故？
506:login:Penguin
11/10/02 18:14:24.14 1Vn17Itr
/etc/mtab は嘘かもしれない。 ∵ echo hoge >> /etc/mtab がエラーにならない。
/proc/mount は無いかもしれない。 ∵ chroot hoge すると /proc が見えなくなる。
lost+found は無いかもしれない。∵ ext2/3/4 以外にはそんなもんない。
mount する前のディレクトリは空でないかもしれない。 ∵ /var/run や /var/lock に手でマウントする時などで起きる。
慎重に扱えば /proc/mount がマシだが ...
mount -bind で /proc/mount が嘘をつくのは直ったのかな。
あまりに酷くて -bind 使わなくなったので最近の動向は知らない。
507:login:Penguin
11/10/02 18:20:18.50 XOmPlDmu
すげえな、定量的にか。
vfatをmountしててlost+found判定できない状況はどれぐらい起こりえるのかという定量的な問題
をまず解説してみてください。
> /etc/mtabとか/proc/mountsとかmountの出力見るほうがよっぽど合理的じゃないか
って言うのは、もちろん定量的(笑に検討した上で「よっぽど合理的」言ってるんですよね？
508:login:Penguin
11/10/02 21:01:35.01 Z/mpTOWm
df .
ではだめなのかな
509:login:Penguin
11/10/03 00:49:14.07 gr2ahZrN
横槍だけど、mountとlost+found見るので困るケースが「定量的に」同じくらいの頻度じゃないと同程度の合理性とは言えねーよなー。
510:485
11/10/03 08:48:57.51 CORsXLR6
以前、/usr/localをマウントしてるものだと思ってtarから書き戻すとこだった。パーティション切っただけで、マウントしてなかった。
疑いもしてなかったからdfもmountもたたかなかった。lsなんて習慣的に叩いてるもので気づけたから助かった。
その程度の話だったんだが、えらい盛り上がってるなあ
511:login:Penguin
11/10/03 11:55:38.92 7+9OxQsa
起こり得る確率で言えばそりゃ低いけどさ、
まっとうな方法ではないよ。
512:login:Penguin
11/10/03 20:28:12.04 ZUJC4f7a
俺もマウント判定にディレクトリ有無検査を自分作業用のスクリプトに組みこんでいるな
lost+foundじゃなくって自分が使うディレクトリ名だけど。
513:login:Penguin
11/10/03 20:33:18.26 l6yscdvc
mount point になってる directory を stat して inode 番号で判別
という案を出してみる
514:login:Penguin
11/10/07 06:35:42.18 KTVmCkMm
おはようお前ら。
Ubuntu 11.10を弄ってて気付いたんだが、
fallocateかext4にバグがあるな。
11.04までは、例えばfallocateで256MB確保した場合、
32768 blocks ＋ 32768 blocks の2extentsが確保されていたのが、
11.10だと、
32758 blocks ＋ 32758 blocks ＋ 20 blocks の3extents確保されるようになってる。
しかも隙間が空いてて断片化しまくり。
128MBまでは正常に確保できるみたいだから、
Ubuntu 11.10でfallocateするときはサイズに注意な。
515:485
11/10/07 07:41:51.39 7/YxsuQ1
>>514
kernelのバージョンでいえよ。
516:login:Penguin
11/10/07 12:05:16.62 VMl41Yta
>>514
MLで言えよ。つか読んでる？
517:login:Penguin
11/10/07 12:10:12.00 VMl41Yta
Kernel.org 落ちてるんだっけか。ext4-MLが読めね。
518:login:Penguin
11/10/07 15:49:38.81 K7C6qYpm
英語読めないです(´；ω；｀)
519:login:Penguin
11/10/07 17:48:00.40 pnBOld6j
>>518
馬鹿も休み休み言え。
向こうの国じゃ幼稚園児だって読むぞ。
520:login:Penguin
11/10/07 17:59:35.12 y4La4Eik
英語なんか誰でも読める！
ただ意味が解らないだけだ。
521:login:Penguin
11/10/07 18:35:49.59 KTVmCkMm
>>515
これでいい？
Linux Ubuntu-PC 3.0.0-12-generic-pae #19-Ubuntu SMP Fri Sep 23 23:10:56 UTC 2011 i686 i686 i386 GNU/Linux
>>516
読んでないよ。
確実に断片化するバグなんて皆すぐ気付くだろうから、
そのうち修正されるんじゃね。
つか既に修正済みかも。
522:login:Penguin
11/10/07 20:57:18.09 KTVmCkMm
テスト用ディスクをXFSでフォーマットして、どうなるか試してみたけど、
XFSだとfallocateしても断片化しないね。xfs_dbで確認したけど断片化率0%だった。
Ubuntu 11.10のext4が逝ってるってことでFAかも。
にしてもXFSってwrite遅いな。
読み込み140MB/sぐらい出るのに、
書き込み108MB/sぐらいしか出ない。
523:login:Penguin
11/10/08 04:40:20.38 7NVcxFML
>>521
thx 3.0.0使う時は気をつけるよ
524:login:Penguin
11/10/08 09:03:45.01 sy/GA988
xfsはlogbufs=8とかするとマシになるんじゃ
nobarrierだとさらにマシだけど電源切れたらさようなら
525:login:Penguin
11/10/08 17:18:01.14 b1AJHvul
>>524
noatime,nodiratime,osyncisdsync,nobarrier,logbufs=8
とかやってみたら、writeの速度は変わらなかったけど、
readが150MB/sまでいったよ。
GPartedでフォーマットしたときは、
書き込み速度も140MB/sぐらい出てたのに。
なんでだろうな。
526:login:Penguin
11/10/09 23:37:59.65 TBs2u8Gf
Ubuntu 11.10のext4、fallocateの精度上がってるな。
128MB以下のファイルならXFS並に断片化しにくい気がする。
527:login:Penguin
11/10/11 09:52:54.36 DXl5Icay
>>524
HDDのディスクキャッシュ切るのとどっちが危険なんだろう。
両方ちゃんとすると明らかに遅くなるので片方だけとか日和ってみたい。
528:login:Penguin
11/10/12 10:03:45.79 ZIBv2QEr
あれ11.10もうでたのか
upgradeしようかな
10.10から
529:login:Penguin
11/10/12 16:32:04.75 QcLm5pLZ
13日だろ？まだだろ
530:login:Penguin
11/10/12 20:37:42.56 ZIBv2QEr
>>529
一日早く
daily Build URLﾘﾝｸ(cdimage.ubuntu.com)
入れてしまった・・
531:login:Penguin
11/10/13 17:14:05.59 kl5132u3
>>526
つまり1エクステントか
532:login:Penguin
11/10/13 19:36:48.36 fboqj5Q9
ntfs-3gって、48bit LBAに対応してますか？ちなみにうちのファイルサーバーのバージョン↓
ntfs-3g 2010.10.2 integrated FUSE 27 - Third Generation NTFS Driver
533:login:Penguin
11/10/14 01:01:50.19 wLXztjLe
新マシンのFSを何にしようかと検討に検討を重ねた結果、ZFSサイコー、おらSolaris使うだという結論になって鬱。どうしてこうなった。
534:login:Penguin
11/10/14 22:34:29.47 hkvByvFR
nexanta?
535:login:Penguin
11/10/14 23:02:16.19 aFcQncdQ
つ StormOS
536:login:Penguin
11/10/15 18:34:20.05 KhS6ul5V
OpenIndianaもあるよ！
まぁapt慣れてるならnexantaでいいだろうけど。
537:login:Penguin
11/10/17 13:01:39.22 Ura9TgxZ
URLﾘﾝｸ(www.nikkan.co.jp)
> 富士通、読み書き毎秒１テラバイトのファイルシステムソフト開発
これGPLで出してくれたら一生富士通のパソコン買うわ。
538:login:Penguin
11/10/17 13:05:14.38 AbyjA/25
100MB/sを1万台とかじゃね？
539:login:Penguin
11/10/17 13:13:12.69 iqtHA8nR
1万台のraid0 ... 略して aaad, 胸熱w MTBFなん分くらいだ。
540:login:Penguin
11/10/17 13:28:55.05 1dmDF2/F
RAIDというよりGfarmみたいなネットワーク越しの分散ファイルシステムと予想。
541:login:Penguin
11/10/17 18:18:15.94 T68JYRyL
特盛キャッシュ
｜
SSDいっぱい
｜
10000rpmのHDD
とかだろうけど、そのスピードについてこれる
インタフェースがあるのか？
542:login:Penguin
11/10/17 18:19:57.14 AbyjA/25
クラスター用って書いてあるだろ？
543:login:Penguin
11/10/17 18:59:48.45 1dmDF2/F
まあ元の記事自体がミスリーディングというか
> 従来のデータ読み書きは最高毎秒２００メガバイト（メガは１００万）程度だった
と書いてあるから「SATA300と比較して50000倍速いインタフェースを作ったよー」
って主張してるように思えるけど実際は違うっぽいよな。
544:login:Penguin
11/10/17 20:04:16.82 1+RZGZs5
＞従来のデータ読み書きは最高毎秒２００メガバイト（メガは１００万）程度だった。
クラスタの世界でSATA2のSSD程度なわけねーだろｗｗ
545:login:Penguin
11/10/17 20:09:58.66 AbyjA/25
>「FEFS」は、オープンソース・ソフトウェア「Lustre」（注2）をベースに、独自の機能強化を加えています
とか書いてあるから、そのうちGPLで出してくるだろ。
546:login:Penguin
11/10/17 22:04:15.61 1QWZTus9
期待age
547:login:Penguin
11/10/17 22:42:34.47 iNgZKaLM
直線番長だったら嫌だな
548:login:Penguin
11/10/18 12:41:02.00 gbxYFctL
これdisk 10k 台で 1TB/s だよ
disk あたり 100MB/s って、ぶっちゃけ luster だしなー的な
549:login:Penguin
11/10/19 14:29:38.01 rASm9HrG
>>548
ストライプサイズが異常に大きくなってるけど、それでも動くようにしたのがキモなんだろうな。
550:login:Penguin
11/10/20 00:08:56.54 tamYMXA2
お邪魔してすみません
CentOS5のMySQLのバックアップデータをCentOS6に復元するには、
事前に、CentOS5のデータのファイルシステムをext4に変更してから、
バックアップを取る必要があるでしょうか？
また、ログファイルなどをCentOS6に取り込む場合も、
データのあるパーティションをext4に変換しておかなければならないでしょうか?
CentOS5からCentOS6へのデータ移行の具体的な記事が、
見つけられなかったので、幼稚な質問ですが、
どなたか、よろしく、お願いします
551:login:Penguin
11/10/20 00:31:32.81 zSLjBQgo
普通はext3からext4にファイルをコピーしても問題はないはず。
ファイル所有者とかのメタデータは気を付けないと失われちゃうかもしれないけど
MySQLの挙動に影響するかは知らない。
不安ならバックアプデータのmd5sumでも取ってちゃんと移動できたか試してみれば？
552:login:Penguin
11/10/20 06:17:09.12 OJkoZLgF
メタデータが変わったからってmd5が変化するわけないだろ
553:login:Penguin
11/10/20 07:03:09.20 QCaZnww4
>>552
554:login:Penguin
11/10/20 07:05:58.37 i94CzyCE
MySQLのバージョンにも注意な
555:login:Penguin
11/10/20 10:13:46.52 NWkZNNQ6
>>550
CentOS5->6程度なら、データベースのあるフォルダを tar で固めて、移行後それを書き戻すので問題ないはず。
レプリケーションとかしてたらステータスに注意しなくちゃいけないけど。わざわざext4に変換しなくてもおｋ。
どうしても心配なら、mysqldumpでデータを取り出して、それを復元するのでもおｋ。
556:login:Penguin
11/10/20 16:45:29.78 tamYMXA2
>>551-555
どうも、ありがとうございます
助かりました
557:login:Penguin
11/10/21 19:23:32.21 wb7cZvNG
32bitと64bitでもそのまま行けんの？
mysqldumpしたほうが良い気するわ
558:login:Penguin
11/10/21 21:09:33.38 Vbbvv7u5
は？
559:login:Penguin
11/10/21 21:44:05.05 YvXJTqh/
経験上はいける
100%大丈夫という保証はできないが．．
560:login:Penguin
11/10/21 22:55:29.50 KZ58fQPO
久々に Windows 触ったら NTFS がびっくりするくらい遅い。
扱うデータのせいか、気のせいか。
561:login:Penguin
11/10/22 00:33:44.96 FCHGCJn0
>>560
速さよりもデータ損失防止に重きを置いたFSだし
562:login:Penguin
11/10/22 22:57:31.30 vG2ry+t5
read 240MB/s以上を出したいんだけど
ZFSにしたHDDで、でるかしら
563:login:Penguin
11/10/24 10:21:46.84 QuHD0jtT
>>562 でるわけないでしょ
564:login:Penguin
11/10/24 10:53:42.06 0/l70kBg
複数台使えば基本は並列になるんだから
でるんじゃないの?
具体的に何台でってのは試さないとワカランけど
565:login:Penguin
11/10/24 10:59:57.48 XsQPovD/
>>563
いまのハードウェアRAIDにRAID5が15000rpm３台で
それくらい出る。次作るなら同じレベルにしたいなと
566:login:Penguin
11/10/24 11:14:03.85 HCnPorIh
シーケンシャル「リード」ならSATAの250GB世代な骨董品で
完全ソフトウェアRAID6の8台でも余裕で300MB/s以上出るが
567:login:Penguin
11/10/24 19:04:55.84 IoPBPusq
それはHDD側のキャッシュにうまいこと当たった場合でなかろうか
568:login:Penguin
11/10/24 22:21:06.35 HCnPorIh
1GBのシーケンシャル読み出しが数MB*6のキャッシュに収まるならそうだろうね
569:login:Penguin
11/10/25 00:15:55.53 CBwXvk4T
>>567
RAID6の8台なら、リードも約8台分出るのでは？
HDD(仮にSeqRead 50MB/sとして) × 8 = 約400MB/s だし。
570:login:Penguin
11/10/25 00:22:20.53 nHeXkgvP
SeqRead 50MB/sってどこの骨董品だよ
571:login:Penguin
11/10/25 16:03:07.38 /aEOyT6+
RAID6 の8台だと read は6台分だったりしないんだろうか
まあ大きいサイズを読み出すなら8台か…
572:login:Penguin
11/10/25 16:40:54.05 /PmSxWz5
3.1でext3でもbarrierがデフォルト有効になったからベンチ取る時気を付けろよお前ら
573:login:Penguin
11/10/25 18:20:52.78 ARtuI8wn
>>571
読み出しているどの瞬間も二台分は必ずパリなんだから
どんなに大きなサイズだろうと実データの読み出し帯域は6台分だろ
574:login:Penguin
11/10/25 18:27:07.33 WlnpD4BY
といってもストライプ(RAID0)じゃないので、台数分の速度にはならんよ
台数多いほうが速いとは思うけど、コンスタンスにその速度が維持できるかは微妙だな
575:login:Penguin
11/10/25 18:27:13.26 ptftyTM4
どうなんだろ。読み込み時にパリティチェックしなければ8台分出そうな気がする。
パリティの部分を外して読み込まないといけない分ヘッドの移動距離は長くなりそうだけど。
576:login:Penguin
11/10/25 20:03:03.66 wDlL5z74
パリティ読まないってなんのためのRAID6だよ
577:login:Penguin
11/10/25 20:15:05.36 caW+ba42
ワロタ
578:login:Penguin
11/10/25 21:34:29.86 U4Apcr0l
pdumpfsっていうソフトを使ってバックアップを取っているんだけど
バックアップ先をext4でフォーマットしたHDDにしてたら
先週あたりからinode不足で止まってたみたい。
去年までXFSのHDDにバックアップしていて、２年くらい使っていたけど問題なかった。
XFSはinode数制限ないの？
ext4でinode数増やして再フォーマットするかXFSにするか迷ってる。
579:login:Penguin
11/10/25 22:11:45.35 68kJin7L
ext4はext2の呪いが掛かってるから、このシリーズはずっとdynamic allocationできない？
今時inode不足とか、流石に古さに凹む。
580:login:Penguin
11/10/25 22:13:49.87 p5uMRVZi
>>576
何言ってるんだ、お高いRAID箱でもreadでパリティチェックする奴なんて、ごく一部だぞ。
581:login:Penguin
11/10/25 22:28:56.77 cc7/oQpS
フォーマット時にinodeの数を指定できるでしょ
582:login:Penguin
11/10/25 22:30:05.57 qQNtJ7OQ
フォーマット時（笑）
583:login:Penguin
11/10/25 22:32:13.12 cc7/oQpS
動的確保をしたいって事？
ならXFSとかだね
584:login:Penguin
11/10/25 22:32:43.67 /PmSxWz5
>>578
逆に生きてるfsの中で静的inodeなのはext2/3/4ぐらい
585:login:Penguin
11/10/25 23:13:07.86 oxmJofWd
>>580
RAIDってresyncするまでデータ壊れててもエラー出ないの？
586:login:Penguin
11/10/25 23:14:25.41 nHeXkgvP
はいはい、ZFS ZFS
587:login:Penguin
11/10/25 23:44:47.14 BOKohEeO
>>585
どのレイヤーの話をしているんだw
588:login:Penguin
11/10/26 00:25:03.91 E4y04L0n
そろそろHansの時間かな?
589:login:Penguin
11/10/26 07:33:48.41 PT5hpJK2
Metadata Replication for Ext4とかまた楽しそうなことしてるなExt4
590:login:Penguin
11/10/26 13:21:33.87 oVTZfdR6
フォーマットとか久々に聞いたわ
591:disklabel
11/10/26 14:20:43.07 ctFFIox9
私の出番が来たようだな
592:VxFS
11/10/26 16:35:56.03 KncxOcgD
ふふふ>>591 は四天王でも最弱よ
593:login:Penguin
11/10/26 19:08:06.57 qbm+Vx12
HAMMER FSどうだろうか
594:login:Penguin
11/10/26 19:50:39.76 Dl/UXFi9
あるとおもいます
595:login:Penguin
11/10/28 00:58:48.83 tJz7ggma
>576
釣れますか
596:login:Penguin
11/10/28 22:59:17.06 2+oo94/P
Linuxでbtrfs待つべきかfuse zfsで行くか、ext3+mdadmで我慢するべきか
597:login:Penguin
11/10/29 01:01:17.98 jj2Wdmfv
そこで、Native ZFS を待つのが漢だろうｗ 俺は待てないので、ext4+mdadm
598:login:Penguin
11/10/29 01:12:59.89 0IjAuJvh
64bit版linuxから32bit版linuxに戻ろうと思ってるんだ
64bit版linuxをインスコするときにインストーラーからディスクをext4にしたんだ
32bitのOS入れなおすときには改めてフォーマットしたほうがいいの？
599:login:Penguin
11/10/29 01:33:26.33 znwjukoE
>>598
ファイルを消すよりフォーマットのほうが速いと思うよ
600:login:Penguin
11/10/29 17:00:34.24 fsv4/Qm4
btrfsの話題が極端に少なくなった気がする
601:login:Penguin
11/10/29 17:19:53.88 PfqIK9x3
btrfsやる気あんのか
602:login:Penguin
11/10/29 19:26:14.76 USMLzu8b
OracleもZFS手に入れたからなあ(とか
603:login:Penguin
11/10/29 20:43:31.20 Yqoi6L1n
とりあえず URLﾘﾝｸ(btrfs.wiki.kernel.org) はいつ復活するのかを問いたい
604:login:Penguin
11/10/29 20:53:11.19 PfqIK9x3
>>603
それもだし、Oracleのページも更新とまってるっぽいし
Oracleはbtrfsやめてzfsライセンス変えてバージョンアップしていくとか？
605:login:Penguin
11/10/30 03:33:50.51 aLd+lnTr
>>600
わが国のＩＴはユーザに使用法を十分説明する時間がありません。
このため、初心者がベテランに疑問についてたずねる光景を目にすることがあります。
しかし本来は事故（情報漏えいなど）が発生した場合の責任は、
接続業者、サーバ運営者、システムを開発したエンジニアにあります。
メーカあるいは購入店にたずねるべきです。
利用者の仕事は自治（掲示板の秩序を守ること）です。助言を行ってはなりません。
素人が専門技術に言及するのは「親切」ではありません。「無責任」です。
海外のプロフェッショナルは、「私の仕事ではない」と答えるはずです。
606:login:Penguin
11/10/30 04:06:25.25 B4loUL9j
>>605
どこの誤爆?
607:login:Penguin
11/10/30 18:19:39.30 SKM8kfv8
Fedora17に間に合うのか
608:login:Penguin
11/11/01 16:41:46.49 r4bUH2nr
久しぶりにスレ覗いたけど、NILLFSの話題が無いな
609:login:Penguin
11/11/01 16:50:06.20 VMNMnS9P
>>608
NILFS2 なら使ってる…バックアップに
610:login:Penguin
11/11/01 20:47:12.89 Vdyt2Hlu
homeにnilfs2使ってるわ。７０ギガ程度。
時々 cat /dev/zero > aaa で満杯にして、rm aaa して運用してる。（問題が起きないだろうかテスト）
今のところファイルが消えたり壊れたりの問題には気づいてない。
速度はext4より遅いかもしれない。ファイルの消去に関して。
とくに、linuxカーネルで make clean した際の速度が、ext4の頃よりも明らかに遅い気がする。
他は得に速度の違いによる不満は感じない。というかext4の頃の速度をいちいち全部なんて憶えてない。
もしもrm -rf %HOME してしまっても平気というのが精神的に安心感があっていいと思う。個人運用でも。
git commit や git push したときの安心感に似てる。バックアップ的意味での。
dfすると常に90%程度ディスクが埋まってる状態（cp保存のため）。
試しにその状態から５ギガほど cat /dev/zero > aaa しても、df の結果は変わらず９０％程度のまま。
ただ、デーモンが5ギガ分のガベージコレクションのために裏でガリ…ガリ…ガリ…と呼吸のようなペースでやりつづける状態になる。これが正直うざいが、
構造上仕方ない。動作音が気になるならSSDにすればいいのだと思う。
611:login:Penguin
11/11/01 23:11:39.98 7henh+OE
%HOME は何ぞ
612:login:Penguin
11/11/01 23:17:22.07 CFiJvwsP
git pushは緊張するぞ、バックアップでも
613:login:Penguin
11/11/02 20:50:05.53 Xlvqymu1
／'i;ii;ii;ii;ii;i: .: .: .し: .: .: . J: .: .＼ ||:: |
'i;ii;ii;ii;ii;ii;i;:: .: . : .,ｨZＺ;;ﾌ: .: . ヽｴヽ .||:: | ヒッ ﾋｯ ヒッ ﾋｯ ﾋｯ
'i;ii;ii;ii;ii;i;:: .: .: . ": ._;_;_;..::::: .: . /二ヾ ||:: |
'i;ii;ii;ii;ii;ii;i : .j : . : .ｨ､◎ヾ::::.:.:.（<◎ ! .||:: | ヒッ ﾋｯ ﾋｯ ヒッ ﾋｯ ﾋｯ ﾋ
'i;ii;ii;ii;ii;ii;i: .: .: . /::::::￣ノ :::::.:.: .＼"{ ||:: |
i;ii;ii;ii;ii;ii;i: .: .: .: .: .: .-'': . /: .,,,,,_:::_,ヽ､ . ||:: | ヒッ ﾋｯ ﾋｯ ヒッ ﾋｯ
i;i/⌒ヽ: .:::::::.: .J: .: .: .: . ヽ::｀“::Ｔ“'::.:ｉ ||:: |
;:{ i: .ﾊ: .: .: .j: .: .: .: .: . /::::: _;;.-‐ー､ | . ||:: | も、もう待ってられない・・・
;:ヾ: .ｰ: .: .: .: .: .: .: .: .: .: ／_,ｨｪｪｪァ､ﾞ! .||:: |
ヽi;ii;ii;i_ﾉ: .: .: .: .: .Ｊ: . : .｀ｰ-┴┴┴ｲ ||:: |
: .ヽi;i;:i: .: .::::::::.: .: .: .: .: .: ..:::｀ー---' ! ||:: | git push -f
: .: .ヽ;:i: .ヽ:::::::::..: .: .: .: .j : .: .": .: . ヽ{ . ||:: |
614:login:Penguin
11/11/02 22:00:03.88 B11639FP
>>611
%HOME%をtypoしたのだろう
615:login:Penguin
11/11/02 23:03:16.46 IxLLzwSI
>>614
どこのWindows w
616:login:Penguin
11/11/03 16:10:03.60 ejLnHJpN
ファイルシステムの特徴の比較を調べていて、
ついつい開発の歴史まで首を突っ込んだら色々な意味で怖くなった。
ソフトは人が作るものだと思い知った。
技術的な良し悪しよりも開発体制の安定の方が重要なのか…
617:login:Penguin
11/11/03 17:20:42.76 bBYACAnT
Ubuntu 11.10にKernel 3.1入れてみたけど、
ext4 + fallocateで断片化するバグは直ってないな。
618:login:Penguin
11/11/03 17:38:49.20 PFsWFGQQ
>>617
バグ報告すればいいじゃん
619:login:Penguin
11/11/03 21:07:16.29 cq+Qxrgw
ふつうにwriteやtruncateした場合は断片化しない状況でも
なぜかアホな確保するとかそんな？
620:login:Penguin
11/11/03 22:06:23.42 bBYACAnT
>>618
多分もう誰かがしてると思う。思いたい。
>>619
空っぽのHDDに1GBのファイルをfallocateしてから書き込んだら断片化しまくりﾜﾗﾀ。
つーかfallocateした後書き込まずにcloseしても断片化しまくり。fallocateの時点で逝ってる。
試しに、e2fsprogs-1.42-WIP-1016.tar.gzをダウンロードして、
Ubuntu 11.10 で e4defrag.c をコンパイルして200MBのファイルをデフラグしてみたら、
デフラグしきれずに断片化してた。
2 extents foundだって、filefrag -vタソに言われたお。
元は12 extentsだったからマシにはなってるが。
ソース見たらe4defragもfallocate使ってるのな。
というわけでNEC社員のお二人にバグレポートを頑張っていただきたい。
621:login:Penguin
11/11/04 08:03:58.85 6+0sPYDE
マシっつーか1extentで管理できるのは2^15*ブロックサイズだからそれ以上どう頑張ったって2より小さくはならねえよ
622:login:Penguin
11/11/04 16:50:58.57 IJtSJcpL
>>621
それは知ってるよ。
filefrag では総extent数が表示されるけど、
-vオプション付けると断片化された分しか表示されんでしょ。
623:login:Penguin
11/11/04 17:00:31.94 IJtSJcpL
↓みたいな感じで違いが出るはず
~$filefrag a.tmp
a.tmp: 8 extents found
~$filefrag -v a.tmp
Filesystem type is: ef53
File size of a.tmp is 878968830 (214592 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 113362944 32768
1 32768 113395712 32768
2 65536 113428480 32768
3 98304 113461248 32768
4 131072 113494016 2048
5 133120 113498112 113496063 32768
6 165888 113530880 32768
7 198656 113563648 15936 eof
a.tmp: 2 extents found
624:login:Penguin
11/11/05 20:52:35.03 SpfJmdFo
>>616
kwsk
625:login:Penguin
11/11/06 07:02:18.58 xMbj4okC
NTFS安定しすぎでつまんないお
626:login:Penguin
11/11/06 16:51:07.43 WxFAsrze
NTFSはスナップショット取れないからなぁ
627:login:Penguin
11/11/06 17:48:47.72 B7RaoTiY
VSSなら有るぞ
628:login:Penguin
11/11/06 17:49:43.21 b0Qmz/7D
お前ら的にHammerFSってどうなの？
629:login:Penguin
11/11/06 17:53:31.48 q+t7QkDH
NTFSは個人的に何度も痛い目にあってるから印象が悪い
630:login:Penguin
11/11/06 18:26:08.35 Udoxbj5V
>>629
うむ。NTFSはなんか怖い。
631:login:Penguin
11/11/06 19:24:01.15 WW+ASP4g
ntfs-3gにやられたクチ？
632:login:Penguin
11/11/06 19:39:53.27 Udoxbj5V
>>631
はい。ntfs-3gじゃなくて自分のデバイスの構成がおかしかったんだけどな
633:login:Penguin
11/11/07 07:07:49.01 uftaH4/2
自爆して怖いってか
634:login:Penguin
11/11/08 20:01:36.96 3EvlQx2a
デカイHDDをnilfsでフォーマットしてみようと思うんだけど
やっぱやめとくね？
635:login:Penguin
11/11/08 20:08:46.63 m7LnlJg/
使い始めたら出来ないし、面白からやってみればいいじゃん
636:login:Penguin
11/11/08 22:10:21.87 yebKytaZ
そうか今気づいたがnilfsって侵入されたときとかでもログ改ざんができない？
まえにやられたときにログ改ざんされて発見が遅れたんで、これはけっこういいかもしれんな
637:login:Penguin
11/11/08 23:02:58.94 GTm+PsZO
>>636
スナップショット消されたら一緒かも
Tripwire がいいんじゃないかな?
638:login:Penguin
11/11/09 00:04:50.15 sdfapi1X
tripwire のログを改竄されたら
639:login:Penguin
11/11/09 00:39:26.55 fCR1GAhj
>>637
スナップショットのスナップショットをgpgで・・・・
640:login:Penguin
11/11/09 08:33:12.40 qfncBaxw
そうか！
スナップショットをgpgでサイン出来るよう実装して貰えばいいんだ！
641:login:Penguin
11/11/10 11:41:31.63 PPwg3rzL
ファイル作成時刻を証明できるFSってあります？
642:login:Penguin
11/11/10 12:17:41.66 aNv5UuZr
>>641
何を持って「証明」とするかをよく考えれ。
裁判などでの「証明」なら第三者が証明できなければならないから、
そもそもFSの範疇外。
643:disklabel
11/11/10 15:58:44.29 48NeiHE6
秒単位の精度でやるのは性能的に辛いけど、日単位でよければ
・時刻認証サーバにチケット（証明書）を発行してもらい、
・そのチケットでファイルに署名したものをチェックサムデータとする、
とかFSだかブロックレベルでやれば改竄検知＋時刻証明を組み込めるな。
644:login:Penguin
11/11/10 18:09:00.53 7evsLDb/
単に mtime みたいなノリで実装してほしい、ってことかな。
645:login:Penguin
11/11/10 23:17:25.15 FHwWp/Vv
帰ったらこんなんでてた
unmountしてluksCloseしてmdadm止めてusb付け直して逆手順したら
ファイルも壊れてないし普通に読み書き出来てるけど何か気持ちが悪い
[7117600.372113] Filesystem dm-5: XFS internal error xfs_trans_cancel at line 1911 of file /build/buildd/linux-2.6.38/fs/xfs/xfs_trans.c. Caller 0xffffffffa033e359
[7117600.372134] Call Trace:
[7117600.372208] [<ffffffffa031a605>] ? xfs_error_report+0x45/0x50 [xfs]
[7117600.372259] [<ffffffffa033e359>] ? xfs_create+0x1e9/0x660 [xfs]
[7117600.372305] [<ffffffffa033980d>] ? xfs_trans_cancel+0xfd/0x120 [xfs]
[7117600.372347] [<ffffffffa033e359>] ? xfs_create+0x1e9/0x660 [xfs]
[7117600.372383] [<ffffffffa02f5f2c>] ? xfs_attr_get+0xac/0xc0 [xfs]
[7117600.372429] [<ffffffffa034b64a>] ? xfs_vn_mknod+0xaa/0x1c0 [xfs]
[7117600.372469] [<ffffffffa034b790>] ? xfs_vn_create+0x10/0x20 [xfs]
[7117600.372481] [<ffffffff81188591>] ? vfs_create+0xb1/0x110
[7117600.372490] [<ffffffff81188c66>] ? do_last+0x346/0x410
646:login:Penguin
11/11/10 23:17:59.22 FHwWp/Vv
続き
[7117600.372500] [<ffffffff811890c4>] ? do_filp_open+0x394/0x7c0
[7117600.372508] [<ffffffff81187c92>] ? user_path_at+0x62/0xa0
[7117600.372517] [<ffffffff812c40d4>] ? apparmor_inode_getattr+0x54/0x60
[7117600.372526] [<ffffffff812fdf57>] ? __strncpy_from_user+0x27/0x60
[7117600.372535] [<ffffffff81196317>] ? alloc_fd+0xf7/0x150
[7117600.372545] [<ffffffff811795ea>] ? do_sys_open+0x6a/0x150
[7117600.372554] [<ffffffff811796f0>] ? sys_open+0x20/0x30
[7117600.372561] [<ffffffff8100c002>] ? system_call_fastpath+0x16/0x1b
[7117600.372570] xfs_force_shutdown(dm-5,0x8) called from line 1912 of file /build/buildd/linux-2.6.38/fs/xfs/xfs_trans.c. Return address = 0xffffffffa0339826
[7117600.372584] Filesystem dm-5: Corruption of in-memory data detected. Shutting down filesystem: dm-5
[7117600.372589] Please umount the filesystem, and rectify the problem(s)
[7117612.413275] Filesystem dm-5: xfs_log_force: error 5 returned.
(以下xfs_log_forceが延々続く）
647:login:Penguin
11/11/11 14:18:47.91 ffl4+brB
>>644
ext4ならもうcrtimeあるじゃん
648:login:Penguin
11/11/11 14:53:11.49 2lgCTLXn
それは時刻が偽造されてないことを保証する仕組みがあるの？＞crtime
649:login:Penguin
11/11/11 15:20:42.37 HxPManhO
>>647
stat でも取得できないのね
650:login:Penguin
11/11/11 15:38:33.15 2lgCTLXn
debugfsでなら読み出せるみたいだな。
新し目のstat(1)だと--format=%kがあればext4/NTFSなら読める。
651:login:Penguin
11/11/11 15:41:18.58 7/gOJE0c
>>647
なるほど
652:login:Penguin
11/11/18 10:38:12.41 fWzjA3IH
ext5は開発されているの？
653:login:Penguin
11/11/20 14:49:45.86 qQ1QPv1s
zfsのライセンスが変更でもされたら本気出すんじゃない?
654:login:Penguin
11/11/20 18:11:52.66 yBAbtA2a
btrfsの始まりもしなかった感は異常
655:login:Penguin
11/11/20 18:19:42.81 x3hh9w7B
btrfsが時期fedoraの標準fsに採用されるって話はどうなった。
656:login:Penguin
11/11/20 18:21:11.98 mp5Tb0Z9
そんな時代もありました
657:login:Penguin
11/11/20 18:28:24.85 lqUtUw5k
NTFSとext2って、使われ始めたのが同時期だと思うけど、
ext2がなくなって、NTFSが生き残ってるのはなぜ？
658:login:Penguin
11/11/20 18:32:12.97 x3hh9w7B
ext2にはext3っていう後継が出てきたけど
NTFSにはまだ後継が出て来てない
というかまだext2は使われたりするけど。
659:login:Penguin
11/11/20 18:34:09.85 kwO4UIIe
NTFSは優秀だからなあ
660:login:Penguin
11/11/20 18:37:33.40 DqILK1Tv
zfsのライセンス変えてbtrfs捨てるなら早くそう言って欲しいな
661:login:Penguin
11/11/20 19:22:12.61 eevTso2J
extが1、2、3、4とバージョンアップしてるように
表面に出してないだけでNTFSだってバージョンアップしてるわけで
662:login:Penguin
11/11/20 19:44:21.83 Z/iyRO62
NTFSがマイナーバージョンアップしているのは事実だけど
ext3でジャーナリングを導入
ext4でファイルシステムサイズの上限を拡張
のような、決定的な不具合を改修する必要が無かったのも事実。
パフォーマンス的なものはわからないけどね。
663:login:Penguin
11/11/20 19:58:42.24 7AQlL4BV
後から付加されたのって順にEFS、オンライン拡張、クォータ、リパースポイント、VSS、TxF、ソフトリンク、オンライン縮小ぐらいで
エクステントとジャーナリングは最初から持ってたもんな
664:login:Penguin
11/11/21 00:18:22.09 rj+Nuuuk
>>657
NTFS4(WinNT3.51～4.0) とか NTFS5(Win2000) とか古いバージョン無くなってますが...
665:login:Penguin
11/11/21 00:54:09.83 uwGtywMO
>>663
恥ずかしいやつだな
666:login:Penguin
11/11/21 03:35:02.93 ISvemJ9i
>>662
「ジャーナリング導入に見られる新しい機能を入れる」ことを
「不具合の『改修』」とは言いません。
基本的な言葉がわかってない輩がもっともらしい事いいなさんな。
667:login:Penguin
11/11/21 09:53:34.55 2EXuoCKH
必要な機能が不足している、というのは
不具合と呼んで差し支えないよ。
主要な用途として使い続けることが出来ないのだから。
668:login:Penguin
11/11/21 09:56:46.27 KgloLUjj
使われなくなったわけじゃないのに、そりゃ無茶な論理だ。
669:login:Penguin
11/11/21 09:59:23.94 mkz4q5n0
日本語が不自由な人だったか
670:login:Penguin
11/11/21 10:07:15.22 eCqv0s84
いえ、頭に不具合がある方です。
671:login:Penguin
11/11/21 12:07:11.84 kAlCr+mK
>>666
そうだな
ext2の不具合なんか放置されてるもんな
672:login:Penguin
11/11/21 13:30:02.86 GbyjMU6L
ext2になんか不具合あんの？怖いんだが
673:login:Penguin
11/11/21 17:11:18.11 XOXw5Znn
怖いならばVXFSを使えば安心
674:login:Penguin
11/11/21 20:23:05.00 PBo87O0A
理屈じゃなく体感でNTFSの方が堅牢な感じがする。
たぶん設計思想の違いがあるんじゃないだろうか。
Linuxの場合「ソフトウエアの問題によりトラブルが発生する」と考えてて、
Windowsの場合「ハードウエアの問題をソフトウエアがカバーする」と考えて
いる様な気がする。
これ、Windowsはドライバを機器メーカが提供するので、マイクロソフトは
粗悪なハードウエア及びドライバの問題がWindowsのせいにされるのに
悩まされたんじゃないだろうか。
なんでそう思うかっていうと、HDDがぶっ壊れるときNTFSからはデータが
回収できるのにExt2/3からはできないから。
Linuxはハードウエアが壊れる前提がないんじゃないかな。
675:login:Penguin
11/11/21 20:32:16.58 PBo87O0A
あとUNIX/Linuxの人がよく言うのに「Windowsは印刷のプレビューが実際と
一致しない」っていうのあるでしょ。
そういうのって問題が出ない人にはさっぱり意味が分からないんだけど、
一致しない人はほんとに一致してないわけ。
でもプレビューってドライバに依存してるから、Windows側ではどうしようも
ないんだよね。
解決策は、安いプリンタ買うなってくらいなんだ。
ほんとひどい話だよね。
でさ、じゃあLinuxなら一致するのかっていうと、そもそもLinuxはOSであって
WYSIWYGとか関係ないから、一致しなくていいんだってわけ。
ここで常識的な人なら「じゃあWindowsのほうがいいね」ってなるんだけどさ、
Linuxな人なら「M$が悪い」ってなるんだよね。
「M$が悪い」とか言われても「え？」ってなるわ。
676:login:Penguin
11/11/21 20:34:02.51 sfctKusd
スレ違い
677:login:Penguin
11/11/21 20:35:29.30 KgloLUjj
そこはせめて、普通の人はとか多くの人はとか書かんかね？
678:login:Penguin
11/11/21 20:56:43.61 PBo87O0A
「常識的な人」を「普通の人」に変えても意味同じだね。
「Linuxな人」を「頭のおかしな人」に変えても意味同じだね。
679:login:Penguin
11/11/21 21:02:38.64 KgloLUjj
下はひょっとするとその通りかもしれんがねぇ……上はなー。
680:login:Penguin
11/11/21 21:17:59.82 oZE9gjHi
頭の可哀相な構ってレス乞食に餌を与えないで下さい。
681:login:Penguin
11/11/21 22:06:25.49 5ksmeRh9
馬鹿はあっちいけ
Linux使っててこりゃ普及するわけないと思った時56
ｽﾚﾘﾝｸ(linux板)
682:login:Penguin
11/11/22 02:03:27.37 Vk2/UZ6z
>>675
板違い
683:login:Penguin
11/11/22 07:25:01.54 r+Od0PlE
さすがに>>675はキモい
684:login:Penguin
11/11/22 14:07:15.82 Ue2C7ara
ほとんどは windowsの，じゃなくて「エクセルの」なんじゃないかと思う今日このごろ
685:login:Penguin
11/11/22 18:22:06.04 cbyMP9q2
extとntfsを比較するのは、不毛としか言いようがないのだが。
linuxではntfsは使えないし、Windowsでextを使うバカもいないだろ。
686:login:Penguin
11/11/22 20:36:30.23 UBs+N3oc
ということで、当時はntfsに比肩できるFSがLinuxに無かったということでよろしい？
687:login:Penguin
11/11/22 20:45:21.78 AsK3JzCh
ntfsは最高さ。何だってできる。空も飛べる。
688:login:Penguin
11/11/22 20:53:33.71 sHJgETTj
レス乞食は虫籠へ
689:login:Penguin
11/11/23 04:00:05.02 /812cs0b
>>686
一般的にはなかったと考えていいんじゃないかな。
俺がext2を初めて使った頃、Windowsは9x系使っててファイルシステムはFATだったからね。
単純にLinuxはダメというもんでもないけどね。
690:login:Penguin
11/11/24 01:57:34.63 DFa22khc
さすがにlinuxはレベルが違った
691:login:Penguin
11/11/24 02:30:09.34 lqCERCmp
そういや、Windows2000くらいまでは、NT系であっても後方互換性や
(それでも)クラッシュした場合の修復ノウハウなんかの都合で
「FATでやってくれ」と注文つけられること、なかった?
692:login:Penguin
11/11/24 02:54:58.80 JY/mpVTS
>>691
Windowsの話は板違いだ
レス乞食は死ね
693:login:Penguin
11/11/24 03:08:44.36 lqCERCmp
>>692
そういう輩がいそうだからext2の話も書こうかとちょっと考えて、
やめといたのにな。
694:login:Penguin
11/11/24 03:12:15.83 lqCERCmp
、とここまで書いた以上、最低限Linuxの話につなげておこうか。
その修復に活躍したのがLinuxのddとfdiskでした。
これで満足かい? 言いたいことはわからんでもないが、もう少し上品にやろう。
Linuxerの品格を疑われるぜ。
695:login:Penguin
11/11/24 03:24:48.97 kjDILr+1
うるせえボケ氏ね
696:login:Penguin
11/11/24 03:56:37.77 wyWScomj
ドヤ顔で無益なことばかり語りたがるレス乞食うざいわ～
697:login:Penguin
11/11/24 07:19:22.58 kjDILr+1
存在自体が無益
698:login:Penguin
11/11/24 21:14:02.45 Rl1IAIqZ
ZFSでさえここで話すことが許されるのに、
なんでNTFSだとこんなに激しく反応するんだ？？
699:login:Penguin
11/11/24 21:39:25.04 YY+8I53s
まーたまた分かってる癖に。
700:login:Penguin
11/11/25 01:30:35.81 nrOJTRQU
NTFSは積極的に使う理由がゼロだからな
701:login:Penguin
11/11/25 05:39:18.83 Rvf/kXwE
ﾌﾟﾌﾟｯwww
702:login:Penguin
11/11/25 09:43:38.25 SJhyhaWK
動画エンコード中に電源切ったらんｔｆｓが破損したんやなｗ
悲劇やなｗ
703:login:Penguin
11/11/26 00:50:37.74 thUJY90I
homeをnilfsにしてがんばってきたが、限界だったのでext4に移行したわ…
移行は cp a b -rf して fstab書き換えただけ。
nilfsは各ファイルで差分が増えてくると効率が落ちるんじゃないか？と。使ってて感じた。
linax kernel の make clean に数十秒掛かった瞬間「あ、ext4戻るべ…」と思った。
nilfsは安心なのはいいんだが、いちいち遅くてこまる。ext4はとりあえず速いから捗る。
また #rm -rf / の入力ミスに怯える日々が始まるお…（＞＿；
704:login:Penguin
11/11/26 00:53:12.02 a45T4fEG
>>703
今どきのディストリなら# rm -rf / は潰されてるけど
705:login:Penguin
11/11/26 02:37:23.07 pq4bJYDu
>>703
バックアップサーバでnilfs2 してるよ
>>704
ディストリビューションじゃなくてGNU の実装だね
GNU coreutils 6.4以降で対応
但し
# rm -rf /*
は実行されちゃう><
706:login:Penguin
11/11/26 09:05:22.48 U0t3Lw6k
nilfs自体はRAID無いんだっけ
707:login:Penguin
11/11/26 14:26:27.62 pq4bJYDu
>>706
無いと思う
softraid の上でdm-crypt してその上でnilfs2 してる
708:login:Penguin
11/11/26 14:40:25.73 QCwJVNxT
RAIDして暗号化してNILFS2してmhddfsが理想かも
709:login:Penguin
11/11/26 18:37:38.48 FG6YKzQX
nilfs2はやっぱログ用途が一番？
710:login:Penguin
11/11/26 19:46:49.77 pP20dQtm
nilfs2は、使ってるうちにパフォーマンス落ちるよな。ログインして、プロンプト
が出るまでに2秒くらいかかるようになって、/をnilfs2で運用するのは限界だと
感じた。今はext4で快適。
711:login:Penguin
11/11/26 20:10:21.13 LpK243r1
なら/etc/log以下にあるログを保存するのがいいのかな。>>nilfs2
712:login:Penguin
11/11/26 20:16:47.09 LpK243r1
d.hatena.ne.jp/hayamiz/20100628/1277742621
“使っていて出会ったバグとして、
削除できないファイルができるこ とがある」というものがありました。
Google Chromeのキャッシュファイルでときどきできるのですが、
削除しようとするとrmコマ ンドがsegmentation faultで落ちて、
その後OSごと固まって死ぬ“
うーむ。
713:login:Penguin
11/11/26 21:47:05.31 53y6cvnR
reiser4はまだかね？
714:login:Penguin
11/11/26 22:24:35.60 FG6YKzQX
>>712
rmがsegmentation faultなんて出たら涙がでるな
715:login:Penguin
11/11/30 13:44:22.23 KJ0OCfmB
人殺しの作ったファイルシステムなんか使いたくないんやなｗ 喜劇やなｗ
716:login:Penguin
11/12/03 14:56:13.82 Zr13zRv+
ext5マダー
717:login:Penguin
11/12/05 00:09:08.58 9ddWdf2S
ZFSをライセンス変更するか、
btrfsの完成をめざすか
どっちにしろボラクルじゃ期待できない
718:login:Penguin
11/12/05 00:53:11.19 pAmXBXLB
URLﾘﾝｸ(btrfs.wiki.kernel.org)
生き返ってた
719:login:Penguin
11/12/05 01:31:16.71 P2A0mI0d
飼い殺しにするつもりなんでしょうか
720:login:Penguin
11/12/05 13:09:09.52 XrybxOrk
>>718のChangelogが2年で6項目しか増えてないってことは実質ほとんど開発進んでないのか、
それともChangelogに書かれてないだけで裏では新機能追加がバリバリ行われてるのかよく分からないな。
721:login:Penguin
11/12/05 19:11:51.76 qbp6xgzd
ZFSの部分はGPLにこだわるOSの悲しさだな・・・
722:login:Penguin
11/12/05 19:21:12.64 pAmXBXLB
アンチGPLに拘るZFSとも言える
BSDなら何の問題もなかったはずなのに
723:login:Penguin
11/12/05 20:02:27.64 aD6O2zJi
数年後にsolarisの処遇に困ったボラクルの判断によってZFSの運命も決まるって事かな？
724:login:Penguin
11/12/05 20:16:45.24 0KlD2Ikk
>>723
なんというSUN事
725:login:Penguin
11/12/05 21:23:32.42 L5wfVr/0
>>724
ｳﾏ
726:login:Penguin
11/12/07 14:23:39.71 DL1qvkB/
>>723
基準がNexenta OSになるだけだろう。
と、思う。
727:login:Penguin
11/12/07 15:22:53.84 2OizTKtm
やる気がないならやめちまえ
728:login:Penguin
11/12/07 16:28:30.25 w2xSnWsQ
実績のあるZFSのコードを取り込むことが出来ず、
車輪の再発明するしかないLinux
それとも、extシリーズの方が将来有望...？
729:login:Penguin
11/12/07 16:48:55.11 BSvWhc7K
XFS最強だから
730:login:Penguin
11/12/07 17:30:33.99 HjBBr5+A
Fedora17でついにbtrfs採用のニュースが来たね
731:login:Penguin
11/12/07 17:52:50.51 TAQpR9N+
URLﾘﾝｸ(fedoraproject.org)
18に延期の臭いがプンプンするぜ
732:login:Penguin
11/12/07 18:00:10.25 HjBBr5+A
>>731
Complete 0% ワロタ
733:login:Penguin
11/12/07 19:57:36.39 5MElhpFr
大容量ディスクと大型セクターをサポートするWindows 8
URLﾘﾝｸ(news.mynavi.jp)
4K nativeのサポートを表明の新ファイルシステムの噂
気になるのはNTFSの存在である。時代をさかのぼると1993年（米国時間）に登場したWindows NT 3.1にバージョン1.0を実装し、バージョンを重ねて現在に至っている。
もちろんNTFSを強化し、機能を拡充する方向も間違いではないものの、新キーワードの導入はマーケティング的な強化にもつながるため、このタイミングで変更する可能性は低くない。
ここで登場するのが、非パブリックなWindows 8の早期ビルドに実装されている「Protogon」の存在だ。具体的な相違点などは明らかにされていないが、
一部ユーザー向けに公開された最新ビルドでは、ファイルシステムの名称が「ReFS」に変更されたというから、単純に見ればProtogonは開発コード名。ReFSが正式な機能名と読み取れる。
同社はWindows Vistaで採用予定だった新しいファイルシステム「WinFS」の開発に着手したが、データベース的機能を担う設計が当時のハードウェアでは快適に動作しないため、結果的に破棄している。
"Resilient FileSystem"と呼ばれるReFSがWinFSの後継ファイルシステムになるのが決まっている訳ではないが、4K nativeをサポートするファイルシステムとして世に登場する可能性は高い。
ただ、ここで意識しなければならないのが同時開発中の｢Windows 8 Server」（開発コード名）の存在である。
本来WinFSは"Windows Future Storage"という名称であり、同技術はファイルシステム自身に検索機能を担わせ、すべてのファイルをオブジェクトとして管理することを目標としていた。
ReFSにどのような機能が搭載されるのかは明らかではないものの、コンピューターへの負担が大きくなるのであれば、クライアントOSはNTFS（の拡張版）、
サーバーOSはReFSを実装という切り分けを行うかも知れない。いずれにせよ2012年早期に登場すると言われているパブリックベータ版が楽しみである。
734:login:Penguin
11/12/08 01:33:25.02 /LfTVLJ+
あれ
確かXPでも1セクタオーバー512バイトは扱えるだろ
セクタ数制限で容量的に困るRAIDカードなんかで使ってる
735:login:Penguin
11/12/09 00:25:34.84 JrMUTgx6
curlftpfs上のファイルを直接ls --fullで見ると秒が切り捨てられて00なのに
cp -pでローカルに持ってきてls --fullすると秒がちゃんと入ってる。
これってリモートのftpサーバのせいなのか、curlftpfsの仕様?
rsyncの際不便なんですが。
736:login:Penguin
11/12/09 01:16:27.95 reb/8RwY
btrfsやZFSの良いところを取り込んだext5を開発するべき
737:login:Penguin
11/12/09 02:11:03.27 XoF5awup
カーネルよりも設計と実装が大変と言われているからなぁ
738:login:Penguin
11/12/10 15:44:19.27 GxMP8l4K
ファイルシステムはもうちょっと頑張って進化して欲しいけど
zfsもbtrfsもOracleが持ってる現状ではあんまし期待できないのかなあ。
739:login:Penguin
11/12/10 17:47:38.71 +Zd/Y1Hz
LibreOfficeの様にZFSだけforkしてくれれば、ちょっとは期待が持てるのでは。。。
740:login:Penguin
11/12/10 19:25:41.83 BC9sxQ74
nilfsはどうなったの？
741:login:Penguin
11/12/11 09:23:40.44 uV0vx7mh
e2fsprogsが16TB以上をサポートしていたようだが誰か試した？
742:login:Penguin
11/12/12 23:04:38.34 n5/OWK/A
ファイルシステムなんてそのうち必要なくなるよ
DRAMがこのままデカくなっていってディスクやSSDにデータを保存することもなくなる
743:login:Penguin
11/12/12 23:08:17.50 0mUMbQnC
名前からデータを見付ける機構は必要でしょう
744:login:Penguin
11/12/12 23:19:04.54 XCN5sCo4
xfs最強伝説は終わらなさそうだな。
例えSGIが破産したとしても、ボラクルに買われない限りは。
745:login:Penguin
11/12/12 23:27:02.14 nKxOoQl2
>>742
一度電源を入れたらもうリブートもできないシステムを誰が使うというのだろう…
まあ、メモリ容量はクライアントでも近いうちに64GBに達しそうではあるけど。128GBもそんな遠くないかな?
746:login:Penguin
11/12/13 00:34:42.48 toGkaAkU
今のSSDは10年ぐらい前のメインメモリより速いんだよなあと思うときはある。
747:login:Penguin
11/12/13 02:54:08.43 Io8luUyb
>>742
不揮発高速高集積メモリの開発競争が進んでいるのに
DRAMと言ってしまうあたりがしょぼいｗ
>>746
ランダムにちまちま書き換えたら遅くてすぐ死ぬんじゃね？
748:login:Penguin
11/12/13 22:23:49.03 20NbfBPy
なんでこのスレではOracle嫌われてるのん？
749:login:Penguin
11/12/13 22:24:45.43 wFnRLfru
Oracle嫌わない奴がいないわけ無いだろ
オープンソース界隈の人間じゃ
750:login:Penguin
11/12/13 22:24:50.38 cWcmPqaW
>>748
このスレだけだとでも？
751:login:Penguin
11/12/13 22:33:20.68 20NbfBPy
自分の製品に対抗するオープンソースなプロジェクトを買い取る。
→そのままプロジェクトの開発は進めずに飼い殺し。
みたいな認識であってる？
ZFSとかJavaとかMySQLとかOpenOfficeとかVirtualBoxとか。
どうやったらオープンソースプロジェクトを買い取れるのかはよく分からないけど。
752:login:Penguin
11/12/13 22:37:23.00 zOiZlyhu
>>749
オープンソース界隈だけじゃないけどなｗ
753:login:Penguin
11/12/13 22:47:30.25 dnyE+I8a
>>751
違う。javaの権利が欲しくてsunを買収。
sun主導のその他のOSSプロジェクトもついてきちゃったってだけ。
754:login:Penguin
11/12/13 22:52:32.11 20NbfBPy
>>753
うーん。それだけ聞くと別にOracleを嫌う理由はないように思えるんだけど。企業の買収なんて割と日常茶飯事だし。
ググってみるといろいろOracleは訴訟してるみたいだけど何で訴訟してるのかイマイチつかめない。
755:login:Penguin
11/12/13 22:53:34.94 pxquyg+d
BerkeleyDBのSleepyCat、MySQLのMySQL ABとかいろんな前科があるな
756:login:Penguin
11/12/13 23:09:57.76 zBISs2X0
Oracleのインストーラーが糞
757:login:Penguin
11/12/13 23:10:25.55 20NbfBPy
>>753
ああ、Javaを欲しくてSun買ったからZFSとかはぶっちゃけ要らない→あんましZFSに力入れない
って感じなのかな。
まあこれ以上はスレチだと思うので適当な所で話打ち切っちゃって下さい。
758:login:Penguin
11/12/13 23:14:39.31 oR7fSaA2
SleepyCat買収騒ぎでボラクル嫌いになった
Java関連を掌握したいが為にSun買収しやがった件でボラクルアレルギーが発症した
759:login:Penguin
11/12/13 23:33:17.54 TXv5bXud
イメージだけで語れば
Oracleは顧客優先、ビジネス優先
RedHatはコミュニティ優先
Novellはその中間
無料で美味しい思いしたい俺達と
OSS開発に参加して名を挙げたい開発者と
自社の一部に組み込んで美味しい所だけ利用したい企業と
金出してサポート買ってる企業の意向や担当の苦悩。
データベースは直接関係無いかもしれないがOSSを利用して組み込みやってる開発者の右往左往ぶりとか。
カオスだよなw
Linuxっていろんな意味で楽しい。
Oracle叩きが加速してるがNovellも相当やってきた。
でも還元はしてる。Oracleはしてない。それが大きな違いかもね。
760:login:Penguin
11/12/13 23:43:29.62 AXEOcTw9
ギークvsスーツ
761:login:Penguin
11/12/14 13:05:32.03 v5c6EVpH
しかしLinuxにはスーツの最右翼、IBMもかなりContributeしている訳で。
まあ直接このスレに関係あるネタはあんまりないかも知れないけど。
762: 忍法帖【Lv=40,xxxPT】
11/12/14 21:12:59.87 /t+ItTFc
IBMがLinuxに貢献したのはSolaris潰しのためだろうが
AIXでSolaris潰しに失敗したからLinuxを当て馬にしただけのこと
763:login:Penguin
11/12/14 21:43:10.82 dV1Px6wl
だったら全力でSunの買収に取り組んだはずだ。
みすみすOracleに出し抜かれるほど落ちぶれちゃいない。
764: 忍法帖【Lv=40,xxxPT】
11/12/14 21:46:43.22 /t+ItTFc
潰す=買収というわけではないのだが…そう読めたか？
Transitiveの買収とかSun買うつもりだったのかなという感じはあったが
結局最後は値切ったのが仇になってOracleに転んだけど
765:login:Penguin
11/12/14 21:51:31.22 7bta9K3/
>>763
SUNをただのハードウェア会社と見ていたので、取り扱うアーキテクチャのラインナップが増えるので手を挙げなかった
と、思うけど…
(IBMは過去に対MS用決戦兵器としてロータスを買収しているし)
766: 忍法帖【Lv=40,xxxPT】
11/12/14 21:54:27.00 /t+ItTFc
それはありえない
歴史的にはOSFやEclipseの一件からSOAPの標準化まで
広範囲にSunに対して嫌がらせしていたのがIBM
Sunの首脳陣もそれを分かっていたからIBMを人類の敵と呼んでいた
なんでそう呼んだかはIBMとナチとの関係をぐぐって貰ってもいい
767:login:Penguin
11/12/14 22:02:03.50 dV1Px6wl
ふむふむ。
でもなぁ、SunもJava移植の件でかなり悪どいイメージが残ってるからなぁ。
もちろんSunのおかげでというのも沢山あるんだけど。
768:login:Penguin
11/12/14 22:02:28.60 7bta9K3/
>>766
え!?なんで!?
ライバル関係にある会社を「褒め称える会社」が存在するだろうか？
MSとIBMが蜜月関係に終止符を打った直後から「OS/2とWindows」を罵倒しあう関係になったし
769:login:Penguin
11/12/14 22:04:23.33 nz/wrtsy
おまえらスレ違い。雑談スレへ行け
770:login:Penguin
11/12/14 22:18:02.84 nR5NTs7o
>>740
不思議な旅してんじゃないの？ﾔﾀﾞﾈｰ
771:login:Penguin
11/12/14 22:32:55.32 7bta9K3/
>>769
仕方がないよ。『SSDに最適化されたファイルシステムの開始』みたいな発表が無いと。。。
(OS板のVBoxスレなんて『Google検索結果発表」スレと化しているし)
>>770
歳バレしちゃいますよ～ ww
772: 忍法帖【Lv=40,xxxPT】
11/12/15 00:00:45.17 dKh6viwg
>>768
>>765の
>SUNをただのハードウェア会社と見ていたので
に対するレスが>>768
IBMとSunはソフトウェア(の標準化)で常にライバル関係にあったということ
>>769
だよねー
>>771
AHCI+trimではダメっすか？
つかこのスレでtrim対応ってあんまり話題になってないのかね？
と強引に戻してみるテスト
773: 忍法帖【Lv=40,xxxPT】
11/12/15 00:01:26.34 dKh6viwg
>>765の
>SUNをただのハードウェア会社と見ていたので
に対するレスが>>766
の間違い
スマネ
774:login:Penguin
11/12/15 05:20:25.88 7B/m777f
OS作る上でで一番大変なのがファイルシステムの設計らしいな
（WinFSはポシャったが）
775:login:Penguin
11/12/15 06:23:15.56 gi7qHsCQ
>>772
>IBMとSunはソフトウェア(の標準化)で常にライバル関係にあったということ
ハードウェア、ソフトが無ければただの箱って理由であえて割愛した
当然、自社のハードを積極的に売り込む為には、囲い込みが必要でしょ？
(IBM ATがオープン戦略をとって、売り上げが激減したように。そしてappleもクローズド戦略に戻ったしね)
>AHCI+trimではダメっすか？
>つかこのスレでtrim対応ってあんまり話題になってないのかね？
それってファイルシステムではなくOS側の話の様な気がする
(debian使いだが、カーネルの関係でbtrfsやext4はtrimに対応しているが、大好きなXFSがtrimに対応していないのが少し悲しい)
776:login:Penguin
11/12/15 08:11:28.97 EA6CrWAr
Appleは別にクローズド戦略に戻ってねーぞ
いまだにDarwinは続けてるし、Clang作ってるし、
最近だと現役バリバリのコーデックをオープンソースにしたし
むしろなぜコードをそこまで公開するのか戦略が全然見えないレベル
Sun亡き今、Googleに次いでオープンソースの活動量が多いんじゃねーかな