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

ext4パーティションを正常にマウントできます。問題は、パーティション上のすべてのファイルがuserid 1000のユーザーによって所有されていることです。あるマシンではユーザーIDは1000ですが、別のマシンでは1010です。 、しかし、私はファイルシステムがユーザー名ではなくユーザーIDを保存することを理解しています。 次のような方法でファイルの所有権を修正できます。 find /mnt/example -exec chown -h 1010 {} \; しかし、この外部ドライブを別のマシンにマウントすると、ファイルの所有権を再び1000に修正する必要があります。 私が望んでいるのは、mountmap userid 1000 to 1010というオプションを提供することです。そうすれば、実際にファイルを変更する必要がなくなります。これを行う方法はありますか？

16 mount  ext4 

Linuxファイルシステムに数百万のテキストファイルを保存し、圧縮して任意のコレクションをサービスとして提供できるようにします。キー/値データベースのような他のソリューションを試しましたが、並行性と並列性の要件により、ネイティブファイルシステムを使用することが最良の選択です。 最も簡単な方法は、すべてのファイルをフォルダーに保存することです。 $ ls text_files/ 1.txt 2.txt 3.txt これは、フォルダ内のファイル数に制限のないEXT4ファイルシステムで可能です。 2つのFSプロセスは次のとおりです。 Webスクレイプからテキストファイルを書き込みます（フォルダー内のファイルの数に影響されません）。 ファイル名のリストで指定された、選択したファイルを圧縮します。 私の質問は、1つのフォルダーに最大1,000万個のファイルを保存すると、上記の操作のパフォーマンスや一般的なシステムパフォーマンスに影響しますか？

15 files  filesystems  performance  ext4 

私は、過去に多くの無名のシステムの最適化を行っているが、私はそれらのほとんどを処分した後にpowertop私は私のUSBポートを設定する必要が私に言った自動サスペンド、私はそれ以上のメリットが実現した後も、永遠の眠りにそれらを余儀なくされた、とswappinessをを。 しかし、今日、見ながら、/と/ homeの/etc/fstabオプションcommit=60を設定したことに気付きました。これはラップトップ向けの最適化であり、ディスクへの書き込み量を減らしてバッテリーを節約したことを覚えています。しかし、その後、これがデータ損失の原因になるのではないかと心配するようになりました（バッテリーが切断され、起動時にいくつかの孤立したiノードについて通知されることがあります）。fsck このオプションの説明を探しているときに、次の説明に行きました（2番目の説明は以前の理解と矛盾しているようです）。 $ man mount | awk '/commit=/,/^$/' commit=nrsec Sync all data and metadata every nrsec seconds. The default value is 5 seconds. Zero means default. https://forums.gentoo.org/viewtopic-p-4088752.html commit = 60は、読み取りの書き込みの「即時」（デフォルトは5秒）の優先順位付けを停止し、数秒後に書き込みをキャッシュします。これは、読み取りと書き込みが混ざり合っている状況で適切です。ユーザーが読み取りを優先するため、読み取りを続行する前に書き込みが終了するのを待つ間、一時停止するのではなく、プロセッサをビジーに保つことができます。 私が見た実世界の例は、Gnomeプルダウンメニューが表示されるのを数秒待っています。その理由は、ディスクが書き込みでビジーであったため、CPUは書き込みを終了してから、メニューを表示できるようにディスクからすべてのデータを取得する必要があったためです。 コミットは実際に何をしますか？応答性や省電力など、それを増やす利点は本当にありますか？実際にデータが失われる可能性がありますか？

14 mount  ext4  fstab  ext3 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前に閉鎖されました。 私はすべてのドキュメントをバックアップし、それを別々に保存するためにディスクを購入しましたが、Linuxで信頼性を高めたファイルシステムは何なのかわかりません。毎月1回バックアップし、常に接続されるわけではありませんが、データが確実に残るようにします。 たぶんext4？

14 filesystems  backup  ext4 

単一のext4ファイルシステム（LVMなどが含まれていない）を含むLUKS暗号化パーティションのサイズを変更しています。cryptsetupよくあるご質問は、古いパーティションを削除して再作成が、多くの時間を無駄ような音ことをすることをお勧めします。そのため、手動でパーティションのサイズを慎重に変更します。 これまでのところ、私はする必要があると思います： ファイルシステムの（暗号化された）バックアップを作成します。重要！次のタスクを実行している間、データを最初に失うことはありません。 既存のext4ファイルシステムをアンマウントします（ライブCDから起動するなど）。Live CDから起動する場合は、次を使用して暗号化パーティションをマウントしますcryptsetup luksOpen /dev/sdXY ExistingExt4 既存のext4ファイルシステムのサイズを変更します。 cryptsetup resize /dev/mapper/ExistingExt4 -b $SECTORS 閉じる/ LUKSパーティションを「アンマウント」する cryptsetup luksClose ExistingExt4 パーティションサイズを縮小します。 上記の手順は正しいですか？ ステップ4では、何を選ぶべき$SECTORSですか？このステップは必要ですか？cryptsetupマニュアルページには、本当にに記述されていないresizeオプション： resize <name> resizes an active mapping <name>. If --size (in sectors) is not specified, the size of the underlying block device is used. 最後に、ext4パーティションを15 GiB縮小すると、parted？を使用して15 GiBを既存のパーティションから削除できると安全に想定できますか？はいの場合、その方法は？それが重要な場合、私のディスクはGPTパーティション化されています。

