パスワードを忘れた? アカウント作成
176476 story
ストレージ

Western Digitalがユーザー使用可能領域を7-11%拡大させたHDD製品を発売 59

ストーリー by hayakawa
今後のスタンダードとなりうるか 部門より

MASA.H 曰く、

マイコミジャーナルAKIBA PC Hotline!によれば、Western Digitalがユーザー使用可能領域を拡大させることのできる物理フォーマットである、「Advanced Format Technology(AFT)」を搭載したHDDを発売した模様。

このAFTは、物理セクタサイズをこれまでの伝統的に使われてきた512bytesから4096bytesに増やすことで、リードインとセクタギャップの占める領域を減らし、その分をECC領域とユーザー領域の拡大に割り当てる。セクタあたりのECCが増えたため、エラー訂正率も拡大したとのこと。ただし、Windows XPで使う際には注意が必要である。Windows XPは512bytes以外のセクタサイズを想定しておらず、ドライブインターフェイス側でエミュレーションの必要がある模様。よってフルパフォーマンスを発揮させるためには、専用のユーティリティーを用いるかジャンパピンで設定しなければいけない。Vista以降は対応しているようだ

また、

HDDの業界団体であるIDEMA(International Disk Drive Equipment and Materials Association)でも、将来のストレージの大容量化に向け4,096バイトセクタを「BigSector」として提唱しており、2011年に移行することを発表している。

