タグ付けされた質問 「ext3」

ホスティング会社のVMでサーバーを実行しており、専用ホスト（AMD Opteron 3250、4コア、8GB RAM、ソフトウェアRAIDの2 x 1TB、ext3）にサインアップしました。 パフォーマンステストの実行中に、一部のSQLite変換（挿入、削除、更新の組み合わせ）が2010 MacBook Proよりも10倍から15倍長くかかっていることに気付きました。 たくさんのグーグルと読書の後、マウントオプションを確認しました。 data=ordered,barrier=1 私たちはいくつかの実験を行い、最高のパフォーマンスを得ました data=writeback,barrier=0 私はこれらを読んで、彼らがしていることの基本を理解していますが、このように走るのが良い考えかどうかについての感覚/感覚がありませんか？ ご質問 上記の設定は、ホストされたサービスで考慮するのが賢明ですか？ 停電やハードクラッシュが発生した場合、データが失われたり、ファイルが破損したりする可能性があります。DBのスナップショットを15分ごとに作成している場合、状況は緩和される可能性がありますが、スナップショットの作成時にDBが同期されない場合があります。このようなスナップショットの整合性をどのように（どのように）保証する必要がありますか？ 他に検討すべきオプションはありますか？ ありがとう

13 centos  mount  ext3  performance-tuning  write-barrier 

私の会社は、内蔵SSDドライブのext3パーティションから起動する組み込みDebian Linuxデバイスを作成しています。デバイスは埋め込まれた「ブラックボックス」であるため、通常は外部スイッチを介してデバイスの電源を切るだけで無作法にシャットダウンされます。 ext3のジャーナリングは物事を整理するので、これは通常は問題ありません。そのため、ログファイルの一部が時々失われることを除いて、物事はうまく動き続けます。 ただし、最近、いくつかのハードパワーサイクルの後にext3パーティションが構造上の問題を発生し始めるユニットを見てきました。特に、ext3パーティションでe2fsckを実行すると、次のような多くの問題が見つかります。この質問の下部にある出力リストに表示されます。エラーの報告（またはパーティションの再フォーマット）が停止するまでe2fsckを実行すると、問題は解消されます。 私の質問は...たくさんの突然の/予期しないシャットダウンにさらされたext3 / SSDシステムでこのような問題を見ることの意味は何ですか？ 私の考えでは、これはシステムのソフトウェアまたはハードウェアの問題の兆候である可能性があります。私の理解では、ext3のジャーナリング機能はこれらの種類のファイルシステムの整合性エラーを防ぐはずだと理解しているためです。（注：ユーザーデータはジャーナリングされていないため、ユーザーファイルが変更/欠落/切り捨てられる可能性があることを理解しています。具体的には、以下に示すようなファイルシステムメタデータエラーについて説明しています） 一方、同僚は、SSDコントローラーが書き込みコマンドを並べ替える場合があり、ext3ジャーナルが混乱する可能性があるため、これは既知/予想される動作であると述べています。特に、正常に機能するハードウェアとバグのないソフトウェアが与えられたとしても、ext3ジャーナルはファイルシステムの破損を不可能ではなく不可能にするだけであるため、時々このような問題が発生しても驚かないはずです。 私たちのどちらが正しいですか？ Embedded-PC-failsafe:~# ls Embedded-PC-failsafe:~# umount /mnt/unionfs Embedded-PC-failsafe:~# e2fsck /dev/sda3 e2fsck 1.41.3 (12-Oct-2008) embeddedrootwrite contains a file system with errors, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Invalid inode number for '.' in directory inode …

13 filesystems  hardware  ssd  ext3 

私が理解しているように、Unixライクなオペレーティングシステム上の各ファイルにはiノード番号（「ls -i」で表示できます）があり、各iノードはファイルの実際のデータを含むディスクブロックのリストです。 引数としてファイル名を取り、そのファイルのiノードが指すディスクブロックのリストを出力するLinuxコマンドはありますか？ PS問題のファイルシステムはext3です。

13 linux  unix  filesystems  ext3 

