ext4:まだテストされているか、すでに動作していますか?



Fedora 9の発表では、最初の行の1つがext4ファイルシステムの実験的サポートに言及しています。



この記事では、 ext3ファイルをext4に置き換えることがどのように役立つか、このステップを決定した場合にどのような追加リスクがあるかについて説明します。






より良いext4





技術的な詳細はこちらをご覧ください: ロシア語ext4

新しいext4機能



ext3からext4に切り替える方法



プロダクションバージョンでは、 ext3ext4としてマウントできます。 ここで、手順はもう少し複雑です。

ext3/ dev / sdc1にインストールします。 blkidを使用して、カーネルがファイルシステムを識別する方法を確認します。

 [root @ ad mnt]#blkid / dev / sdc1
 / dev / sdc1:LABEL = "/ var / www / img" UUID = "77d69541-cd2e-47d5-91fc-bdb5606aa8fb" SEC_TYPE = "ext2" TYPE = "ext3"




TYPE = "ext3"である限り、ext4でドライブをマウントすることはできません。 この問題を修正

 [root @ ad mnt]#debugfs -w / dev / sdc1
 debugfs 1.40.8(2008年3月13日)
 debugfs:set_super_value s_flags 4
 debugfs:終了




チェック:

 [root @ ad mnt]#blkid / dev / sdc1
 / dev / sdc1:LABEL = "/ var / www / img" UUID = "77d69541-cd2e-47d5-91fc-bdb5606aa8fb" SEC_TYPE = "ext2" TYPE = "ext4dev"




エラーはありません。ファイルシステムの名前ext4devです。



マウントできます:

 [root @ ad mnt]#mount -t ext4dev -o extents / dev / sdc1 ./test




ext4でパーティションをフォーマットする方法



 #mke2fs -E test_fs / dev / sdc1
 #tune2fs -j / dev / sdc1




ext4を使用するのが賢明な場合



/ var / lib / mysqlディレクトリにないことは確かです。

すべての写真コンテンツと同様に、 nginxキャッシュが追加されるセクションで既にext4devを使用しています(静的をnginxに送信する場合、ファイルシステムの速度が重要です)



それを危険にさらさないために、コンテンツをフォーマットして空のディスクにアップロードすることにより、ファイルシステムを変更しました。 この手順の間に、ちょっとおかしいことが起こりました。 ext3では、すべてのファイルが97Gを占めていましたが、新しいext4dev形式のパーティションにリロードした後、 90Gでした 。 私は半日と比較して、mcでフォルダ比較をカットしました-すべてがOKです:)。 保存が行われた理由は言えません。おそらくext3のデータは非常に断片化されていました(小さなファイルのディレクトリがたくさんありました)。



リスクは何ですか?



リスクは明らかです、これは実験的なサポートです-すべてが可能です!

ext2からext3にいつでも切り替えるとき、 ext3を拒否し、 ext3ext2としてマウントできます。すでにext4に切り替えている場合は、後戻りできません!

-o noextentsオプションを使用してマウントすると、すべてをext3にロールバックできますが、このオプションはほとんどすべてのext4チャームを切断します。



ファイルシステムの「収集」の場合、 tune2fsを使用する準備ができている必要があります。



/ tmpディレクトリをext4に変換することをすでに決めているかもしれません:)?



UPD1: fsckが機能するには、 fsck.ext3fsck.ext4にコピーします 。 さあ、実行しましょう

 #fsck.ext4 / dev / sdc1





All Articles