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

RAMが128MBしかない小さな組み込みデバイスがあります このデバイスに接続されているのは2TB USB2ハードディスクです 最近まで、デバイスのパフォーマンスに非常に満足しており、ファイルの数がディスクの容量のしきい値を超えたときに、しきい値を超えました（どちらかわかりません）。 書き込みの性質上、ディスク上には多数の小さなファイルがあります。アプリケーションファイルは非常にバランスのとれた方法で編成されています。リーフノードディレクトリには200を超えるファイルはなく、800,000を超えるファイルしかありません。 私は調査するためにリードを得たいと思っています。ディスクのパフォーマンスが大幅に低下しました。デバイスは順調に動いていたため、突然のパフォーマンスはすべて岩のように低下​​しました。 私の仮定では、ディスク上でファイル用に選択した組織構造が、iノードキャッシュの機能を損なうために何らかの形で害を及ぼしていると思います。 実験として、ディスクのマウントを解除しました（キャッシュのフラッシュ、無料で確認済み）。次に、コマンドプロンプトからディレクトリ構造の深いところに移動しました。すべてがこのディレクトリ（およびその子）にはその下に含まれるファイルが約3200しかないことを伝え、この時点で 'free'は117MBを超える空きメモリを示しました この時点で、コマンド「find」に続けて「free」を入力しました 「検索」は約3000ファイルを示しましたが、メモリ使用量は約117MBから約2MBになりました キャッシュと空きメモリのバランス、およびカーネルが空のページを不良ページと見なす方法を理解しています。ただし、3000ファイルのディレクトリから115MBのキャッシュされたコンテンツは、私の理解に重大なギャップがあることを示しています。誰かが起こっていることを理解するのに役立つことを願っています バランスの取れたツリーが多くのファイルを持つための方法だと思いますか？

10 linux  filesystems  ext4 

ロックされています。この質問とトピックへの回答はロックされています。質問はトピックから外れていますが、歴史的に重要です。現在、新しい回答や相互作用を受け入れていません。 本番環境でのext4ファイルシステムについてどう思いますか？数千万もの非常に頻繁に更新される非常に大きなファイルを使用するプロジェクトの立ち上げに非常に近いため、使用するFSを決定する必要があります。 しばらくの間、他のLinux FSに関する考慮事項は次のとおりです。 Ext3は非常に安定していますが、数百万の小さなファイルの処理にはあまり適していません XFSは非常に見栄えがよく、おそらくそれを使用します ReiserFS ...まあ...漠然とした将来、誰がバグを修正するのですか？

10 linux  filesystems  ext4 

fsck.ext4はすぐに終了するようです。ジャーナルログをチェックするだけで、ジャーナルがクリーンな場合は何もしません。それは...ですか？ファイルシステム全体をチェックするように強制するにはどうすればよいですか？私は-fオプションを試しましたが、それは再び終了し、それは非常に迅速にきれいであると言いました。

10 ext4  fsck 

eext4ファイルシステムにインストールされたLinuxマシンのいくつかのファイル/ディレクトリの属性に気づきました。 [kelly@p2820887.pubip.serverbeach.com ~]$ lsattr -d /bin -------------e- /bin によるとchattr(1)： 'e'属性は、ファイルがディスク上のブロックをマッピングするためにエクステントを使用していることを示します。chattr（1）を使用して削除することはできません。 これはどのように異なるのか、そしてより重要なことには、この詳細はどのように重要なのですか？具体的には、なぜこの詳細がファイル属性として報告されるのに十分重要なのですか？このファイルが「ディスク上のブロックのマッピングにエクステントを使用している」という知識に基づいて、どのような状況で動作を変更する必要がありますか？おそらくこれは私が知っておく必要があることです。そうでなければ、それほど明白にはなりませんよね？

9 linux  filesystems  ext4  attributes 