512 MBのRAMしか搭載していない古いDebian Linuxボックス（etchを実行している）の世話をしますが、外部ストレージは大量に接続されています。1つのext3ファイルシステムのサイズは2.7 TBであり、fsckはそれを確認できません。これは、次のようなエラーでメモリが不足するためです。 ディレクトリブロック配列の割り当てエラー：メモリの割り当てに失敗しました e2fsck：中止されました 4 GBのスワップパーティションを追加しましたが、まだ完了していませんが、これは32ビットカーネルであるため、これ以上の追加が役立つとは思いません。 64ビットカーネルで起動する以外に、fsckにチェックを完了させる他の方法はありますか？

13 linux  debian  memory  ext3  fsck 

rsnapshotを使用して、「作業」共有の毎時/毎日/毎週/毎月のバックアップを作成します。今、rsyncを使用して、バックアップディレクトリ全体を外部ドライブにコピーしようとしています。 画面セッション内でこのコマンド/パラメーターを使用しました（はい、rsync-exclude.txtはコマンドを実行するディレクトリにあります） rsync -avzHP --exclude-from 'rsync-exclude.txt' /share/backup/ /share/eSATADisk1/backup/; すべてがQNAP TS-439で実行されており、内部ドライブはEXT4でフォーマットされた単一のディスク（RAIDなし）、外部ドライブはEXT3でフォーマットされています。 起こることは次のとおりです。Rsyncはすべてのハードリンクに従い、更新されたハードリンクを外部ドライブに再作成する代わりに実際のファイルをコピーします。私はすぐにこれを認識しなかったので、外部ドライブは同じファイルのxxxコピーでゴミ箱に入れられました。 私が達成したいのは、rsnapshotによって生成されたファイル構造全体を外部ドライブにコピーして、スペースを節約するためにハードリンクを保持することです。注：これは必ずしもrsyncを使用して実行する必要はありません。 あなたのアイデアと時間をありがとう。貴重な時間をありがとうございました。 更新： rsnapshotはシンボリックリンクを使用せず、ハードリンクを使用しているため、Rsnapshotに応じたハードリンク構造を複数の宛先に保持する（またはハードリンク構造を維持する） -Hオプションを使用するようになりましたが、まだ機能しません...ここで何が欠けていますか？ 更新2：ここでこのトピックに関する別の意見/ステートメントを見つけました：rsync with --hard-links freezes Steven Mondayは、ハードリンクを含む大きなファイル構造をrsyncしようとしないことを提案します。したがって、おそらく、より良い解決策は、バックアップしようとしているデータ構造の.imgを作成することです。どう思いますか？

13 linux  backup  rsync  ext3  rsnapshot 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 6年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 HOWTO Forgeの記事や1年前の別の記事で説明されているように、Windowsでext2 / ext3を使用/アクセスする方法がいくつかあることを理解しています。ただし、リストされている項目はいずれも、完全に実装されたext3への完全な読み取り/書き込みアクセスを提供しません。つまり、2つの読み取り/書き込みオプションはext3ジャーナルをサポートしていないようです。（ext2fsdは空でないジャーナルを再生しますが、そうでない場合は使用しません。ext2fs.sysはジャーナルをまったく使用していないようです。） Windowsにインストールして、ジャーナル、ユーザー権限、selinux属性（可能な場合は少なくとも保持する）、その他の拡張属性など、ext3パーティションへの完全な読み取り/書き込みアクセスを提供できるドライバーを知っている人はいますか？ これらのドライバーのいずれかを実際に使用したことがありますか？現在、FAT32パーティションを介してデュアルブートシステム上のOS間でデータを共有しています。Linuxで読み書きアクセスできるNTFSを使用できることを知っています。ただし、可能であれば、ext3を使用することをお勧めします。

12 windows  filesystems  ext3 

