  |
はてなキーワード: ファイルシステムとは
そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います。
ドワンゴアカウントシステムはScalaのコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています。
ドワンゴのユーザーアカウント基盤は明らかに破綻しています。 10 年以上にわたり、ガラケー時代から今に至るまで多くの業務をコードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います。
ニコニコ生放送(以下「生放送」)ではバックエンド・フロントエンドのサーバーを建てる環境として、2016年からDocker Swarmを採用し始めています。
Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的な検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができます。さらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートがクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上のゼロコンフィグレーション)で実装したことは素晴らしいと思います。しかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターがコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。
私は kubernetes が嫌いです。 Google 製品は開発者の UX を考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題も解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます。
実は分散ファイルシステムも独自に開発しました。もともと既存のオープンソースのファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自に調査開発を進めることにしました。
こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって
ということが分かります。
触れない話: 事実上全然稼働しなかった CTO 、北の将軍様
パブリッククラウド、特に CDN を採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザーは結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定の理由をここでは探ってみます。
動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています。
ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しかし現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。
CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性
要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴは CDN 大流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います。
ただしこの点において今後もビジネス環境、技術環境が現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。
まあもう無理でしょいろいろ
この話の続き
systemd-nspawnに移行した
以下詳細とか雑記
docker commitもdocker diffも使わないし、要らない
要らないだけならまだしも、aufs、overlayfs周りでトラブル可能性がありむしろ邪魔
イメージの差分管理はファイルシステムの層でやるのが素直でコンテナ管理にくっついてるのに違和感がある
Docker特有の機能をフルに使ってる奴ならまだしもコンテナ動かすだけなら何使っても変わらねーよｗ
Docker Hub からイメージダウンロードしてtarで解凍すりゃ良いだけじゃねーか
composeだって容易にコンバート可能だし、composeで何が起きるかわからない状態で本番運用とか口にしないで欲しい
実際systemd-nspawnの今でもベースはDocker Hubから拾ってきてるし、Docker使ってる奴との受け渡しも問題ない
やりかたは runc.io のGetting startedでも見れば？
Docker hubでよくわかんねーイメージ落とすときに、出所がクリアになるってメリットだけだなこんなん
取り急ぎansibleでセットアップは済ませてる
コンテナにしたからプロセス管理は違う方法でやります→supervisorで云々→めんどくさいだろ！
じゃあ1プロセス1コンテナにしてマイクロサービスにします→本当に便利それ？管理できる？
ログの管理は？logrotateは誰がやる？データボリュームはどこにする？みたいなアホみたいな検討し始めたときに俺は会議室を出た
「いや今はこれが主流で流行ってるから便利です」みたいな事言ってるバカが居て殴りたくなった
「毎週、毎週swarmが壊れたバージョンアップで再起動だのと余計な仕事増やしやがって、いつまでDocker社のβテストに付き合うつもりだクズども」
とは言えないので
「今の状況は前よりも運用負荷が高い状況みたいなので、systemd-nspawn等のシンプルなものに代替できないか検討してほしい」
と言ってなんとか説得
(結局半分以上は俺が対応したが)社内のクリティカルな部分のDockerは全部廃棄した
普通に起動して、普通に終了できる。コンテナの中なのにそれを意識しないくらい普通に起動する。
aufs,overlayfs等の差分管理しなければそれに付きまとう問題もない(overlayfsとか使うこともできる)
自動起動も設定もコマンドもコンテナ内だから〇〇しなきゃダメみたいなやつが無くなって、ものすごく安定してる
Dockerも--privilegedつけてinitからrunすればいいって？糞不安定だし、権限多すぎだろ？capabilitiesを適切に設定しろだって？
一生やってろバーカ
結局のところ本当にこれ便利になったんだっけ？って聞かれて理由を言える奴じゃないと何をやってもダメってことが分かった
これはDockerに限らず全部そうだと思う
QiitaとかにあるDockerでこんな素晴らしくなったよって記事の大半は本質を見失った馬鹿記事
楽になるどころか厄介事を＋１してるだけ
とりあえずこっちはDockerのゴタゴタに振り回されなくなって良かったよって話
この前、テキストエディタで日記を書いて保存する、というのを教えた。
で、さっき。帰宅するなり息子が「お父さん、すごいことを思いついた！」と駆け寄ってきた。
息子が言うには、
ということだ。
実際はファイル情報としてファイルシステムに保存されるので、容量は消費しているのであるが、よく気がついたものだと感心した。
「やっぱりねー。そんなはずないとは思ったんだけど『もしかしたら』と思ったんだー」と少し残念そうだった。
でもさ、このアイデアといい、薄々「そんなはずない」って気がつくことといい、すごいよね？
リリース直後だと apt-get update && apt-get upgrade でそのまま壊滅的に環境が壊れるという状態で話にならなかったのだが、
現状残っている問題点としては
あたり。
Mac 上で Linux サーバーで動くアプリを作ることが出来るぐらいには Linux サーバーで動くアプリを作れるようになっている気がする。
ユーザのデータは暗号化されているので直接フラッシュメモリを覗いても意味ないけど、
パスコードを入力して間違ったときに、インクリメントされる値があるはずだよね？
そしてそれは暗号化されていないと思うのだけど、それを適宜書き換えれば、
６桁くらいのパスコードなら簡単に突破できそうな気がするのですが。
誰かおしえてください。
追記
なるほど、そもそも全体が判っていませんでした。（そして今も全然わからない・・）
ファイルシステム全体が暗号化されている、というのはわかりました！
でも前回との差分がそこまで膨大にはならないと思うので、カウンタの位置は特定できそうな気がするのだけど、
特定できても無理なのかしら。
この時間なら誰もいないはず。
https://getfedora.org/ja/workstation/download から
1.4GBと大きいので数十分はかかると思う。
1分ぐらいで終わると思う。
パソコンを再起動しBIOSを開き、USB bootして一番上の選択肢を選ぶ。
あとは待つだけ。7分ぐらいで終わる。
終わったら再起動。
次にWi-Fiの設定を尋ねられるのでいつものWi-Fiに繋ぐ。
次にFirefoxを起動してSyncにかける(すぐ終わる)
ここまでで1分ぐらい。
itamaeを使う。
レシピを自前のプライベートリポジトリからgit cloneし、
パスワードを入力したら勝手にflashとかVimとか入って、
gsettingsでの各種設定、vimrcの配置などをやってくれるので放置。
だいたい15分くらいで終わる。
Unix(とUnixで使われる大抵のファイルシステム)ではU+005cはファイル名に使えるよ。いちいちエスケープしないとならない場合が増えて手間だけど。
あと大元の話だが、時系列としては(1)ディレクトリがまだ無い時代(DOS1.0)に、コマンドのスイッチとして'/'を導入した。これは当時DECのVMS等でも使われてた慣習。(2)DOS2.0で階層ディレクトリをサポートすることになったが、'/'をパス区切りにするとスイッチの'/'とかぶる。VMS等のディレクトリ構文は複雑。というわけで'/'に似た文字として'\'を採用、というわけで、敢えてUnixと違うことをしようとしたわけではない。
TeraStationの前面液晶に「ARRAY2 CHECKING」って表示が出たから何かと思ったら、
ファイルシステムの破損をチェックし、修復する機能です。ディスクチェック中はTeraStationへのアクセスはできません。終了するまで（最大1週間）お待ち下さい。
だと。
最大1週間ってなに！使えねぇじゃんか。
仮にもNASで業務用にも使われてるやつが最大1週間使えないとかなんなんだ。TeraStationが悪いのか。それともRAID5が悪いのか。
というわけでみんなどうしてんの。
成功者しか生き残れない世の中の話ではないですよ（書いているうちに似ているのかも知れないと思ったけど）。
部屋を整理していたら、誰だかわからない人の写ったポラロイド写真が出てきた。僕はこれをだれであるのか知らないけど、たぶん前にこの部屋を使っていた父なら分かるんだろう。というか、この写真は父の持ち物だ。
正直に言って、あまり綺麗な写りではない写真なのだけど、これがもともとそういう写真なのか、経年劣化でそうなってしまったのかは定かではない。
ふと思ったのは、これがもともと写りが悪い写真だった場合と仮定して、（写真の感じから当時存在していたとは思えないけど）デジカメで撮っていたら今まで残っただろうか、ということ。
デジカメの場合、その場で確認して写りが悪かったらそのまま削除してしまう人もいるんじゃないかと思う。フィルムの写真だと一度現像しなきゃならない分コスト大きいからその場で捨てるって言うのは難しい。ポラロイドの場合はすぐに現像されるからフィルムに比べれば確認しやすいけれど、デジタルデータを削除するようにさくっと捨てられるわけじゃなくて、ゴミ箱にもっていくまでのコストはある。それで、時々捨て忘れたりすることがある。
写真に限らず、デジタルデータというのは、「残そう」という意思が一度でも働いたものに関しては、基本的にはデータとしては劣化しにくいし後々まで残しやすいのだろうけど、要らないデータを捨てるのも簡単すぎて、ネガにあたるものとか、一切残骸すら残らないわけですよ（ファイルシステムを直接覗いてサルベージ擦るって言うのはちょっと現実的じゃないかと思って考慮してない）。
今まで、失敗しちゃった写真とかでもたまたま残ってて、後々そのおかげで「あのときああいうことがあったねぇ」「お父さん若いねぇ、懐かしいねぇ」というような思い出話が出来たりしたのが、今の世の中だと起こりにくいのかな、と考えるとちょっと寂しい気持ちになった。デジタルデータを一切消さずにAmazon S3あたりに無限にためていくのも一つの方法かもしれないけど、それはそれで膨大すぎて見返すのはつらかったりするし、思い出を振り返るようなことには使えないんだろうなって。
そういえば、紙の写真のアルバムをみんなでみることも無くなったなぁ。やっぱり今時は、居間のテレビとかに映してみんなで見るのかねぇ。
最終的になにが言いたいのか自分でもわからなくなってきたけど、ふとした瞬間の家族の思い出みたいなものって、なんとなく大切にしたいものだな、そう思ったんですよ。
ファイルシステムのディレクトリのような木構造にデータを格納するのは、RDBに比べたらデータ構造が人間には超分かりやすいし、検索にかかる時間も簡単に見積もれるし、そもそも高速で動くし、CPUもメモリも少なく済む。
確かにRDBのWHERE句に相当する部分はいちいちプログラムで実装しないといけないけど、必要な処理はどれもこれも定型的で、一度覚えてしまえば非常に楽できそう(テンプレのコード用意しといて、システムに応じて微修正してコピペすればいい)。
即ち、誰でも素人からプロになれるというか、プロになるまでのコストが低いので、人材育成の面でも有利。
と、これほどまでに良いことづくめなのに、なんで廃れたのか意味が分からない。
逆にRDBはデータ構造は合理的なんだろうけど、人間にはとても分かりにくいし、パフォーマンスも加味した適切なテーブル設計が出来て効率いいSQLを組めるレベルの人となると、もはや適性の問題になってくる。
要するに向いてない奴にはいくら教育しても全く身につかない。一人前になれる人間が限られると言い換えてもいい。なかなかデキる人が出てこない。
僕はこういう記事を書いたわけです。
http://anond.hatelabo.jp/20130920051551
するとこんなトラックバックが付きました。
http://anond.hatelabo.jp/20130921011214
このトラックバックに正直呆れてます。馬鹿という言葉は時として褒め言葉にもなりえるのでここは「愚か」を選択させてもらいますね。
本当にこのトラックバックを付けた増田は愚かです。無知とかそういうレベルの話ではなく、単純に人生経験が浅いんじゃないかな？って感じました。
僕はまだまだ人生の先輩から学ぶ立場なので、これで僕よりも年上であるのならば年上に対してほんの少しだけ失望してしまう。僕はそんなのは嫌だ。出来れば年下で居てくれ。
このトラックバックを付けた増田、そして同時に似たような思考回路しか持てていない増田へ対し、これらを僕よりも年下だと考えて「教育」「指導」をするために記事を書きます。
前提として先に言っておきます。今から語ることは「なにそんな当たり前の常識的なことをドヤ顔で記事にしてんの？」って嘲笑されるような内容です。
しかしトラックバックを付けた増田はその点がどうやら欠けているようなので僕は「教育」「指導」します。
もう一つ付け加えておきましょう。「そんなこと当たり前だから書かなかっただけ」みたいな言い訳は必要ありません。
この点がしっかりと「真に理解」していたのならばこんなトラックバックは付けません。
それでは引用してみましょう。
データの中身とか気にしなくても使えるコンピュータ（iPadなど）が技術者や科学者でない人間のコンピューティングの中心になっていくはず（我々コンピュータ産業に携わる人間が総力をあげてそういう方向にもっていかないといけない）なので、データの中身とか整理とか割とどうでもいい。そんなのはプログラムのしごと。
ここの部分です。これは非常に愚かな考えだとしか言い様がない。まさに愚考です。
僕はふと自分で書いた増田にどんなトラックバックが付いたかな？と確認したら唖然としました。こんなこともわからないのかと。
コンピューティングが一般ユーザが意識しない方向へ向かっていくのは確かです。この考えは間違っていないと僕は感じます。
この晒しあげ記事を読んでいる多くのIT業界関係者のほとんども同様の意見を持っていいると思います。
しかし、何が愚かか？と言えば僕の書いた記事へこのトラックバックを付けること自体が愚かなのです。
何故か？
このトラックバックには「子供の成長」「子供の将来性」という考慮がまるっきり抜け落ちているからです。
もっとはっきり言えば「子供が将来プログラマになり意識しないシステムを構築する可能性を完全に考慮していない」のです。
例えば50年後に完成された意識しないシステムが完成するとしましょう。
では50年経つ前の子供たちはどうするんですか？その子供たちはプログラマにもならないし従来通りのMS Officeも使わないんですか？
何で子供の成長を考慮しないんですか？時間の流れを考慮しないんですか？
とりあえず、この議論に首を突っ込みたい人は三宅なほみ氏の著書インターネットの子どもたちくらい読んでおくべきだと思います。
は？言葉は悪いですけど「は？」ですよ？
多分その本は良著なんでしょう。三宅なほみ先生は僕でも知っている素晴らしい人物だ。その三宅なほみ先生が書いた本だ最低限のレベルは確保してるでしょう。
しかしその良著を紹介する増田自身が「子供の成長」という最低限レベルの当たり前の常識的なことを理解していない。ダメでしょそれじゃあ。
データの中身とか気にしなくても使えるコンピュータ（iPadなど）が技術者や科学者でない人間のコンピューティングの中心になっていくはず（我々コンピュータ産業に携わる人間が総力をあげてそういう方向にもっていかないといけない）なので、データの中身とか整理とか割とどうでもいい。そんなのはプログラムのしごと。
「一般ユーザ」はファイルシステムを意識しなくてもいいし、意識しなくてもいいコンピュータを設計べきである。
小中学校（「コンピュータを利用した教育」の推進者たちがいうことがほんとうに実現するとしたら学校なんか要らなくなるはずなのでこれらについて考えるのは本末転倒なのだが）では、
を生徒自らが考えることを中心とした授業をやってくれないかなぁ。
とりあえず、この議論に首を突っ込みたい人は三宅なほみ氏の著書インターネットの子どもたちくらい読んでおくべきだと思います。
まずノウハウなんだから読む人が読みやすく、検索性に優れてないとダメでしょ。
というわけでWikiやWordpressでページ作って管理しようず。共有もしやすいし閲覧も検索もしやすいから。
馬鹿だろおまえ＋１。
でかくなったら開くのも書き足すのも重くなって書込みしたいスタッフが書き込む事をやめるベクトルのエネルギーになる。
馬鹿だろおまえ＋２。
んで前述の通り、運用管理しやすいフォーマットに変更しようず、肥大化して対処不可に成る前に、と提案したけどダメでだった。
なぜかというと、本社に提出するにあたって、仕事してる感の強い＝印刷しやすくて印刷したらすげー枚数になる方が予算降りるから。
評価方式が色々アレだとは思っていたが馬鹿にもほどがある。
例えばファイルのダウンロードの場合、メモリにバッファを取って特定容量ずつ書き込みを行う。
多分512KBとか1MBとか、つまりダウンロード途中でも一時ファイルごとの容量はOSに取って書き込み完了してる訳。
ローカルで書き込まれて書き込みが完全に完了した後に
ファイルが存在すると決定してインデックス部分に書き込みを行っている。
だからエクスプローラは途中でキャンセルしても一時ファイルは存在しない、
何故そうなるかというとエクスプローラはファイルの整合性の問題。
書き換え途中でファイルの存在を通知して確定してしまうとキャンセルを押した場合に取り消しができないから
上書きしてる時にキャンセルした時に途中まで書き換わってたら困るでしょ？
ブラウザの一時ファイルの通知はメモリの容量の問題もあるし、キャンセルした所で一時フォルダにゴミが残ったとしても問題ないから。
こんな感じでおｋ？
少し遅れた感があるけど、解いてみた。
出力がテキストでないけど・・・。
仕事の合間を使ってやったものの、昼前に始めたのが5時頃にようやくできる程度。
これを25分とは尋常じゃないな、大口叩くだけあってよっぽど優秀なんだろう。
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=shift_jis"> <meta http-equiv="Content-Language" content="ja"> <meta http-equiv="Content-Script-Type" content="text/javascript"> <meta http-equiv="Content-Style-Type" content="text/css"> <style type="text/css"> <!-- pre { font-family: monospace; } --> </style> <script type="text/javascript"> <!-- window.onload = function() { var q = new Map(); q.load("maptest.txt"); q.search(); var answer = document.getElementsByTagName("pre").item(0); var answerText = "\r\n"; for(var ix = 0; ix < q.route.length; ix++) { answerText += q.route[ix].join("") + "\r\n"; } answer.firstChild.data = answerText; alert("終了しました。"); }; /** マップオブジェクト */ function Map() { this.ymap = []; this.route = []; } //マップの読み込み Map.prototype.load = function(filePath) { //ファイルシステム var fileSystem = new ActiveXObject("Scripting.FileSystemObject"); //ファイル読み込み var file = fileSystem.OpenTextFile(filePath); while(!file.AtEndOfLine) { var fileBuffer = file.ReadLine(); this.ymap.push(fileBuffer.split("")); } file.Close(); fileSystem = null; }; //マップの探索 Map.prototype.search = function() { var that = this; //マップコピー var ymap = this.ymap.concat(); for(var y = 0; y < ymap.length; y++) { ymap[y] = ymap[y].concat(); for(var x = 0; x < ymap[y].length; x++) { if(ymap[y][x] == "S") var start = new MapNode(y, x); if(ymap[y][x] == "G") var goal = new MapNode(y, x); } } var openList = []; var closeList = []; start.costf = start.distance(goal); openList.push(start); //経路探索 while(openList.length > 0) { var node = openList.shift(); //探索終了 if(goal.equal(node)) { createRoute(node); break; } closeList.push(node); //隣接ノードの作成 var tonari = []; if( ymap[node.positionY][node.positionX - 1] == " " || ymap[node.positionY][node.positionX - 1] == "G" ) tonari.push(new MapNode(node.positionY, node.positionX - 1, node)); if( ymap[node.positionY - 1][node.positionX] == " " || ymap[node.positionY - 1][node.positionX] == "G" ) tonari.push(new MapNode(node.positionY - 1, node.positionX, node)); if( ymap[node.positionY][node.positionX + 1] == " " || ymap[node.positionY][node.positionX + 1] == "G" ) tonari.push(new MapNode(node.positionY, node.positionX + 1, node)); if( ymap[node.positionY + 1][node.positionX] == " " || ymap[node.positionY + 1][node.positionX] == "G" ) tonari.push(new MapNode(node.positionY + 1, node.positionX, node)); //隣接ノードの検索 for(var tx = 0; tx < tonari.length; tx++) { var openIn = false; var closeIn = false; tonari[tx].cost = node.cost + 1; var costf = tonari[tx].cost + tonari[tx].distance(goal); tonari[tx].costf = costf; //オープンリストから検索し入れ替える。 for(var ox = 0; ox < openList.length; ox++) { if(tonari[tx].equal(openList[ox])) { openIn = true; if(costf < openList[ox].costf) { openList.splice(ox, 1); push(openList, tonari[tx]); } break; } } //クローズリストから検索し、オープンリストへ移す。 for(var cx = 0; cx < closeList.length; cx++) { if(tonari[tx].equal(closeList[cx])) { closeIn = true; if(costf < closeList[cx].costf) { closeList.splice(cx, 1); push(openList, tonari[tx]); } break; } } //どちらにもない場合、オープンリストへ追加する。 if(!openIn &amp;&amp; !closeIn) push(openList, tonari[tx]); } } //適切な位置に追加する。 function push(array, item) { for(var ix = 0; ix < array.length; ix++) { if(item.costf < array[ix].costf) { array.splice(ix, 0, item); return; } } array.push(item); } //ルートマップの作成 function createRoute(lastNode) { var node = lastNode.parent; while(node.parent) { ymap[node.positionY][node.positionX] = "$"; node = node.parent; } that.route = ymap; } }; /** マップノード */ function MapNode(y, x, parentNode) { this.positionY = y; this.positionX = x; this.parent = parentNode; this.cost = 0; this.costf = 0; } //同一ノードかチェックする。 MapNode.prototype.equal = function(targetNode) { if( this.positionY == targetNode.positionY &amp;&amp; this.positionX == targetNode.positionX ) return true; return false; }; //直線距離を求める。 MapNode.prototype.distance = function(targetNode) { sabunY = this.positionY - targetNode.positionY; sabunX = this.positionX - targetNode.positionX; return sabunY ^ 2 + sabunX ^ 2; }; // --> </script> <title>経路探索：A*</title> </head> <body> <pre>&nbsp;</pre> </body> </html>
1/ CDから起動
2/ Windows XP 回復コンソール（R）を選択
3/ コマンドプロンプトが起動したら、
「format drive: /FS:file-system」
と書く。
例：
「format D: /FS:NTFS」
http://support.microsoft.com/kb/314058/ja
①＜スタート＞メニュー→＜ファイル名を指定して実行＞を選択し、
②「名前」欄に半角で「format（半角空き）d＝（半角空き）／ｆｓ：NTFS（半角空き）／v：データ」
と入力。
「NTFS」はファイルシステムをNTFSにすることをあらわし、
かわりに半角で「fat32」と入力すれFAT32形式でフォーマットできる。
「データ」はボリュームラベルで任意のものを入力すればいい（省略可）。
③＜ＯＫ＞ボタンを押すと「コマンドプロンプト」が起動するので、
④[Y]→[Enter]とキーを押そう
