問題タブ [ext3]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
537 参照

linux - Linux API - EXT3 ファイル情報

私はバックアップソフトウェアを書いています。前回からファイルが変更されているかどうかをプログラムで判断したいと考えています。EXT3 ファイルシステムの下にあるファイルにフラグまたはそのようなものはありますか?

0 投票する
1 に答える
208 参照

linux - ファイルの書き込みは非常に高速で、ファイルの上書きにははるかに時間がかかります

Linux Fedora Core 11ボックスでPHP スクリプトを使用すると、いくつかのパフォーマンスの問題が発生することがわかったので、いくつかのコマンドを実行してボトルネックを探していました。私が気づいたことの 1 つは、ファイルの書き込みが非常に高速であることです。

ただし、上書きにははるかに時間がかかります。

何故ですか?(これらの結果を繰り返すことができます。)

0 投票する
1 に答える
510 参照

directory-structure - Web アプリケーションの理想的なディレクトリ構造

ユーザーベースの Web サイトを作成しようとしており、各ユーザーの写真、ドキュメント、およびその他のデータを保存する必要があります。

1 000 000 000 ユーザーのようなばかげた数字を取るとしたら、1 000 000 000 のフォルダーが世界最速のものになるとは思えません。だから私は次のようなものを作成することを考えていました

1 レベル : [az] 2 レベル : [az] 3 レベル : [az]

したがって、ボビーは /b/o/b/by になります

ただし、これは、az で始まるユーザーが非常に少なく、am、s、l ... で始まるユーザーが非常に少ないため、均等に拡散されないことも意味します。

なので、「000000000001」「000000000001」などのユーザーIDを使おうと思っていたのですが…

第 1 レベル : [000-999] 第 2 レベル : [000-999] 第 3 レベル : [000-999]

したがって、ユーザー 000000000001 のデータは /data/000/000/000/001 に保存され、各レベルに最大 1000 個のフォルダーが確実に作成されます。

あなたはそれについてどう思いますか、私がすべきこと、すべきでないことは何ですか?

サーバーは RAID 1 で EXT3 を使用して Centos 5.4 を実行します。I/O があまりにも悪い場合は、おそらく RAID 10 を使用します。

0 投票する
2 に答える
875 参照

mysql - SELECT ワークロードが 100% の MySQL に最適な Linux ファイルシステム

テーブルごとに数百万行を含む MySQL データベースがあり、合計で 9 つのテーブルがあります。データベースは完全に読み込まれ、私が行っているのは読み取りだけです。つまり、INSERT や UPDATE はありません。データは MyISAM テーブルに保存されます。

このシナリオを考えると、どの Linux ファイル システムが最適でしょうか? 現在、私はxfsを持っています。しかし、どこかで xfs の読み取りパフォーマンスがひどいと読みました。本当?データベースを ext3 ファイル システムに移行する必要がありますか?

ありがとう

0 投票する
5 に答える
3144 参照

linux - Linux で 1 つのディレクトリ内のファイル数をすばやく見つける方法

Linux のディレクトリ内のファイル数をすばやく見つける方法を探しています。

ディレクトリ内のファイルの数に比例して時間がかかるソリューションは受け入れられません (たとえば、「ls | wc -l」など)。ディレクトリ内のファイル)。

ディレクトリ内のファイルの数は、ディレクトリエントリを格納するために使用されるデータ構造の一部として、ファイルシステム構造 (おそらく i ノード?) のどこかに単純な数値として格納する必要があると確信しています-どうすればこの数値に到達できますか?

編集:ファイルシステムはext3です。これを行う移植可能な方法がない場合は、ext3 に固有の方法を実行したいと考えています。

0 投票する
2 に答える
230 参照

filesystems - Windows 用の適切な extN ドライバーがないのはなぜですか?

ext2/3/4 ファイルシステムを読み取る Windows 用の適切なドライバーがないのはなぜですか? グーグルで調べてみると、そこには 2 つまたは 3 つあることが示されていますが、それらすべてに問題があります。マイ コンピュータを開いて、NTFS や FAT のように extN パーティションを操作できるようにするコードを正しく作成するのが困難な、技術的な矛盾はありますか? オープン ソースと標準の利点の 1 つは、このような問題がかなり迅速に解決されることだと思いました。

0 投票する
2 に答える
166 参照

mysql - データベース テーブルのパーティショニングにはどの粒度を選択しますか?

MySQL データベースに 2000 万のレコード テーブルがあります。適切なインデックスを設定したため、SELECT は非常に高速に動作しますが、INSERT および UPDATE 操作は非常に遅くなります。データベースは、負荷の高い Web アプリケーションのバックエンドです。このテーブルには 5 つのインデックスがあり、現在のインデックス サイズは約 1GB であるため、INSERT と UPDATE は非常に低速です。計算に時間がかかると思います。

