『HDDの断片化』のクチコミ掲示板

[isipon]

東芝のDBR-Z160でBDに保存しようとすると、BDレコーダーが、フナイ製のせいなのかエラーになり、やり直す回数が多く困っています。BDに保存するならパナかソニーが良いとのことですが、ソニーは、 REGZA　TVからのLANダビングができないが、手間はかかるが、パナだと可能と言う事で、DMR-BWT520の購入を検討しています。ただ気になることは、東芝機では、CMカットは、プレイリストをUSB−HDDに移動すれば済んでいます。パナでは、編集でCMを削除しなければならないらしいのですが、実は、以前DBR-Z160でもプレイリストを使わず、編集でCMを削除していたら編集中にデータが壊れて録画していた残りの番組も全部ダメになってしまい、泣く泣くHDDを初期化しました、原因は、編集でCMの削除を繰り返していると、HDDが断片化してしまうと聞きました。しかしプレイリストを使うことで断片化を抑えられるらしく以後データが壊れることはありません。PCのようにデフラグがないので、パナ機でもこのようなことは起きうるのでしょうか？

書込番号：15291408

[ﾕﾆﾏﾄﾘｯｸｽ01の第三付属物]

パナは起きないです・・・っていうか
東芝以外は起きないです

それに東芝でのエラーも
HDDの断片化では無いかもしれません

書込番号：15291497

[ポテトグラタン]

パナの710で妻がCMカットを頑張ってやってます。
さっきもシリーズものを頑張ってやってました。
ウチでは今までトラブルはないです。

書込番号：15291514　スマートフォンサイトからの書き込み

[shigeorg]

ﾕﾆﾏﾄﾘｯｸｽ01の第三付属物さん
> それに東芝でのエラーも
> HDDの断片化では無いかもしれません

東芝機についてちゃんと検証したわけではありませんが、コンピュータの仕組み的にはテレビやレコーダーの録画 HDD では OS レベルの HDD の断片化は起きにくいものになっています。(録画テレビやレコーダーの OS は各メーカーともに Linux で、Linux は Windows とは違って断片化は起きにくい (気にしなくてもよい) 仕組みになっています)

東芝レコーダーの不具合は、東芝が OS の上に独自に構築していると思われるデータ管理システムが不具合を起こしていると思っています。

ということで、東芝以外のメーカーでは東芝機のような不具合は起きないでしょう。

書込番号：15291619

[isipon]

shigeorgさん　ご回答大変参考になりました。東芝機だけの現象だったんですね。購入を前向きに検討します。

書込番号：15291705

[経過観察中]

スレ主さん、横からすみません。

shigeorgさんへご質問なんですが、

>録画テレビやレコーダーの OS は各メーカーともに Linux で、Linux は Windows とは違って断片化は起きにくい (気にしなくてもよい) 仕組みになっています

…とはどういう仕組みで断片化が起きにくいのでしょうか？
以前は断片化が起きにくいとされていた Windowsの NTFSもたまにデフラグを起動すると真っ赤に断片化していて、かといってあまり頻繁にデフラグするとハードディスクに負荷をかけてかえってトラブルの元になるってことでたま〜にしかしないようにはしていましたが、精神的にはいやな感じはありました。

それとこのレコーダーを購入前は東芝のアナログチューナー機の RD-XS43を使っていまして、RDの場合はタイトルがあってチャプター編集してプレイリストでつなぎ合わせたいチャプターを各タイトルから選んでダビング…の手順に慣れていたので、タイトルそのものを編集しながらダビングする BWT520の手順に慣れてはきましたが若干の違和感を持ちつつ使っています。

私の場合で言うと平日深夜の５分番組の「全力坂」を撮って、不要なCMを削除すると実質４５秒程度の番組なんですが、これを毎日編集していて、しかも子供の部活のバスケットボールの試合の撮影ビデオも毎週のようにダビング・編集・BD/DVD化していて「大量に断片化してるだろうな〜と」とか「そのうちトラブルかも？」と思っているんですが、そのような心配は要らないものでしょうか。

例えば一つながりになっていた録画番組で CMなど不要部分を削除した後の番組データはどのようにハードディスク上で管理されることなのかお教えいただくと、今後使っていく上で参考になるのでよろしくお願いいたします。

書込番号：15292173

[参番艦]

>東芝のDBR-Z160でBDに保存しようとすると、BDレコーダーが、フナイ製のせいなのかエラーになり、やり直す回数が多く困っています。

フナイドライブは確かに焼き品質に問題ありますが、そんなに頻繁にエラーが出るということはドライブの故障も考えられます。保証期間内ならメーカーにBDドライブ交換依頼してみては？
あと使っているBDはどのメーカーの物で原産国どこの物ですか？台湾産の物だとBDの品質にばらつきが多いのでBDの不具合も考えられます。パナかソニーの原産国日本の物使ってみて下さい。

書込番号：15292309

[紅秋葉]

Linuxで断片化が起きにくい仕組みについては、次のページが
分かり易いと思います。

Linuxとデフラグ
http://www.obenri.com/_dialy/linux_defrag.html

Linuxでデフラグが必要のない理由
http://blog.livedoor.jp/vine_user/archives/51201150.html


　パナソニックでは断片化が原因とみられるトラブル報告は
ほとんどないです。ただ、残り容量を10%をきったままで、
録画・編集・削除・再度録画を続けていた、という状態だと
正常に再生できないトラブルが出た、という報告は記憶に
ありますが。