私はファイルシステムのバージョン管理について長い間考えてきました。これはキラー機能であり、Wayback、ext3cow、zfs、fuseソリューション、または単にcvs / svn / gitオーバーレイを見てきました。 ext3cowを要件のモデルと考えています。透過的で効率的ですが、追加ls abc@timestamp機能なしで実行できます。何らかの形でファイルの自動化された透過的なバージョン管理を取得している限り。 瞬間的なものでも、10秒、30秒、1分、5分、15分などの間隔でのスナップショットに基づいたものでもかまいません。特定のディレクトリにある数千のファイルをさまざまなサイズで効率的に処理します。 100メートルから1ギガバイト以上。 私はLinuxを使用しているので、ZFSは実際にはオプションではありません（新しいものではなく、バージョン管理したいext3セットアップがすでにあるので、ヒューズを介して使用することを好まないでしょう）。 どんなソリューションがありますか？

11 git  ext3  filesystems  versioning 

Linux CentOSサーバーにEXT3フォーマットのドライブがあります。これはウェブアプリのデータドライブであり、すべてのユーザーアカウントのディレクトリが含まれています（ユーザー数は25,000人です）。各フォルダには、そのユーザーがアップロードしたファイルが含まれています。全体として、このドライブには約250GBのデータが含まれています。 これらすべてのディレクトリを使用してドライブを構成すると、ドライブの読み取り/書き込みパフォーマンスに影響がありますか？それは私が気付いていない他のパフォーマンスの側面に影響を与えますか？ このように構造化することで本質的に悪い点や悪い点はありますか？おそらくファイルシステムの間違った選択でしょうか？ 私は最近2つのデータドライブをマージしてみましたが、EXT3は32,000のサブディレクトリに制限されていることに気付きました。これはなぜだろうと思いました。データベース内のIDに対応する一意のIDが各ファイルにあることを考えると、この方法で作成したのはばかげているようです。ああ...

11 linux  performance  filesystems  ext3  ext4 

私は実際にブロックサイズにあまり注意を払っていませんが、デフォルト以外のものを選択することには明らかにメリットがあります。ブロックサイズの選択に関する優れた「ベストプラクティス」ペーパーを探しています。また、LVMの上で使用すると、パフォーマンスの見返りや重要性が何らかの形で打ち消されますか？TIA

11 filesystems  ext3  performance 

私のイントラネットサーバーには、lvm2の物理ボリュームとして使用する100.00 GiBパーティション/ dev / sda5があります。 これは、ボリュームグループvg01の唯一の物理ボリュームです。 vg01には現在、1つの論理ボリュームlv01が含まれており、完全な100.00 GiBを使用しています。まあ、実際には（丸めが原因で）丸めが原因で99.99 GiBになっています。 lv01には、スペース全体を使用するext3ファイルシステムが含まれています。 lv01を約97 GiBに減らしたいので、およそlv02を作成できます。3 GiB（lvmスナップショットを撮るために必要です）。 これまでに行ったこと： e2fsck -f /dev/mapper/vg01-lv01 resize2fs /dev/mapper/vg01-lv01 97G これはうまくいきました。しかし今、私は実行する必要があります lvreduce --size ? /dev/mapper/vg01-lv01 また、正確にどの値を指定する必要があるのかわかりません。lvreducemanページには、結果のサイズは、ファイルシステムより小さくてはならないこと、明示的に警告しています。また、必要以上に大きくしたくありません。しかし今、私は異なる数を持っています： 97Gresize2fsで指定しました。 df -h 言う、それは96 Gです。 df 言う、それは100115936 1 Kブロックです。 lvdisplay（もちろん）はまだ論理ボリュームの99.99 GiBを報告します。 何を指定する必要がありlvreduceますか？ 編集： 現在受け入れられている答えは良い回避策を提供します。しかし、そのようなものを堅固なスクリプトなどに統合するために、私は通常、代わりに正確な測定値を使用することを好みます。または、サイズ変更手順全体を1つのステップで実行する信頼性の高い（！）スクリプトまたはツールがすでにあるのでしょうか。

10 lvm  ext3 

