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

ファイルシステム（またはファイルシステム）は、データの保存、取得、更新の手順を提供することにより、プログラムの終了後に保持されることが予想されるデータを整理し、データを含むデバイスの利用可能なスペースを管理する手段です。

2
.nfsXXXXファイルが表示されますが、それらは何ですか？
NFS共有にデータをストリーミングする（RHEL5上で）実行中のアプリケーションがあります。最近、作業ディレクトリに多くの.nfsXXXX ...（xxxは16進数）が表示され、アプリケーションが1時間ごとのファイルを書き込み、後で別のファイル名に移動するのを見ました。 これらのファイルは何ですか？何かおかしくなった兆候ですか？さらに診断する方法は？
38 unix  filesystems  nfs 
7
lost + foundを削除するとどうなりますか
ext3などのLinuxファイルシステムを作成すると、「lost + found」ディレクトリが作成されます。ある種のシステムクラッシュによりファイルが破損した場合、このファイルはそこに配置されます。 このディレクトリが削除され、システムがクラッシュするとどうなりますか。フォルダが削除された場合、mkdir lost + foundを使用して新しいディレクトリを作成できますか、またはファイルシステムの作成時にのみ設定できる属性があります。
3
fsckはいつ危険ですか？
最近、一貫性の問題の結果として、リモートデータセンターにあるマシンのルートファイルシステムが読み取り専用で再マウントされるのを見ました。 再起動時に、次のエラーが表示されました。 UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options) 提案どおりにfsckを実行しY、で手動で修正を受け入れた後、エラーは修正され、システムは正常になりました。 ここで、fsckがすべてを自動的に実行および修復するように構成されている場合、興味深いのは、場合によっては（このような）唯一の代替手段がリモートデータセンターに直接行き、影響を受けるマシンにコンソールを接続することだからです。 私の質問は、なぜfsckがデフォルトで手動の介入を要求するのですか？そのようなプログラムによって実行された修正がいつどのように安全でないのでしょうか？システム管理者が提案された修正をしばらくの間（他の操作を実行するために）残したい場合と、まとめて中止したい場合はどちらですか？
14
Linux-サーバーのバックアップ時に除外するディレクトリは何ですか？
Linuxサーバーをバックアップし、別のサーバーに保存しています。 私はシンプルな rsync -aPh --del server.example.com:/ /mnt/backup その後、誰かが別のサーバー/procを復元したくないので、バックアップしてはいけないと指摘し/procました。 他に含めるべき/すべきでないものはありますか？ たとえば、どう/sysですか？
2
ディスクに書き込めませんが、ディスクがいっぱいではありません
私はUbuntu 12.04を使用していますが、rootとしてもファイルに書き込むことができず、書き込みが必要な他の操作を実行できません。書き込む必要があるプロセスもできないため、すべて失敗します。df私は十分なスペースがあると言います： Filesystem Size Used Avail Use% Mounted on /dev/xvda1 30G 14G 15G 48% / udev 984M 4.0K 984M 1% /dev tmpfs 399M 668K 399M 1% /run none 5.0M 0 5.0M 0% /run/lock none 997M 0 997M 0% /run/shm 「ディスクに書き込むことができません」で私が見つけた結果はすべて、正当なフルディスクに関するものです。ここからどこから始めればいいのかさえ分かりません。問題は今朝どこからともなく現れた。 PHPの最後のログエントリは次のとおりです。 失敗：デバイスにスペースが残っていません（28） Vimのコメント： 書き込み用に（ファイル）を開けません 他のアプリケーションでも同様のエラーが発生します。 念のため〜1gbを削除しても、問題は残ります。私も再起動しました。 df -i 言う Filesystem …
8
NTFS Move / Copyの設計上の問題を回避する方法は？
ファイルサーバーのアクセス許可を扱った人なら誰でも知っているように、NTFSには、移動/コピーの問題として知られる興味深い設計機能/欠陥があります。 このMS KBの記事で説明されているように、フォルダーが移動され、ソースと宛先が同じNTFSボリューム上にある場合、フォルダーまたはファイルのアクセス許可は親から自動的に継承されません。フォルダーがコピーされた場合、またはソースと宛先が異なるボリュームにある場合、許可は継承されます。 以下に簡単な例を示します。 「技術者」と「マネージャー」と呼ばれる同じNTFSボリュームに2つの共有フォルダーがあります。技術者グループには技術者フォルダーへのRWアクセス権があり、管理者グループには「マネージャー」フォルダーへのRWアクセス権があります。両方にアクセスできるユーザーがいて、サブフォルダーを「マネージャー」フォルダーから「技術者」フォルダーに移動しても、移動されたフォルダーには「マネージャー」グループのユーザーのみがアクセスできます。「技術者」グループは、「技術者」フォルダの下にあり、上部から権限を継承する必要があるにもかかわらず、サブフォルダにアクセスできません。 想像できるように、これにより、これらのエンドユーザーの問題を解決するためのサポートコール、チケット、無駄なサイクルが発生します。もちろん、ユーザーが異なるセキュリティで保護されたフォルダー/エリア間でフォルダーを頻繁に移動する場合、最終的にアクセス権のネズミの巣ができます同じボリューム。 質問は次のとおりです。 このNTFS設計の欠陥を回避する最良の方法は何ですか？また、環境でどのように処理しますか？ リンクされたナレッジベースの記事では、Windows Explorerのデフォルトの動作を変更するためのレジストリキーについて説明していますが、それらはクライアント側であり、ユーザーが権限を変更する必要があることを必要としますファイルサーバーのアクセス許可（およびシステム管理者としての健全性）を制御したい。
11
分散ストレージファイルシステム-すぐに使用できる製品はどれですか？
HadoopとCouchDBのすべての上のブログで、実際に動作することを分散フォールトトレラントストレージ（エンジン）何の関連ニュース。 CouchDBには実際には配信機能が組み込まれていません。私の知る限り、エントリやデータベース全体を自動的に配信するための接着剤はありません。 Hadoopは非常に広く使用されているようです-少なくともそれは良い評価を得ていますが、それでも単一障害点：NameNodeです。さらに、FUSEを介してのみマウント可能です。HDFSは実際にはHadoopの主な目標ではないことを理解しています GlusterFSには何も共有されていないという概念がありますが、最近、私はそれがそれほど安定していないという意見に導くいくつかの投稿を読みました また、Lustreは専用のメタデータサーバーを使用するため、単一障害点もあります。 Cephは選択したプレーヤーのようですが、ホームページではまだアルファ段階にあると述べています。 質問は、どの分散ファイルシステムに次の機能セットがあるかです（特定の順序はありません）。 POSIX互換 ノードの簡単な追加/削除 シェアードナッシングのコンセプト 安価なハードウェア（AMD GeodeまたはVIA Edenクラスのプロセッサー）で実行 認証/認可ビルトイン ネットワークファイルシステム（異なるホストに同時にマウントできるようにしたい） 持ってうれしい： ローカルでアクセス可能なファイル：標準のローカルファイルシステム（ext3 / xfs / whatever ...）でパーティションをマウントしてノードをマウントしても、ファイルにアクセスできます。 私はしていない、ホストされたアプリケーションのために、私は私達のハードウェアボックスのそれぞれの10ギガバイトを言う取り、私たちのネットワークで利用可能なそのストレージを持って、簡単に多数のホストにマウントすることができますではなく、何かを探しています。
5
最新のファイルシステムで何百万ものファイルのパフォーマンスにどのような影響がありますか？
ext4（dir_indexを有効にした）を使用して約3Mファイル（平均750KBサイズ）をホストし、使用するフォルダースキームを決定する必要があるとしましょう。 で最初のソリューションは、我々はファイルにハッシュ関数を適用し、（最初のレベルのための1つの文字と第二のレベルに2つの文字である）フォルダ二つのレベルを使用しますので、というfilex.forハッシュに等しいabcde1234、我々は上/パスに保存します/ a / bc /abcde1234-filex.for。 第二の溶液、我々はファイルにハッシュ関数を適用し、（最初のレベルのために2つの文字及び第レベルに2つの文字である）フォルダ二つのレベルを使用します。したがって、あるfilex.forハッシュに等しいabcde1234を、我々はそれを保存します/パス/ ab / de /abcde1234-filex.for。 最初のソリューションでは、フォルダー（ファイルが存在する最後のフォルダー）あたり平均732ファイルの次のスキーム/path/[16 folders]/[256 folders]を使用します。 2番目のソリューションでは/path/[256 folders]/[256 folders]、フォルダーごとに平均45個のファイルがあります。 このスキーム（基本的にはnginxキャッシングシステム）からファイルの書き込み/リンク解除/読み取り（ただしほとんどは読み取り）を行うことを考えると、いずれかのソリューションを選択した場合、パフォーマンスの意味で重要ですか？ また、この設定を確認/テストするために使用できるツールは何ですか？
1
大きなファイルの削除に時間がかかるのはなぜですか？
私の理解ではrm、ファイルで実行すると、単にリンクが解除され、ファイルシステム内の空きスペースとしてマークされます。1つのファイルの削除には常にほぼ同じ時間がかかります（つまり、削除速度はファイルのサイズではなくファイルの数に比例します）。 では、なぜ15 GBファイルを削除するのに1分以上かかるのは簡単rm file.tar.gzですか？
9
完全なディレクトリ構造を比較（差分）する最良の方法は？
ディレクトリ構造を比較する最良の方法は何ですか？ rsyncを使用するバックアップユーティリティがあります。ソースとバックアップの正確な違い（ファイルサイズと最終変更日）を教えてください。 何かのようなもの： Local file Remote file Compare /home/udi/1.txt (date)(size) /home/udi/1.txt (date)(size) EQUAL /home/udi/2.txt (date)(size) /home/udi/2.txt (date)(size) DIFFERENT もちろん、ツールは既製のものでも、Pythonスクリプトのアイデアでもかまいません。 どうもありがとう！ ウディ
3
XHELファイルシステムはRHEL / CentOS 6.xで壊れています-どうすればいいですか？
RHEL / CentOS（EL6）の最近のバージョンは、私が10年以上にわたって強く依存してきたXFSファイルシステムにいくつかの興味深い変更をもたらしました。昨年の夏の一部で、文書化されていないカーネルバックポートに起因するXFSスパースファイルの状況を追いかけました。EL6に移行してから、不幸なパフォーマンスの問題や一貫性のない動作をしている人もいます。 XFSは、デフォルトのext3ファイルシステムよりも安定性、スケーラビリティ、および優れたパフォーマンスの向上を提供したため、データおよび成長パーティションのデフォルトのファイルシステムでした。 2012年11月に表面化したEL6システム上のXFSに問題があります。アイドル状態でも、サーバーが異常に高いシステム負荷を示していることに気付きました。あるケースでは、アンロードされたシステムは、3 +の一定のロード平均を示します。他では、負荷に1+のバンプがありました。マウントされたXFSファイルシステムの数は、負荷増加の重大度に影響するように思われました。 システムには2つのアクティブなXFSファイルシステムがあります。影響を受けるカーネルへのアップグレード後、負荷は+2です。 深く掘り下げてみると、XFSメーリングリストxfsaildで、STAT D状態にあるプロセスの頻度が増加していることを示すスレッドがいくつか見つかりました。対応するCentOSバグトラッカーとRed Hat Bugzillaのエントリは、問題の詳細を概説し、これはパフォーマンスの問題ではないと結論付けています。2.6.32-279.14.1.el6より新しいカーネルでのシステム負荷のレポートのエラーのみ。 WTF？！？ 1回限りの状況では、負荷レポートは大した問題ではないかもしれないことを理解しています。NMSと数百または数千のサーバーで管理してみてください！これは、2012年11月にEL6.3のカーネル2.6.32-279.14.1.el6で特定されました。カーネル2.6.32-279.19.1.el6および2.6.32-279.22.1.el6はその後の月（2012年12月および2013年2月）にリリースされ、この動作は変更されていません。この問題が確認されてから、オペレーティングシステムの新しいマイナーリリースがありました。EL6.4がリリースされ、現在カーネル2.6.32-358.2.1.el6上にあり、同じ動作を示しています。 新しいシステムビルドキューがあり、問題を回避する必要がありました。EL6.3の2012年11月以前のリリースでカーネルバージョンをロックするか、ext4またはZFSを選択してXFSを使用しないだけで、パフォーマンスが大幅に低下します。上で実行される特定のカスタムアプリケーション用。問題のアプリケーションは、アプリケーション設計の欠陥を説明するために、XFSファイルシステム属性のいくつかに大きく依存しています。 Red Hatのペイウォール付きナレッジベースサイトの背後に行くと、次のようなエントリが表示されます。 カーネル2.6.32-279.14.1.el6をインストールした後、高い負荷平均が観察されます。平均負荷が高いのは、xfsaildが各XFS形式のデバイスでD状態になるためです。 現在、この問題の解決策はありません。現在Bugzilla＃883905で追跡されています。回避策インストールされたカーネルパッケージを2.6.32-279.14.1より前のバージョンにダウングレードします。 （RHEL 6.4のオプションではないカーネルのダウングレードを除く...） したがって、EL6.3またはEL6.4 OSリリースに対して実際の修正は予定されておらず、この問題に4か月以上かかります。EL6.5の修正案と利用可能なカーネルソースパッチがあります...しかし、私の質問は次のとおりです。 アップストリームのメンテナーが重要な機能を壊した場合、OSが提供するカーネルとパッケージから離れることはどの時点で意味がありますか？ Red Hatはこのバグを導入しました。彼らはすべき errataカーネルに修正を組み込みます。エンタープライズオペレーティングシステムを使用する利点の1つは、一貫性のある予測可能なプラットフォームターゲットを提供することです。このバグは、パッチサイクル中にすでに実稼働中のシステムを混乱させ、新しいシステムの展開に対する信頼性を低下させました。提案されたパッチのいずれかをソースコードに適用できますが、それはどれほどスケーラブルですか？OSの変更に合わせて更新を続けるには、ある程度の警戒が必要です。 ここで正しい動きは何ですか？ これはおそらく修正できるかもしれませんが、いつかは修正できません。 Red Hatエコシステムで独自のカーネルをサポートするには、独自の注意事項があります。 サポートの資格に与える影響は何ですか？ 適切なXFS機能を得るために、新しくビルドされたEL6.4サーバーの上に動作中のEL6.3カーネルを単にオーバーレイする必要がありますか？ これが正式に修正されるまで待つ必要がありますか？ これは、エンタープライズLinuxのリリースサイクルに対するコントロールの欠如について何と言っていますか？ XFSファイルシステムに長い間依存していたのは、計画/設計の間違いですか？ 編集： このパッチは、最新のCentOSPlusカーネルリリース（kernel-2.6.32-358.2.1.el6.centos.plus）に組み込まれました。私はこれをCentOSシステムでテストしていますが、これはRed Hatベースのサーバーにはあまり役立ちません。
4
ext4の「クイック」フォーマットなどはありますか？
Windowsでは、NTFSでフォーマットするのは非常に高速です。RAMの少ない低電力のLinuxマシンがあります。2TBボリュームをext4にフォーマットするには、長い時間がかかります。 フォーマットを高速化するためにできることはありますか？何がそんなに時間がかかるか想像できませんか？（何がそんなに時間がかかる）
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.