maiaの日記： 日立GSTが面記録密度345ギガビット/平方インチを実証 112
日記 by
maia
日立GSTが面記録密度345ギガビット/平方インチを実証したと発表した（プレスリリース）。2009年に製品化できるという。4枚構成の3.5型で2TB、2枚構成の2.5型で400GB、2枚構成の1.8型で200GBを実現できるという。なお3.5型1TBは2007年上半期に製品化の予定。また2016年には平方インチあたり4テラビットの記録密度で25TBの3.5型HDD、さらなる将来には平方インチあたり100テラビットの記録密度で650TBの3.5型HDDが登場するだろうと予測している。
無駄なあがきを (スコア:3, おもしろおかしい)
それに2ＴＢなんて何に使うの。
Re:無駄なあがきを (スコア:4, おもしろおかしい)
｛;;;;;;ゝ T辷iﾌ i f'辷jァ !i;;;;; >それに2ＴＢなんて何に使うの。
ヾ;;;ﾊ ﾉ .::!lﾘ;;rﾞ
`Z;i 〈.,_..,. ﾉ;;;;;;;;> そんなふうに考えていた時期が
,;ぇﾊ、 ､_,.ｰ-､_',. ,ｆﾞ: Y;;f 俺にもありました
~''戈ヽ ｀二´ r'´:::. `!
Re:無駄なあがきを (スコア:4, すばらしい洞察)
メモリが2～4KBの頃、ボードマイコンの時代、「64KBなんて何に使うの？」
メモリが32～64KBの頃、Z80全盛期、「1MBなんて何に使うの？(8086)」
メモリが1MB程度の頃、8086時代、「16MBなんて何に使うの？(80286プロテクトモード、68K系)」
メモリが16MB程度の頃、DOS/Vが出てきた頃、「4GBなんて何に使うの？(32bitアドレス)」
「4GB空間あればもう足りるだろう」→「今のOSって2～3GBしか使えないの？」
「64bitあれば…」←現在
40MBのHDDが標準だった98時代、1GBのHDDなんて何に使うかわからんかった。
今1GBなんて誤差扱い。
そのうち2TBが今の2MB程度の扱いになる時代も来ます。
Flashは根本に書き換え回数(寿命)という問題も抱えているし、全てを置き換えようなんて考えは間違い。
適材適所でしょ。こういうモノって。
OSなどのデータはFlashでも良いけど、ノンリニアの画像編集なんかはHDDでやった方が良さそう。
Re:無駄なあがきを (スコア:2, 参考になる)
エンタープライズ用途で考えればディスク容量はいくらあっても良い
最近空き容量一定の法則を痛感してます
Re:無駄なあがきを (スコア:2, すばらしい洞察)
Re:無駄なあがきを (スコア:1, すばらしい洞察)
Re:無駄なあがきを (スコア:2, おもしろおかしい)
Re:無駄なあがきを(オフトピ) (スコア:1)
それとも120MB(今となってはずいぶん小さい…)
Re:無駄なあがきを (スコア:2, おもしろおかしい)
週に約80本の番組をSP画質で録画していくと40GB。
すると2TBなんてたかが1年分にしかならない。
はい、そこ!
いつ見る時間があるかなんて質問禁止!!
Re:無駄なあがきを (スコア:1)
「老後の楽しみ」って答えていたよ。
Re:無駄なあがきを (スコア:1)
映像は馬鹿みたいな容量になってきてるし、
デジカメ画像ですらギガとかの時代になってきてる。
問題は転送の時間かなぁ。
数テラのバックアップをネット越し（学内ネットとか）で転送しようとしたら、あまりにも時間がかかってHDDを郵送したとかいう話を聞いた。
HDDの読み取り時間がネックになると、いよいよフラッシュメモリーなのかな。
Re:桁が違う (スコア:1)
フラッシュメモリーは1年で容量が倍になるらしい。
2011にはiPod nanoが250GB位にはなってるんじゃない。
ファンの法則 (スコア:1)
ためしに (スコア:1)
容量を、10G/hと80年で計算すると
10*80*365*24=7008000GB = 7008TB = 7.008PB
20年後にはなんとかなりそう
見るのにも80年かかる……
読み取り速度（人間側）の向上が望まれます
何に使おうか (スコア:2, おもしろおかしい)
お約束なのでAC
ハードが進歩してるのはいいとして (スコア:3, 興味深い)
FAT32の論理限界が8TB（標準のセクタサイズだと2TB）
NTFSの推奨最大サイズが2TB、論理限界が16EB、
EXT3の論理限界が32TB
ReiserFSの論理限界が16TB
HFS+の論理限界が8EB
Win9x系は125GBまで（FAT32）
WinNT系は256TBまで（NTFS）
Mac OS X 10.3以降が16TBまで（HFS+）
たとえばNT系の256TB制限は、クラスタサイズの上限(64KB)*クラスタ数の上限(2^32クラスタ）なので、64ビット化によって突破可能っぽいのですが。
# そろそろFAT32に代わる汎用FSが出てきてくれないと、
# 複数のOSから利用したい場合の選択肢が・・・
じゃあ、当分考えないでいいようにZFSで (スコア:3, 興味深い)
論理限界が140737488355328YB
になりますよ。
OpenSolarisに含まれているのでどうやって
実装したら良いかもわかりますし。
Re:ハードが進歩してるのはいいとして (スコア:2, すばらしい洞察)
Re:ハードが進歩してるのはいいとして (スコア:3, 参考になる)
SCSIには「CHS」なんて概念はありません。規格が出来た当初から、
「CHS=シリンダ番号・ヘッド番号・セクタ番号」といった物理的構造に密接したアクセス方法ではなく、
「LBA=通しのセクタ番号」でアクセスするようになってます。
で、現状ではLBAを32bitで指定しているので、
SCSI接続では2TB以上の領域をアクセスする方法が無い=SCSIドライブは2TBが上限なのです。
ただ、SCSI のコマンドについては、
初期の規格では read/writeコマンドで指定できる LBA が21bit(1GBまで)だったのを、
後からread(10)/write(10)というコマンドを追加して32bitを指定できるようにしたという経緯があるので、
2TBじゃ全然足りないってことになったら、同じように
「アドレスを64bit指定可能なread(14)/write(14)を新設」みたいなことで対応できるんじゃないでしょうか。
そのときは、
「read14/write14 対応ホストに接続した時は2TB超を使える」
「read10/write10まで対応のホストに接続したときは2TBのドライブに見える」
なんてことになるかと。
ってとこまで書いて気づいたのですが、SCSI では「1セクタが512バイト」なんて決めうちはしてないので、
物理セクタをいくつかまとめた論理セクタなんてのを導入すれば、現状のコマンドのままでも最大容量は増やせますね。
ブロックサイズの指定は32bitなので最大4GB、ブロック数は32bitなので合計で64bit=16EBまでいけます。
ブロックサイズが4GBってことは4GB単位でのアクセスになるので実用性は低そうですが…
Re:ハードが進歩してるのはいいとして (スコア:2, 参考になる)
ufsだと2TB
ufs2が2^73バイト=8ZBまでだそうです。
Large data storage in FreeBSD [freebsd.org]より。
Wikipediaにも比較表があります [wikipedia.org]。
さすがに64bitになれば、しばらく上限は無視できそうですね。
OS independent なのは確かに必要だと思います。
でも FAT だと、あまり大きなパーティションには向かないと思ってます...
Re:何に使おうか (スコア:1, 参考になる)
体力あるのか (スコア:2, 興味深い)
大丈夫なんですかね、いろんな意味で。
Re:体力あるのか (スコア:1, 興味深い)
1.8インチ以下の容量と体積じゃ半導体メモリにあっさり食われるのが目に見えてたってのに･･･。
それとiVDR、いろんな意味で中途半端だし。
冒険もいいけど、冒険に資金回しすぎてて本丸の3.5インチ疎かにしてたのも不味かったね。
3.5インチも他社に比べ後手後手に回ってるし。
流石にマズイって気づいて挽回策探してるんだろうけども。
大容量化と信頼性を上げることを両立させてく、本筋のところを疎かにしちゃいけないよなぁ。
Re:体力あるのか (スコア:2, 興味深い)
その大きな原因に日立GSTがあるということに備えた株価対策でしょ？
一般にHDDの高密度記録技術の発表は、
磁気記録関係の学会であるIntermag/MMMでの発表の事前宣伝としてそれらの直前にあるものだし、
なによりも今回の発表には何ら技術的な裏付け資料が伴ってない。
テラワロス (Yahoo! ファイナンス) [yahoo.co.jp]
Re:体力あるのか (スコア:1, おもしろおかしい)
Re:体力あるのか (スコア:1)
CPUやビデオカードは性能に比例、指数的に価格が上昇しますよね。
それに対し、HDDは容量に反比例してビット単価は落ちていきます。
現在はどのHDDメーカも薄利多売のようなので、
この構図を変える必要があります。
それが通用しないからIBMも手放したのだとは思いますが。
もっともっと大容量を安価にお願いしたい。 (スコア:2, 興味深い)
テラの時代が来て、やっと手持ちのビデオをすべてPCに取り込めそうです。
バックアップもしなくてはいけませんので、同じ容量のHDDが何台もほしいので、1テラ1万に早くならないかと思っています。
Re:もっともっと大容量を安価にお願いしたい。 (スコア:1)
今のところ、取り込む元になるものが無いですが、たくさん貯めた、SF小説を簡単に取り込む専用スキャナーが出ないかなとは思っています。
今のスキャナーは、本を開いて伏せて置かないとだめですので、本を普通に見開きで置いて、上からスキャンできると作業がものすごく楽になります。
そうなれば、10テラ1万に早くならないかなと思うでしょう。
Re:もっともっと大容量を安価にお願いしたい。 (スコア:1)
非破壊にこだわらなければ、5万円ぐらいで [fujitsu.com] ありますよ [canon.jp]
あとは自作するとか [geocities.jp]
でも、小説ぐらいじゃスキャンしても大した容量になりませんよ。
文庫だと、150dpiでスキャンして1冊40MBってとこです。
1TBで25,000冊。
600dpiでスキャンしても640MB、10テラバイトには15,000冊入ります。
容量よりも、壊れにくいHDDで勝負して (スコア:1, 興味深い)
容量より壊れにくい方向で技術を競争して欲しいな。
現在、300GBのHDDを使っているのだが、このサイズになると
HDDぐらいしか実質的なバックアップメディアが存在しない。
どのみち駆動部分があるハードはいらないと思うので、
HDDにはなるべく早い時期に退場してもらうのがいいな。
動くものが減ればノートもバッテリが持つようになるし。
Re:容量よりも、壊れにくいHDDで勝負して (スコア:2, 興味深い)
結局、「小さくて壊れにくい」より「大きくて壊れやすい」方が、需要があるんだろうね。
「転んでも壊れないバイクを作るべきだ」と同じで、作れるんだけど、大きくて重くなるから、走れない・曲がれない・止まらない・値段も高くなる・運動性能が下がって事故り易くなる。と、本末転倒な結果になってしまうんじゃないかと思われます。
事態は際限なく悪化する。
Re:容量よりも、壊れにくいHDDで勝負して (スコア:1, すばらしい洞察)
HDDも、サーバ用は信頼性を第一に設計したものが多かったけど、冗長構造にしてどんどん使い捨てるのがトレンドになってきてるだけ。「作ろうとすれば作れ」て「本末転倒な結果」にもならないけど、流行りではない、ということ。
Re:容量よりも、壊れにくいHDDで勝負して (スコア:1)
基本的なコンポーネントは共通だけど、各種の保護機能(鉄パイプのガードなど)を追加した結果、高額になるけど壊れにくくなっているのが教習所用のバイクです。
教習所のバイクは、その性質上コケてナンボなので、修理する手間と費用が、車両本体の追加費用を上回れば元が取れます。理屈の上では冗長化(コケても大丈夫なようにスペアのマシンを大量に確保する)という選択肢もありますが、維持・管理の面から現実的ではありません。
HDDでもアベイラビリティー強化モデル [ascii24.com]のように、単体の信頼性を上げることは不可能では無いと思います。でも、RAIDの方が冗長化だけでなくホットスワップなど単体構成では不可能なメリットも生まれるので、結果として主流となっているということではないかと。
Re:容量よりも、壊れにくいHDDで勝負して (スコア:1)
壊れない物を作るより、壊れても大丈夫な方法を考える方が安上がり。
もちろん、壊れまくるのは論外なので、ほどほどに壊れずにそこそこ大容量が求められるでしょうね。
大容量で、壊れにくいHDD (スコア:1)
欲しくない？
それと
据え置き、サーバとかなら
駆動系がどうのより容量とかのが
重要そう
Re:容量よりも、壊れにくいHDDで勝負して (スコア:1)
HDD単体でRAIDって意味無いんかなあ。RAID1なら作れそうだが。
Re:容量よりも、壊れにくいHDDで勝負して (スコア:1)
Re:容量よりも、壊れにくいHDDで勝負して (スコア:1)
そりゃ (スコア:1)
今の関心事というとフラッシュメモリの密度上昇と比べてどっちが早くなるかだと思う。
マイクロドライブは既に大概に於いて競争力を失いつつあるので
次は1.8inchとの戦いがどうなるかとか、ノートパソコンが現在の主流である中3.5inchのアプリケーションはどんな物であるとか(暫くはHD映像の録画ということになりそうだけど)が大事じゃないかと
開発スピード (スコア:1, 参考になる)
→新iPodを支えるフラッシュメモリの進化 [impress.co.jp]
(Samsungのフラッシュ開発ロードマップあり)
2008年でやっとiPod nano 32GBが出る程度の速さです。
(他も推して知るべしという感じかと)
1ビットあたり (スコア:1, 興味深い)
正方形だとすれば、42ナノメートル × 42ナノメートル [google.co.jp]の領域で1ビット記録してるのか。
＃ あれ？
もしかして、700GBくらいが物理的限界？
ブーッ，間違い (スコア:4, 参考になる)
平方フェムトメートル = (fm)^2 = f^2 m^2 = 10^-30 m^2 です(『平方』は『フェムトメートル』にかかっている)．
従って，
1.82x10^-15 m^2 = (1.82x10^3)x^10^-18 m^2 = 1.8x10^3 nm^2
で1800平方ナノメートルですね．
42 nm x 42 nm 領域ってのはあってます．
原子１つで1オングストローム四方 = 0.1 nm四方とすると，420原子 x 420原子 = 18万原子の領域になりますね．
Re:ブーッ，間違い (スコア:1)
彷彿とさせるのですが・・・
キロ、メガ、ギガ、テラ、ペタ、エクサ、ゼッタ、ヨッタ (スコア:1, 参考になる)
テラまでだと思ってたけど、ペタの出番はありそうですね。
さすがに、NTFSの上限値16EBはないかな？甘い？
--
フォーマットに時間かかりそうだから、最初からフォーマットしといてくれ。
iPodやType Uにも足らない (スコア:1)
Type Uをビューワーとして持ち歩いていると、時々
「これに300GBあればなぁ」
と思っている私には全然足りません。
同様に、HDDタイプのiPod持っていて映像見ている人（の何割か）もそう思っているかも
----------------------------------------
とゅー びー おあ のっと とぅー びー ゲノム読めても理解できない
Re:読みにくい (スコア:3, すばらしい洞察)
Re:読みにくい (スコア:2, すばらしい洞察)
Re:読みにくい(これも:-1,オフトピック ) (スコア:1, 参考になる)
普段から読みやすいというか理解しやすい文章を書くのは、
とっても大事だと思うよ。
脳内補完を日常的に行っていると、
少なからずすれ違いが発生するからね。
文章のコミュニケーションの場合、
何をするにしてもタイムラグが発生するから(特に/.jpは)、
一発で理解してもらう文章はさらに重要だと思うな。
Re:読みにくい(これも:-1,オフトピック ) (スコア:1)
>その前に君は日本語の鍛錬が必要なようだｗ
脳内保管が(比較的)要らなくなるニュースだ、と暗に言いたいのですよきっと。
この技術の応用範囲 (スコア:1)
ディスケットドライブの飛躍的大容量化→なわけない。
Jazドライブの飛躍的大容量化→なはずも無い。