古いHP DL380G5サーバーがあり、RAID5アレイに5つの300GB SCSI 3.5 ''ディスクがあり、外部ベイに、ext3ファイルシステムで論理ボリュームとしてフォーマットされ、1.2 TBの機密の臨床患者データをホストします。 2つのディスクがhpacucliで予測障害を示したため、最初にそれらの1つを交換し、問題がないことを確認しましたが、「再構築の準備ができました」とも表示されていませんでした。私は2番目のものもまったく不注意に変更しましたが、RAIDが失敗したと表示されます。 古いディスクを元に戻し、サーバーを再起動してみましたが、起動中にリカバリモードになり、論理ボリュームが見つからないと表示されました。 これを復元するために私ができることは何ですか？残念ながらバックアップはありません。どんな助けでも本当に感謝します！ 古いドライブを両方とも戻すことを考えていましたが、RAIDが復活する可能性はありますか？

9 raid5  ext3 

ext3ファイル名にはどの文字が無効ですか？私は少なくとも/無効な文字であり、おそらくそうだと思い\0ます。公式リストはどこにありますか？ この情報をどこで探すか正確にはわからないので、どこで見つけたのか教えてください。

9 linux  ext3 

私は大規模なストレージファームのセットアップを行っており、1か月にわたるfsckの必要性を回避するために、私の計画は、ストレージを多数の小さなファイルシステムに分割することです（これは、十分にバケット化されたファイルツリーがあるため、問題ありません）私は簡単に持つことができるので、別のファイルシステムは、上に取り付けられ1/、2/、3/、4/）など。 私の問題は、fsckの時間を同様に「妥当」に保つために、「妥当な」サイズがファイルシステムにとってどのようなものかを列挙して見つけることです。特定のサイズの絶対時間はハードウェアに大きく依存することは十分に承知していますが、さまざまなファイルシステムサイズでのext3 fsck時間の曲線の形状、およびその他の変数については説明が見つからないようです（ツリー内の何千ものディレクトリのそれぞれに10個のファイルがある場合、単一のディレクトリにあるファイルでいっぱいのファイルシステムは1よりも長くかかりますか？大きなファイルと小さなファイル、完全なファイルシステムと空のファイルシステムなど）。 誰もがこれについてよく研究された数字を参照していますか？それが失敗した場合、これらの問題に関する逸話は、それが必要な場合でも、少なくとも私自身の実験を導くのに役立つはずです。 編集：明確にするために：ファイルシステムに関係なく、メタデータに問題が発生した場合は、チェックする必要があります。時間ベースまたはマウントベースのre-fscksが有効であるか必要であるかは問題ではなく、特にext3に関する数値を求める唯一の理由は、選択されるファイルシステムが最も可能性が高いためです。特に高速なfsckプロセスを備えたファイルシステムをご存知の場合は、私は提案を受け入れることができますが、堅牢なオプションである必要があります（「ファイルシステムXはfsckingを必要としない！」 。私もバックアップの必要性を認識しており、fsckへの欲求はバックアップの代わりではありませんが、ファイルシステムを破棄し、不具合が発生したときにバックアップから復元するだけではなく、fscckを実行するのではなく、

9 ext3  fsck 

Dell 1950サーバーで問題が発生しています。RHEL 4.6をOracleおよびその他のソフトウェアとともにここにインストールしています。 sshセッションとサーバーに接続したモニターで、「カーネル：ジャーナルコミットI / Oエラー」というエラーメッセージがランダムに表示され、「EXT3-fsエラー（デバイスsda5）」というエラーが表示されます。 start_transaction：ジャーナルは中止されました。」 これは何度か発生しましたが、インストール中の同じ時点では発生していません。実際、前回はシステムが稼働していて、データベースをOracleにインポートしようとしていました。 これはいくつかのハードドライブで発生したので、問題ではないと確信しています。これは私にレイドコントローラーが悪くなっていると思います。 皆さんはどう思いますか？ **更新** それが悪いハードドライブだったことはかなり確かです。私はサーバーに別のドライブを投げました、そしてそれは問題なしで約48時間走っていました。

9 linux  raid  ext3 

127を超えるキリル文字UTF-8シンボルを含む名前のファイルをExt3ファイルシステムに保存できません。ただし、255文字までの英語のUTF-8記号を含むファイルを保存することは可能です。 だから、数に制限があるバイトのファイル名または数含む文字ファイル名には？前者の場合、たとえば、中国語のファイル名の長さにはさらに厳しい制限が予想されます。そうですか？

9 ext3  utf-8