14 partition  encryption  ext4  luks  cryptsetup 

私のext4ファイルシステムパーティションで、次のコードを実行できます。 fs="/mnt/ext4" #create sparse 100M file on ${fs} dd if=/dev/zero \ of=${fs}/sparse100M conv=sparse seek=$((100*2*1024-1)) count=1 2> /dev/null #show its actual used size before echo "Before:" ls ${fs}/sparse100M -s #setting the sparse file up as loopback and run md5sum on loopback losetup /dev/loop0 ${fs}/sparse100M md5sum /dev/loop0 #show its actual used size …

14 ext4  tmpfs  sparse-files 

私はluksOpenでLUKSパーティションを持っています：/dev/sda1--allow-discards cryptsetup --allow-discards luksOpen /dev/sda1 root 次にext4、discardオプションを使用してファイルシステムをマウントします。 grep /dev/mapper/root /proc/mounts /dev/mapper/root / ext4 ro,relatime,block_validity,discard,delalloc,barrier,user_xattr,acl 0 0 次に、マウントされたパーティションの空き領域をトリミングします。 fstrim -v / ではdf、/80％の空き容量があります。つまり/dev/sda1、では、ディスクの80％がバイナリゼロです。 で画像を複製した場合 cat cat /dev/sda1 > sda1.img そして、イメージをxzで圧縮すると、ディスク上のすべてのゼロが圧縮されるはずです。ディスク上のデータの20％は暗号化されているため、ランダムに見え、圧縮できないはずです。したがって、xzで圧縮されたイメージは約になります。未加工サイズの20％。 ただし、結果のxz圧縮イメージは、元の元のイメージとほぼ同じサイズです。 私の推論は正しいですか？ なぜ私の理論は実践に変換されないのですか？

13 ext4  ssd  cryptsetup  trim  fstrim 

マニュアルページにはbarrier、ext4 のオプションについて記載されています。 書き込みバリアは、ディスクへのジャーナルコミットの適切な順序付けを強制し、揮発性ディスク書き込みキャッシュを安全に使用できるようにしますが、パフォーマンスがいくらか低下します。ディスクが何らかの方法でバッテリバックアップされている場合、バリアを無効にするとパフォーマンスが安全に向上する場合があります。 バッテリー（およびSSD）を搭載したラップトップは、バッテリーバックアップディスクを搭載していると見なされますか？では、barrier=0ラップトップでext4を使用するのは安全ですか？

13 hard-disk  performance  ext4  laptop  cache 

関連した本。 OSスイッチを利用してBTRFSにアップグレードしたいと思います。 BTRFSは多くの機能を提供すると主張しています（データ損失の回復力、RAIDの場合の自己修復、メタデータとデータのチェックサム、圧縮、スナップショット）。しかしfsync、dpkg（私が知っeatmydataている、くだらないapt-btrfs-snapshotプログラム）などの集中的なプログラムで使用すると、遅くなり、RAIDをセットアップしません：p。 EXT4は、メタデータのチェックサムのみを許可し、データを圧縮しません。 6年で、HDDが破損したため（飛行旅行後）、OSを2回再インストールする必要がありました。最初のラップトップを起動不能にし、2番目の破損は、破損したフィルムとOSバイナリのmd5sumチェックのおかげで特定されました。（SMARTはディスクが正常であることを教えてくれます）。ラッピーは現在非常に奇妙に動作します。ハードウェアとソフトウェアのどちらが責任があるのか​​はわかりませんが、ハードウェアが疑われます（フライトの直後にすべてが再び始まりました）。 データ圧縮とチェックサムのため、ラップトップのBTRFSに切り替えることをお勧めしますか、またはEXT4に固執する必要がありますか？ （どの変数と比較してどちらが「最良」であるかは気にしませんが、BTRFSの経験がほとんどないため、フィードバックを希望します） 編集： レッツは、より明確になる：BTRFSはまだ私は、実験としてフラグが設定されている知っているが、SUSEは、それはもういけないと言います。Oracleも同様です（Oracleが誰であるかは知っています）。そして、多くのディストリビューションがすでにインストール用のBTRFSを提案しており、それらのほとんどは今後数か月でBTRFSに切り替えることを計画しています。 2つの事実： 破損したデータのバックアップは価値がありません。なぜ私がわざわざ唯一の人であるように見えるのか分かりません。それは常識ではありませんか？その間： バックアップを行うべきだと言って停止する：私はすでにやっています。 バックアップを暗示するのをやめるだけで、数年分のバックアップを行うためにTBの空き領域を与えてくれる場合を除き、データを安全に保つことができます。 破損したファイル= / => Linuxからの不満。そう： OSが起動しているという理由だけで、システム/データが正常であると想定しないでください。 データの整合性をチェックするために、BTRFSの半分の機能で不便なことになりますが、過剰に設計され肥大化したソフトウェアよりも（メタ）データチェックサムを好むことを理解してください。 どのFSが「優れている」かを尋ねていないので、それはより明確になりましたか？質問は、私が定期的にバックアップを行うことを考えると、BTRFSはまだ実験的すぎてデータの整合性チェック機能に使用できないのですか、それともEXT4に固執するべきですか？