問題： 最近、サーバーの1つを改造しました。使用する前にテストされ、正常に機能しましたが、数日前に、ルートボリュームへの通常の書き込み量の約4倍に気付きました。これはパフォーマンスの問題ではありません-サーバーは正常に動作します。 私の改造はかなり広範囲（完全な再構築）だったので、原因に関して多くを続けることはできません。簡単に言うと、私の変更は次のとおりです。 AmazonのLinuxのアップグレード（2011.02から2011.09へ）-ルートボリュームもext3からext4に変更されました php-fcgiからphp-fpmへの移行（現在はtcpを使用） リバースプロキシ（nginx-> apache）設定からnginxのみへの移行 vsftpdをpure-ftpdで置き換える dkim-proxyをopendkimで置き換える isminconfigによるwebminの置き換え ワニスを動的ファイルのキャッシングレイヤーとして追加します（これらのサイトが受けるヒット数のオーバーキルですが、実験です）。 スワップパーティションを追加する 基本セットアップ： 私のスワップ領域は独自のEBSボリュームにマウントされています-スワップボリュームへの書き込みはごくわずかです-本質的にこれを割り引いています（十分な空きメモリがあり、両方とも最小限のスワップ使用量freeをiostat示しています）。 私のデータ（mysqlデータベース、ユーザーファイル（ウェブサイト）、すべてのログ（/ var / logから）、メール、およびvarnishファイルを独自のEBSボリュームに（を使用してmount --bind）。基礎となるEBSボリュームは、/mnt/data 私の残りのファイル-オペレーティングシステムとコアサーバーアプリケーション（nginx、postfix、dovecotなど）-は、ルートボリューム上にある唯一のファイル（合計1.2 GB）です。 新しいセットアップは、古いシステムより「スムーズ」（メモリが少ないなど）で実行され、20日間（10月中旬）安定しています-私の知る限り、昇格した書き込みはこの間ずっと存在していました。 予想とは逆に、読み取りボリュームが少ない（私の読み取りは、ルートボリュームのブロックとバイトの両方の点で、書き込みの約1.5％です）。過去数日間、ルートボリューム（たとえば、新規インストールなど）で何も変更していませんが、書き込みボリュームは予想よりはるかに多くなっています。 目的：ルートボリュームへの書き込みの増加の原因を特定する（基本的に、それがプロセス（およびプロセス）、別の（ext4）ファイルシステム、または別の問題（メモリなど）かどうかを把握する）。 システムインフォメーション： プラットフォーム：AmazonのEC2（t1.micro） O / S：AmazonのLinux 2011.09（CentOS / RHEL派生） Linuxカーネル：2.6.35.14-97.44.amzn1.i686 アーキテクチャ：32ビット/ i686 ディスク：3 EBSボリューム： xvdap1、root、ext4ファイルシステム（noatimeでマウント） xvdf、data、xfsファイルシステム（noatime、usrquota、grpquotaでマウント） xvdg、swap ルートボリュームとデータボリュームは1日に1回スナップショットが作成されますが、これは「読み取り」操作であり、書き込み操作ではありません。（さらに、以前のサーバーでも同じ方法が使用されました。以前のサーバーもt1.microでした。） I / Oを調べる原因となったデータは、前回のAWS請求の詳細に含まれていました（通常のI / Oを上回っていました-このサーバーをセットアップし、最初に多くのものをインストールしていたため、予期しないことではありませんでした）今月の）、その後、接続されたEBSボリュームのCloudWatchメトリクスで。11月（​​サーバーを変更していないとき）からのI / Oアクティビティを推定して月間値を推定し、それを作業していない過去の月のI / Oと比較することにより、「通常の4倍」の数値に到達します。以前のサーバーで。（以前のサーバーからの正確なiostatデータがありません）。同じ量の書き込みが11月まで持続し、170-330MB …

9 amazon-ebs  ext4  io  alternative-php-cache 

私はWindows Server 2008r2をHyper-Vの役割で使用しています。ゲストシステムはUbuntu 12.04 LTCです。ダイナミック仮想ハードディスク上にあります。 このVHDを圧縮したい（実際のサイズは50 GB、ディスク上の360 GB）。しかし、UbuntuファイルシステムはNTFSではないため、これを行うことはできません。 この問題を解決するには何が必要ですか（gparted、sdeleteなど）。 主な問題は、ファイルシステムがNTFSではなくext4であることです。 答え： 1）systemrescuecdをダウンロードする http://sourceforge.net/projects/systemrescuecd/files/sysresccd-x86/3.8.1/systemrescuecd-x86-3.8.1.iso/download 2）この.isoをクエストOS Ubuntuに追加します 3）この仮想マシンを起動します 4）zerofreeを使用する zerofree /dev/sda1 5）この仮想マシンをパワーオフします 6）Hyper-Vマネージャーを使用（編集->デフラグ） このvhdは360 Gbでした。現在は70 GB。

9 hyper-v  ntfs  hyper-v-server-2008-r2  ext4  zero-fill 