とのこと。ただITproの過去の記事を振り返るととだいぶスケジュールが遅延している模様。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 昔話 (スコア:5, 興味深い)

    by saitoh (10803) on 2009年12月20日 16時34分 (#1691724)
    そういえば、HDDのセクタサイズが「512固定が当然」になってから長いですね。 SMDとかESDI規格が現役だった頃は、ジャンパーでセクタサイズ256/512/1024/2048から選ぶなんてドライブはごく普通にありましたが。

    512が主流になったのは(昔の)UNIXが512決め打ちだったからじゃなかったかなぁ。

    • NeXTstepでは (スコア:2, 興味深い)

      by nq (16642) on 2009年12月21日 13時58分 (#1692115) 日記

      セクター長を1024に変えて容量を増やすのは、常套手段でしたが、そのためには、/etc/disktab を手で書かなくてはいけないので、ちょっと面倒でした。この話題、まだ検索にひっかかりますね。

      http://www.nextcube.org/board/bbs.php3?board=doc&line=subject&... [nextcube.org]

      ひょっとしたら当時生まれていなかった人も読んでいるでしょうから蛇足を加えると、NeXTstepは、現在の MacOS X の源流の Unix系 OS です。今の Mac ではセクタ長を選べるのでしょうか?

      親コメント
    • Re:昔話 (スコア:1, 興味深い)

      by Anonymous Coward on 2009年12月20日 20時11分 (#1691830)
      ですね、OSによって決め打ちされていて、セクタサイズを変更して出荷していました。
      ソフトセクタ式HDDでセクタサイズ変更後に容量が結構増えていたと記憶しています。
      親コメント
  • 思わずPC-9801のMS-DOS FDフォーマットを思い出しました。

    MS-DOSで使われていた5インチ2HDのフロッピーディスクは、
    PC-9801: 1024バイト/セクタ×8セクタ/トラック×77トラック/面×両面=1232KiB
    PC互換系: 512バイト/セクタ×15セクタ/トラック×80トラック/面×両面=1200KiB(通称2HC)
    の2種類があったのでした。

    1024バイトセクタを採用することで、512バイトセクタと比べて、1トラックあたりの容量が7.5KiB→8KiBと約7%増えています。

    (そのかわり、PC-9801で使われていた方は、8インチ2D規格を5.25インチに持ち込んだため77トラックしかないのに対し、
    PC互換機系の方は、それまでの5.25インチ規格と同じ80トラックを採用したため、結果的に容量はほとんど同じになっちゃってますけど…)

    で、当時からPC互換機系のMS-DOSはセクタサイズが512バイト決めうちになっていたため、
    そのままではPC-9801の2HDフロッピーは読み書きすることができなかったので、データ交換が面倒だったのですが、
    PC-9801用の2HDを読み書きできるAT互換機DOS用ドライバが出てきて世界が一変したのでした。

    そのドライバは、内部で1024バイトセクタと512バイトセクタの変換処理を行うため、DOSからは512バイトセクタのメディアに見えるようになっていたのですが、
    DOSから見て奇数セクタ数の書き込みを行った場合、メディア上では1024バイトセクタの半分だけ書き込む必要があります。
    そういう場合は、一端1セクタ1024バイトを読み込んでから、半分の512バイトを書き換えたデータを作って、書き込みを行う、という処理の流れになるため、かなりパフォーマンスが落ちたのでした…

    …というオサーンほいほいな思い出話ですが、
    というわけで、OSがネイティブに対応していないと、パフォーマンス的に悲しいことになるんじゃないかと心配してしまいます。
    まあ、最近はドライブ内部にキャッシュがあるから、それほどひどいことにはならないと思いますが…

    ていうか、ドライブが内部で変換してくれればいいじゃん、とか思ってしまいますね。

    #MacOSXやUN*X系OSの対応はどうなんだろう?

    • > 思わずPC-9801のMS-DOS FDフォーマットを思い出しました。

      TRS-80 Model I [trs-80.org] に CP/M を移植したときに、そういうオレサマフォーマットして悦に入っていたことを思い出しちまったよ。詳細は忘れちまったけどね。

      #あのころは、たかが 512 byte が、なんて貴重だったんだろう。
      #いや、128 byte と 256 byte だったかもしれない。

      親コメント
      • by Anonymous Coward
        CP/Mは論理セクタサイズ128バイト、8インチ単密度の物理セクタも128バイト、5インチは256バイトかな。
        CP/M86になっても同様で、MS-DOSのほうがディスクは圧倒的に高速でした。(DOSのほうがファイルシステム全般的に優れていましたが)
    • by Anonymous Coward

      全部じゃないけど元記事にある程度の解説が、、、

      >互換性を維持するためにAdvanced Format Technologyでは、ドラ
      >イブインターフェイスにおいて4,096バイトの物理セクタを512バ
      >イトの論理セクタに組み立てるエミュレーションを行う。

      >Advanced Formatは、Windows 7/ Vista、Mac OS X Tiger/ Leopa
      >rd/ Snow Leopardなど、新しい世代のOSの機能にHDDを最適化さ
      >せる技術である

    • by Anonymous Coward
      フォーマットといえば、2Dでは1024バイト * 5セクタを「3-5フォーマット」なんて言ってたけど、なかには

      1024バイト * 5セクタ + 256バイト * 2セクタ = 5.5kB

      なんてのもありました。
      PC88は標準256バイト * 16 = 4kBだったから、137.5%。
  • この辺を読んでいると垂直磁気記録方式はDTRやBPMと言った技術と組み合わせることでまだ当分イケそうですね。
    【PC Watch】 DISKCON JAPAN 2009レポート ~HDDの記録密度向上ペースを鈍らせないために [impress.co.jp]
    日本HDD協会2008年10月セミナーレポート [impress.co.jp]
    東芝:プレスリリース (2007.09.06) [toshiba.co.jp]

    --
    屍体メモ [windy.cx]
    • by Anonymous Coward
      HDDの記録密度の限界より半導体の製造プロセス微細化の限界の方が先に来そうですね。
      SSDがHDDを抜いて主役になる日は来ないんでしょうね。
      • by Anonymous Coward

        意外でしたよね。
        半導体メモリはあと2~3回しか密度倍加できないんでしたっけ。

  • by Anonymous Coward on 2009年12月20日 17時37分 (#1691758)
    なつかしの 3.5inch MO でも同様のことがありました。
    540MB と 640MB ディスクは記録密度がほぼ同一で、
    セクターサイズの 512B/2048B の違いでこれだけの容量差を
    稼いでました。
    (CD に対抗するためにどうしても 640MB にしたかったらしい)

    セクターマークそのものや、セクターマークを「読んで」から
    データ「書き込み」に切り替えるなどの時間を稼ぐための
    マージンとしてのギャップや、再生信号と同期をとるための
    ヘッダーパターンを書き込む領域は 1/4 に節約できますね。

    ECCデータ長はエラー訂正力を同一にするためにセクターサイズに
    比例して増えるし、回転ムラを吸収するためのギャップ長は
    セクター長が長くなるので相対的に変わらなかったと思います。
    • 採用前のあれたまでは
      >それにしても、いままでもMOは2048bytesセクタを使っていたような気がするのだが、どう対応していたのだろう。
      と言及しておいたのですが、なぜか採用されるときに消されました。
      そんなにMOはマイナーなのか。
      親コメント
      • by Anonymous Coward
        当時 DOS では 2048b/sect用のドライバを使う必要があった。

        win95(98/Me) は何故かそのまま使えた。ただし OS 起動時にメディアが
        すでにあると そのセクターサイズがどこかに残り、異なるセクター
        サイズのメディアに差し替えると問題を起こした。

        winNT は忘れた。win2000 は普通に使えたように思う。

        FreeBSD などは日本の有志が対応していたように思う。

        1GB の iPodShuffle を買ったときに調べたらこれは 2048b/sect だった。ブートメディアに使えないじゃん!とがっかりした。

        それから後の最近の事情はよくわかりません。
        • by Anonymous Coward on 2009年12月20日 19時53分 (#1691826)

          当時ドライバを書いていましたが、
          DOS では 2048 セクタのメディアは、
          512 セクタに見えるように変換していましたね。

          Windows NT では認識しませんでしたが、
          Windows 2000 からは、こっそり対応してました。

          当時の Linux は 2048 メディアを差し込むと、
          ハングアップしてましたね。

          ずいぶん懐かしい話ですが、今頃こんな話がでてくるとは・・・

          親コメント
          • by munemasa (4544) on 2009年12月21日 15時12分 (#1692161) 日記

            Linux 2.0.38あたりを使っていたときに
            2048バイト/セクタパッチ当ててMO使ってましたなぁ…。

            親コメント
          • by kei100 (5854) on 2009年12月21日 23時33分 (#1692424)

            NTも一応認識はします。
            ただ、起動時にMOをドライブに刺してたり、540MB以下と640MB以上を混在したり、640MBだとエクスプローラーからフォーマットできなかったりとか。
            # 使えないのとほぼ同義なのでSCSIカードやMO等に付属のドライバを組み込むのですけどね。

            それとは別にNTFSフォーマットしたりするとディスクを抜けなくなる等の事象が発生したりします。
            こちらはポリシーで設定可能。とはいえ普通はFATでしょうけど。
            # GigaMOドライブを高速MOとして繋ぐこともあるけど今やUSBスティックの方が全てにおいて便利よね。メディア自体の耐久性以外は。

            親コメント
  • こんなこともあろうかと!
    Vistaから512Byte超のセクタサイズに対応できるようにしておいた・・・のかと思ったら、
    リンク先読むと、予定されていたことだったみたいですね。

    • by Anonymous Coward

      基本的に最近のMSは「こんなこともあろうかと」で対応はしません。下手な「対応」はセキュリティホールの温床になるだけですから。フラッシュメモリの大幅な値下がりでUSBメモリが一気に普及したけど「こんなこともあろうかと」CD/DVD以外からのオートランにも対応してたらConflicker大流行でござるの巻とか。

  • コレ使うと逆に細かいファイルたくさん格納してる人だと
    セクタ/クラスタ端数領域の無駄が増えて結局損してたりしませんかね。
    細かいエロ画像とかエロ画像とかエロ画像とかたくさん持ってる人とか。
    あと不良セクタのダメージが増えたり。

    #そんなの誤差だとは思いますが、7-11%増える程度も誤差のような、
    #と言いたくなる昨今のHDD価格にビックリ。
    • 512bytes以上4096bytes以下のサイズ差が問題になるエロ画像なんて存在するの?

      画像ファイルなんて今時なら数MBytesなんて当り前なのかと想像してました。
      いつの世もリソースを一番食うのはエロだよね。

      親コメント
    • by Anonymous Coward
      細かい画像が大量にあって気になるなら無圧縮ZIPで格納するといいかも。
    • by Anonymous Coward

      もともとOSは8セクタ=1クラスタで管理してたので、違いは出ません。

      • by Anonymous Coward

        「8セクタ=1クラスタ」(=4096bytes)はNTFSでの規定値ですね。
        (厳密には16TB以下のストレージでの規定値ですが)
        FAT32だと1クラスタが64セクタ(=32KiB)なんてこともザラでした。
        http://support.microsoft.com/kb/140365/ja [microsoft.com]

        どちらにしろ,大半のHDDは4096bytesの倍数が最小の管理単位でフォーマットされますから,
        1セクタが512bytesから4096bytesになっても,容量の無駄は無い筈です。

    • by Anonymous Coward
      ファイルシステムの圧縮を有効にするとか、圧縮フォルダ使えばいいのではないかと。
    • by Anonymous Coward

      NTFSの場合小さいファイルはMFTに配置されるから大丈夫ではないかと
      その閾値は調べてないですが

  • by Anonymous Coward on 2009年12月20日 16時25分 (#1691720)
    SSD のブロックサイズとセクタサイズを一致させた新フォーマットの提唱が行われます
  • by Anonymous Coward on 2009年12月20日 18時21分 (#1691783)
    要はファイルシステムのページサイズとアライメントを合わせれば良いということなんでしょうけど、1シリンダ目=63セクタをMBR/PBRで使うことになってるとどうしてもズレちゃうんですよね。
    Linuxはどうなってるんだ?とちょっと調べたんですが、やっぱり63セクタで決め打ちになってるようで・・・そのままじゃ無理ぽい。EFIならできるのかもしれないけど、そうするとXPなど古いOSとのマルチブート環境で辛いことになりそう。
    うちはTrueCryptでWindowsシステム暗号化してるんで、さらに厄介なことに。
    今後の主流になるかわかりませんが、その他ソフトの対応に期待したい。
  • by kikki (30639) on 2009年12月21日 12時35分 (#1692066)
    これでやっとHDD製品のGB表示とOSのGB表示が近い値になりますね(違
  • HDD業界って
    1Kバイト=1000バイト
    1Mバイト=1000Kバイト
    (以下略
    として扱っているけど、てっきり1セクタ=1000バイトだからそのようにしてるのかと思ってた。
  • by Anonymous Coward on 2009年12月20日 17時21分 (#1691745)

    自社のRAID装置は、データ512byteにend-to-endでデータの同一性を保証するためのトレーラ情報8byteを足して1セクタ520byteでフォーマットし直してるなぁ…

    データ経路上全てで520byte単位で処理しているので、HDDだけBigSectorに対応しても全く恩恵にあずかれなかったり。
    そろそろRaidEngineを全部作り直ししないとなぁ。

    • by Anonymous Coward
      そんなRAID用のハードディスクを512byteで
      物理フォーマットしなおしてサーバに突っ込んでたことも
      あったなぁ。

      アクセスランプがアクセス時に消灯だったりするので
      区別しつつ。

      # 特定されそうなのでAC
  • by Anonymous Coward on 2009年12月21日 0時30分 (#1691910)
    詳しくは知らないけど、2HDの容量は基本2MBだよね。
    DOSでフォーマットしちゃうと1.2MB程度になっちゃうけど、某フリーのフォーマッタでフォーマットすると
    2MBフルに使えるディスクになっちゃうのあったよね?
    あんな感じのを誰か開発してくれないかな。ブートは出来なくていいから。
    1.5TB買っても使えるのは1.27TBって・・・
    どういうことやねん。
    • by misuzu (7219) on 2009年12月21日 3時03分 (#1691946) ホームページ 日記

      >2HDの容量は基本2MB

      シーケンシャルに使えばね・・・
      って事でその昔、98用でそんな独自フォーマットを使うバックアップソフトがあったとさ。
      当然ながらランダムアクセスは出来ないんだけど、ディスク枚数と時間を節約できるんで結構便利でした。
      (FATが無い、ギャップが無いから実効転送速度が上がる、回転待ちをトラック変えた時しかしない等での高速化)

      #なんでもっと早くに物理セクタでかくしなかったんだろう。どうせクラスタサイズが肥大化してるのに。
      #そういえば3Mのフロッピーが(略

      --
      凛々しく、あほらしく。
      親コメント
      • オーシャノグラフィー懐かしい。
        当時(1986年)業務で20MのHDDを利用していて、1プロジェクトが300kb~10MB程度の
        プロジェクトのバックアップに利用していました。
        たしか、圧縮した後オーシャノを立ち上げる、そんなバッチを作っていました。

        とにかくデータ転送が早く、ふつうにコピーしたら2~3分かかる作業が、
        ソフトの立ち上げ時間を入れても30秒程度で済んでいたと思います。

        まず、HDDが100Mになり(ミドリ電子だったと思う)、
        Zipドライブにバックアップを変えてから、オーシャノの出番は無くなりました。
        親コメント
      • by Anonymous Coward
        > その昔、98用でそんな独自フォーマットを使うバックアップソフトがあったとさ。
        オーシャノグラフィ2だったと思います。フォーマット形式は不明ですが、たしか超大サイズのセクターを作ってデータを詰め込む形式だったはず。

        しかしそんなローカルマシンを例に挙げなくても、マイクロソフトがWindows 95のインストールメディアで採用したDMF(Distribution Media Format: 1.68MB)や、IBMがPC-DOS7.0やOS/2 Warpで使ったXDF(eXtended Density Format: 1.86MB)なんかの方が有名ですね。
        前者は書き換える必要が無いインストールメディアという性
    • Re:X68000 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2009年12月21日 5時43分 (#1691954)
      >1.5TB買っても使えるのは1.27TBって・・・

      それは 1000vs1024 と filesystem の仕様のせい
      なのではなくて?

      ... | dd of=/dev/rsd2c すればぁ?

      ちなみに FDD にはエラー訂正という概念は入ってません。
      "読めませんエラー"が検出されて終わりです。
      親コメント
  • by Anonymous Coward on 2009年12月21日 10時36分 (#1692006)
    > ただITproの過去の記事を振り返るととだいぶスケジュールが遅延している模様。

    いまだに売れている・普及しているのがXPなんだもの。

    7だってまだ企業などの組織体はまだ様子見・・・・評価するために多少製品を買っているだけだろう。
    少なくともSP1が出るまでは本格普及は先だろう。

    そういう意味で今から約1年くらいは、ベンダー側がWin7に対応したり、トラブル情報を収集したり
    とノウハウをためている時期かと・・・SP1が出て2年目以降からようやくお客様への提案書に書くよう
    になり、予算執行はその次の年じゃないかね?

    かといって、ベンダーもお客もVistaにはOSそのものにノーを突きつけたから、
    結局提案書に書くことはなかったがね。

    個人向けはWin7しかないから泣く泣く買っているにすぎない。
    XPがあったら、XPを買う人のほうがまだまだ多いと思う。
    今買っている人は正直新しいものが好きなPC好きであり、一般ユーザーが
    手を出しているのはまだまだごく少数(PCが壊れて仕方なく買い替えとか)。

    私の場合、評価および開発ソフトのテストで仕方なく使ったけど、メインはまだまだXPだから・・・
    Win7に本格的な移行はまだまだ先だと思う。

    皆さんはどうでしょう?
    お客様への本格導入で今既にWin7を前提の案書を既に今書けてますか?
    • by Anonymous Coward
      > 個人向けはWin7しかないから泣く泣く買っているにすぎない。
      Vistaと違い、Windows 7はそれなりに話題になりましたからわざわざWindows 7を指名買いする人もそれなりに居るような印象があります。

      今までの例を見ると、OSが切り替わるタイミングって「世の中に普通に売っている(なにか)が、古いOSでは使えなくなったとき」というのが多いような気がします。たとえば、Windows 95と98は、外見上ほとんど違わないOSだったけど、USB機器が使えなかったり、4GB以上のHDDが使えなかったりといった理由で「95にしがみつく人」はそれほど多くはなかった。
      一方でWindows 2000→XPなんていうのは、××が使えない、というのがそれほど多くなかったので、今でもまたWindows 2000を使い続けている例も多い。今回に関しては、2TB超のHDDがそれにあたるかもしれません。すでに世の中には2TB容量のHDDも普通に出回り始めており、2TBオーバーも最早時間の問題。そうなったとき、2TBオーバーのドライブが使えないXPがどうなるか、てところでしょうか?
    • by Anonymous Coward

      普通の人は現状で容量に困ってないから。
      容量的に困っているのは動画を扱う人のみだし。

      Windows7については、既に問題は少ないと思う。
      そもそもVistaSP2だと思えば問題ないし。

      アプリ的にはVistaの段階で移行しているから問題は無い。
      というか、ヘンにVista選ぶより良い。
      今の段階でVista対応すら考えていない会社だと顧客に捨てられるよ。

      • by Anonymous Coward

        Vista対応というか、UAC対応をする=アクセス権限をきちんと管理する=アプリケーションがクラックされた時の被害減少というのもあるので真面目にVista対応してほしいです。
        w2kのターミナルサーバー対応アプリケーションのガイドラインを満たせば良いのだからさ。

  • by Anonymous Coward on 2009年12月22日 0時15分 (#1692445)

    x86のセグメントサイズ4Kもいやだな
    x86はやく無くならないかしら...

typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...