書込番号：15292664

[shigeorg]

経過観察中さん
> どういう仕組みで断片化が起きにくいのでしょうか？

仕組みの概要についてはすでに紅秋葉さんがリンクを紹介して頂いていますが、さらに補足すると Linux やその元となった UNIX 系では、最初からあちこちにデータが分かれて置かれることを前提として設計されているので (各データごとという意味ではなく、一つのデータの中の細切れデータ単位で)、おおざっぱに言うと「最初から断片化が発生することを前提としている」と言えます。

で、それを前提としているので、断片化が起きていても読み書きがなるべくスムーズになるような方法を採用されているのです。

そういう意味では「断片化が起きにくい」というより「断片化は起きているが、読み書きの際のその影響が少ない」という方がよいのかもしれません。


> 以前は断片化が起きにくいとされていた Windowsの NTFSもたまにデフラグを起動すると真っ赤に断片化していて

私は NTFS については詳しくはないのですが、Linux や UNIX と同様に「断片化が起きにくい」のではなく「断片化があっても影響が少ない」という設計なのではないでしょうか？


> 「大量に断片化してるだろうな〜と」とか「そのうちトラブルかも？」と思っているんですが、そのような心配は要らないものでしょうか。

Linux 系 (UNIX 系も同様) の場合、前述のように断片化を前提としているのですが、さらに、小さいサイズのファイルも大きなサイズのファイルも同じに扱うのではなく、サイズに応じて適切な処理ができるような工夫がされています (そういう仕組みが用意されています)。


> 例えば一つながりになっていた録画番組で CMなど不要部分を削除した後の番組データはどのようにハードディスク上で管理されることなのかお教えいただくと、今後使っていく上で参考になるのでよろしくお願いいたします。

これには大きく分けて 2 つのレベルがあると思います。

OS レベルの HDD の管理と、その上での各社のレコーダーソフトによる番組データ管理です。

各社ごとのデータ管理の方はそれぞれ独自にデータベースを作成するようなものなので、管理方法はわかりません。ただ、東芝はそれがかなり大規模でチャプターを含めた多くのデータを一括して管理しているのだろうと思います。


各社の機器では見た目一つの番組に見えていても、実は内部ではチャプターごとにファイルとして分割されているとか、もっと細かく分割されているかもしれませんし、逆に複数番組が実は一つのファイル内で管理されているのかもしれません。

これは編集やダビング、録画方式変換等のしやすさなどに影響するので、どの機能を重視するかによって異なってくるのだろうと思います。

なので、CM カットをする前の番組ファイルと、した後の番組ファイルが、それぞれ一つのファイルなのかもしれませんし、実は CM カット後は 2 つ (以上) のファイルになっているのかもしれません。


OS レベルの HDD 管理の方は、ファイルシステムという仕組みで管理されているのですが、これは「一つのファイルにどのような情報を持たせ (データおよびファイル名や日付など)、それを HDD 等でどのように保存 (読み書き) するか」という仕組みです。

これは同じファイルシステムを採用していれば、メーカーに関係なく同じです。一つの OS でも複数の方式を採用しているものもあります。


UNIX や Linux では各ファイルは iノードというもので管理されていて、HDD 内のセクタやブロックという読み書きエリアとの関連付けをしています。この関連付けが前述のようにあちこちに実際のデータブロックがあることを前提としたものになっているのです。

Linux では ext2, ext3 や xfs というファイルシステムが使えますが、レコーダーだと ext3 や xfs が多いようです。(ext3 は ext2 をベースにしていて、さらに UNIX の ufs をベースにしています)

これ以上は専門的になりすぎるので、参考ページのご紹介にとどめておきます。

http://docs.oracle.com/cd/E24845_01/html/819-0386/fsfilesysappx-23724.html
(図21-1 が UFS の関連付けを表していて、左がファイル情報、右がハードディスクです)

http://www.geocities.jp/sugachan1973/doc/funto31.html
(ファイルシステム全体についてかなり詳細にかつなるべく分かりやすく解説されている)


後者のページはかなり長いのですが、関連する事柄が図も使いながら説明されていて、興味を持って読めばいろいろ勉強になるかと思います。

途中いろいろ専門的な話も出てきますが、ざくっと話の流れを把握して、細かいところは飛ばして必要そうなところを斜め読みするだけでも参考になるでしょう。

Linux 系のデータ保存方法については、真ん中より下あたりの「これで、C言語の余談、おしまい」と赤文字で書かれた下の図が参考になります。

書込番号：15293585

[経過観察中]

紅秋葉さん、shigeorgさん、解説レスをありがとうございました。

リンク先のサイトの内容をすべて理解できたわけではないですが、大雑把に言ってファイルをスペースを開けながら書き込んで不連続を防ぐようにしているってことなのかな？との理解でよろしいでしょうか。

まずは録画・編集を繰り返すことによって番組データが壊れることはないとのことで安心できました。

書込番号：15295210

[shigeorg]

経過観察中さん
> 大雑把に言ってファイルをスペースを開けながら書き込んで不連続を防ぐようにしているってことなのかな？との理解でよろしいでしょうか。

大雑把にはそれで合っています。

あとは、「不連続があっても大丈夫なような仕組みが使われている」と思ってください。

書込番号：15295960