この問題を解決するために、テーブルを分割することにしました。私は MySQL 4 を実行しており、アップグレードできません (サーバーを直接制御できない) ため、手動でパーティショニングを行い、セクションごとに個別のテーブルを作成します。

データセットは、約 18000 の異なる論理スライスから構成されており、完全に個別にクエリを実行できます。したがって、(maindata1、maindata2 など) という名前の 18000 個のテーブルを作成できました。しかし、これが最適な方法であるかどうかはわかりませんか?手動で何かをしたいときはいつでも、管理ツールで 18000 項目をブラウズしなければならないという明らかな事実に加えて、ファイル システムのパフォーマンスが心配です。ファイルシステムはext3です。36000 個のファイル (データ ファイルとインデックス ファイルがあります) を含むディレクトリ内のファイルを見つけるのがどれほど速いかはわかりません。

これが問題になる場合は、データの一部を結合して同じテーブルにすることができます。例: maindata10、maindata20 など。maindata10 にはスライス 1、2、3...10 が含まれます。10 の「グループ」を使用する場合、テーブルは 1800 しかありません。20 個をグループ化すると、900 個のテーブルが得られます。

このグループ化の最適なサイズ、つまりディレクトリ内のファイルの数とテーブルのサイズはどうなるのだろうか?

編集:複数の別々のデータベースを使用してファイルをグループ化することも良い考えではないかと思います. したがって、18000 個のテーブルがあったとしても、それらを 600 個のテーブルを持つ 30 個のデータベースにグループ化できます。これでだいぶ管理しやすくなりそうです。複数のデータベースを使用することで、パフォーマンスやメモリ フットプリントが増減するかどうかはわかりません (ただし、バックアップと復元が複雑になります)。

0 投票する
1 に答える
140 参照

php - ファイル システムの最適化 (ext3)

リクエストごとに1つのiniファイルと少なくとも10個のPHPファイルをロードするPHPアプリケーションがあります。

これらの同じファイルはリクエストごとにロードされるため、RAM ディスクにマウントすることを考えましたが、Linux ファイリング システム (ext3) は基本的に何らかの方法でファイルをキャッシュするため、RAM ディスクではパフォーマンスが向上しないと言われました。

誰でもこれを確認し、実際に何が起こっているのか説明できますか?

どうもありがとう。

0 投票する
2 に答える
2726 参照

filesystems - ファイル名の長さは、ディスクの残りのストレージスペースにどのように影響しますか?

ファイル名の長さは、ディスクの残りのストレージスペースにどのように影響しますか?

これはファイルシステムに依存していることに気づきました。特に、EXTシリーズのファイルシステムについて考えています。iノードがディスクスペースにどのように影響し、ファイル名自体がどのように保存されるかを完全には理解していません。この質問に関連する検索結果を取得することも困難です。だから私はここで尋ねています。Linuxでは、ファイル名の最大長は通常255文字または256文字です。ファイルシステムが作成されるとき、その量のスペースはすべてのファイル名に対して「予約」されていますか?つまり、最大値がすでに使用されているため、ディスクストレージは実際のファイル名の影響を受けませんか?それともそれよりも複雑ですか?

「joe.txt」という名前のファイルがあり、その名前を「joe2.txt」に変更するとします。この後、使用可能なディスク容量は減少しましたか?「joe_version.txt」や「joe_original_version_with_bug_that_Jim_solved.txt」のような長い名前はどうですか?8、16、32、64などの文字のしきい値が心配です。何百万もの画像を保存します。私はこれまでそのような問題について心配することを気にしたことがないので、これがどのように機能するのか完全にはわかりません。

私が使用しているファイルシステムはEXTだけですが、FATなどについて話し合うことは、同様の質問をしている他の人にとって役立つかもしれません。

0 投票する
3 に答える
1708 参照

filesystems - ext3 でディレクトリを「デフラグ」する方法は?

ディレクトリ内のファイルを分析して削除するデーモンを実行しています。何らかの理由でデーモンが実行されていない場合、ファイルがスタックされます。今日、そのディレクトリには90kのファイルがありました。デーモンを再起動すると、すべてのファイルが処理されました。

ただし、ディレクトリは大きいままです。「ls-dh」5.6M のサイズを返します。そのディレクトリを「最適化」するにはどうすればよいですか? そのディレクトリの名前を変更し、同じ名前と権限で新しいディレクトリを作成すると問題が解決することはすでにわかっています。ただし、ファイルは常にそこに書き込まれるため、ディレクトリの名前を変更して新しいディレクトリを作成する安全な方法はないようです。しばらくの間、ターゲット ディレクトリは存在しません。

a) ext3 ファイルシステム上のディレクトリを最適化できる方法/(シェル) プログラムはありますか? または b) ディレクトリにロックを作成して、名前の変更/作成が完了するまでファイルの書き込みをブロックする方法はありますか?