13 linux  filesystems  ext4  btrfs 

最近、いくつかの不良セクターを開発したext4ファイルシステムがあります。実行するfsck.ext4 -cと、不良ブロックが検出され、記憶されます。バックアップから復元できるように、これらの不良ブロックが含まれているファイル（ある場合）を見つけるにはどうすればよいですか？

13 linux  ext4 

SDカードベースのデバイスでのクリーンでないシャットダウンに続いて、SDカードをfsckルートファイルシステムに取り出しました。これにより、以下のバリエーションが生まれました。 e2fsck 1.43.1 (08-Jun-2016) /dev/sdc2: recovering journal Superblock needs_recovery flag is clear, but journal has data. Run journal anyway<y>? no Clear journal<y>? no e2fsck: unable to set superblock flags on /dev/sdc2 ここでは両方とも「いいえ」と答えましたが、すぐに同じ結果につながらないはい/いいえのシーケンスはありません。 ファイルシステムはマウントすることができ、何気ない検査で大丈夫に見えます。これはデバイスでも正常に動作し、それがルートファイルシステムです（実際には、それほどうまくいかないことが判明しました。コメントを参照してください。回復不能な破損ディレクトリがいくつかあります）。 私はdd「ファイルへのパーティション（8ギガバイト）をD、およびその上でfsckを試してみました。興味深いことに： e2fsck 1.43.1 (08-Jun-2016) plush.rootfs: recovering journal Clearing orphaned inode 18290 (uid=0, gid=0, mode=0100644, size=34096) Clearing orphaned …

12 ext4  fsck  sd-card 

ではext4、ファイルシステム、それが思うfile1iノード番号を持ち1、そのfile2iノード番号を持っています2。さて、crtime利用可能なタイムスタンプに関係なく、それfile1がfile2inode 1がinode よりも小さいという理由だけではなく、それよりも前に作成されたと想定するのは間違ってい2ますか？

11 ext4  inode 

ext4USBスティックやメモリカードなどのファイルシステムを使用する際の問題は、別のシステムにマウントされたときに、ディスクのUID / GIDが存在しない可能性があることです。 これはマウントオプションで修正できますか？

11 filesystems  ext4 

Faux pas：私が以下に述べる「速い」方法は遅い方法より60倍速くはありません。30倍高速です。私は時間の間違いを非難します（午前3時は明確な思考のための私の最高の時間ではありません:)。 更新：テスト時間の要約を追加しました（下記）。 速度係数には2つの問題があるようです。 使用するコマンドの選択（以下の時間比較） ディレクトリ内の多数のファイルの性質...「大きいことは悪いこと」のようです。数値が増加するにつれて、物事は不均衡に遅くなります。 すべてのテストは100万のファイルで行われました。 （実時間、ユーザー時間、sys時間はテストスクリプトに含まれています） テストスクリプトはpaste.ubuntu.comにあります。 # # 1 million files # =============== # # |time |new dir |Files added in ASCENDING order # +---- +------- +------------------------------------------------- # real 01m 33s Add files only (ASCENDING order) ...just for ref. # real 02m 04s Add files, and make …

11 bash  filesystems  ext4 

fsck -p /dev/sda5ext4パーティションのエラーを修復するために実行しようとしていますが、コマンドの出力 fsck from util-linux-ng 2.17.2 fsck.ext4: Device or resource busy while trying to open /dev/sda5 Filesystem mounted or opened exclusively by another program? 使用/etc/mtabを確認しましたlsofが、パーティションが使用されておらず、マウントされていません。私はまたfuser -k /dev/sda5、ファイルを使用して何かを強制的に閉じたりumount、それをアンマウントして無益にしようとしたりしていました。 fsckパーティションがビジーと読み取られているにもかかわらず、パーティションを少なくともチェックし、できれば修復することを強制するにはどうすればよいですか？マウントも使用もされておらず、データの破損の可能性は問題ではないという十分な自信があると仮定します。 すべてのコマンドは、Ubuntu 10.04 32ビットliveCDからrootとして実行されました。パーティションは、Ubuntu 10.04 32ビットインストールのシステム（非ホーム）部分です。

11 ubuntu  ext4  fsck  unmounting