単一のファイルシステムとして公開されている、AWSで大規模で拡張可能な共有ストレージを提供するための許容できる/合理的な/最善の方法は何ですか？ 現在、1 TBのEBSボリュームを隔週で作成しており、NFSはno_subtree_checkとnohideを使用してエクスポートしています。このセットアップでは、個別のエクスポートがクライアントの単一のマウントの下に表示されます。この配置は適切にスケーリングされません。 私たちが検討したオプション： LVM2とext4。resize2fsが遅すぎる。 LinuxのBtrfs。まだプライムタイムの準備ができていません。 Linux上のZFS。まだプライムタイムの準備ができていない（LLNLが使用しているが） Solaris上のZFS。このコンボの将来は（私にとって）不確実であり、新しいOSが混在している glusterfs。ほとんどは良い話ですが、恐ろしい（そしておそらく古い？）2つの話を聞きました。 理想的なソリューションは、共有、単一のfsビュー、簡単な拡張性、スナップショット、およびレプリケーションを提供します。 アイデアと経験を共有してくれてありがとう。

8 linux  amazon-ec2  filesystems  zfs  ext4 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ サーバー障害のトピックになるように質問を更新します。 5年前休業。 Patriot Torx SSDを搭載したMaverickを実行しているラップトップ（昨日までとてもうれしい）を持っています。パーティション全体のLUKS暗号化。その上に1つのLVM物理ボリューム。次に、その上にあるext4論理ボリュームのホームとルート。 昨日起動しようとしたところ、ルートファイルシステムをマウントできないと文句を言った。fsckを実行すると、基本的にすべてのiノードが間違っているようです。ホームとルートの両方のファイルシステムで同様の問題が発生します。バックアップスーパーブロックを確認しても効果はありません。 e2fsck 1.41.12 (17-May-2010) lithe_root was not cleanly unmounted, check forced. Resize inode not valid. Recreate? no Pass 1: Checking inodes, blocks, and sizes Root inode is not a directory. Clear? no Root inode has dtime set (probably due to old mke2fs). Fix? …

8 linux  ssd  corruption  fsck  ext4 

新しいLucid Lynx（Ubuntu 10.04）をラップトップで実行しています。ここで、ファイルシステムを次のように定義しました。 マウントポイント/ ext4（46 Gb） jfs上のマウントポイント/ home（63 GB） 3 Gbとしてスワップ AC電源なしで、私はいくつかのタスクを実行するために機械を一晩放置しました。翌日の朝、私はそれをスタンバイで見つけ、タスクは完了しましたが、ファイルシステムに到達できませんでした。I / Oエラーが発生した jfsとstandbyに問題があるようです。 とにかく、面倒を避けるために、このマウントポイントをjfs形式からext4に移動したいと思います。 データを失うことなく、変換が完了するまでデータを一時的な場所に置く必要なく、これを行うことができますか？ 申し訳ありませんが、Windowsの時代には、データを失うことなくFAT16をFAT32に、またはFAT32をNTFSに変更することを思い出します。これがLinuxで利用できることを願っています。 更新 / homeファイルシステムはjfsではなくxfsであり、何らかの理由でこのファイルシステムにバグがあるようです。全体がext4になるまでOSを2回再インストールする必要がありました/ ただし、結論としては、変換する方法がないようです

8 linux  ubuntu  xfs  ext4  jfs 

問題 2つのディスクに2つのマウントポイントがあり、どちらもまったく同じタイプです。両方のディスクはext4でフォーマットされています。 rsyncソースから宛先に同期するオプションを指定したコマンドが実行されます。 rsyncの実行後、次のデータが表示されます。 ディスク1-ソース 315.8 GiB (339,148,905,125) - 476,038 files, 21,975 sub-folders. ディスク2-宛先 315.8 GiB (339,098,108,411) - 476,038 files, 21,975 sub-folders. 差 50,796,714 バイト（〜50 Mb） 使用コマンド rsync -r -t -p -o -g -v --progress --delete --ignore-existing -s /media/user/disk1 /media/user/disk2 質問 合計バイトサイズが異なるのはなぜですか？ 更新 提案された答えが試みられました。ソースと宛先の間のバイトサイズは、サイズの均等化の改善を示しませんでした。 推奨される応答コマンドには-a、-lスイッチとスイッチが含まれ、アーカイブとシンボリックリンク転送が追加されました。 rsync -a -r -t -p …

rsync  ext4