ext3の最大ファイルサイズは2TBでなく16GB?!
(Last Updated On: 2016年2月24日)24GBのファイルをコピーしようとしてエラーになり??な話です。大きなファイルを使いそうなファイルシステムにはXFSを利用していたので気が付きませんでした。 sshfsでマウント先のファイルシステムにコピーしようとしたら16GBでエラー、クラッシュした為と思いますが勝手にumountされました。sshfsの制限かな?とscpにしても同じ、4GBにsplitしてコピー後にcatしても16GBちょうどでエラーなのでググるとKernel 2.4の制限が出てきました。 http://www.ussg.iu.edu/hypermail/linux/kernel/0403.3/1673.html Depends upon the block size. Block size file size 1 kb 16 GB 2 kb 256 GB 4
Linuxでストレージのラベルを確認・変更する - Akionux-wiki
概要 Linuxでストレージデバイスのラベルを確認・変更する。 確認環境 Slackware Linux 14.1 デバイスの確認 lsblkで対象デバイスを確認。 % lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 596.2G 0 disk ├─sda1 8:1 0 25G 0 part ├─sda2 8:2 0 250.1G 0 part /mnt/sda2 ├─sda3 8:3 0 317G 0 part / └─sda4 8:4 0 4.1G 0 part [SWAP] sdb 8:16 1 59.8G 0 disk └─sdb1 8:17 1 59.8G 0 part /run/media/akio/Plamo5.1x64 sdc 8:32 0 1.8T 0 disk └─sdc1 8:33 0 1.8T 0 pa
Haizara-Cho::Kouen 5[Moriharu Tomizawa] :: ハードディスクの前回のマウントが将来時刻になった場合、fsckを
ハードディスクの前回のマウントが将来時刻になった場合、fsckを 実行すると良い場合もある。 (Linuxは何事も自己責任、ご注意ください。特にfsckは、アンマウントとか、シングルユーザーモードとかよく調べてから。) 私の体験したのは、debian squeeze amd64で起動時に、 Superblock last mount time (日付・時刻・年, now = 日付・時刻・年) is in the future. の表示のうち、前回のマウント時刻が次の月にずれるというものだった。時間が合わないので、そのまま起動が続けられない。「fsckをしろ」とは表示されるものの、そうしてよいものか？ 普通はUTCの受け入れができていないとかで、そこを直せば良いのだが、こういう例は検索してもなかった。だから書く価値があると思うので、書くが、現時点でこの条件であるので、他の場合は参考程度に考え
EXT4 vs XFS vs Btrfs vs ZFSをfioでベンチマークを取ってみました。 - Qiita
概要 CentOS7のデフォルトのファイルシステムがXFSとなりました。 mkfsコマンドでも、minix, xfs, btrfsが使えるようになりました。 そこで気になるファイルシステムを色々調べ、ベンチマークを自分なり取ってみました。 多少なりともご参考になればと思います。 色々なファイルシステム こちらをご参考ください。 http://qiita.com/sion_cojp/items/c8e015db39ddbf43012e それぞれファイルシステムを作ってみる 今回の環境は CentOS6（ホスト） 4Core, MEM:32G, HDD:300G CentOS7（ゲスト。こちらで計測しております。） vCPU *1, MEM:4G, HDD:40G 容量が少なかったため、btrfsのベンチマークが終わった後、zfsにファイルシステムを変更し検証をしております。 ### zfsの
WindowsからLinuxのファイルシステムを扱える「Ext2Fsd」
Open source ext3/4 file system driver for Windows (2K/XP/VISTA/WIN7) 7月9日(米国時間)、Ext2Fsdの最新版となる「Ext2Fsd 0.51」が公開された。Ext2FsdはWindowsプラットフォームからExt2、Ext3、Ext4でフォーマットされたボリュームを扱うためのファイルシステムドライバ。GPLv2のもとでフリーソフトウェアとして配布されている。 Ext2Fsd 0.51で注目されるのは、これまでサポートされていなかったExt4ボリュームに対する書き込みが可能になった点にある。UbuntuやFedoraなど人気のあるディストリビューションは今のところExt4をデフォルトのファイルシステムとして採用している。Ext2FsdがExt4への書き込みをサポートしたことで、こうしたOSのファイルシステムをWindo
LinuxでUSBメモリ等の中のvfat/ntfsのラベル付け方法 (blog@browncat.org)
blog@browncat.org Web, Linux, Ubuntu, Mac, PDA, 携帯電話, プログラミング, ソフトウェア＆落書き 最近大容量で低価格化していることと、eeepcから使いやすいため手持ちのUSBメモリやらメモリカードやらの外部記憶がやたら増えてきました。そうなると困るのがいったいこれはなに？というところ。ボリュームラベルにわかりやすい名前をつけることが出来ると少しは整理しやすくなるかもと思い調べてみました。 RenameUSBDrive -- Editing ext2/ext3/JFS/ReiserFS/XFS/FAT32/NTFS Partition Labels なんともそのものずばりな内容がubuntuのhelpで見つかりました。まだ日本語になっていないようなのでext2/3とntfs、vfatを抜粋＆メモ。動作確認はUbuntuで行いました。 以下す
Keeping filesystem images sparse
Filesystem images in local files can be used by many PC emulators and virtual machines (user-mode Linux, QEMU and Xen, to name but three). Typically these filesystems are created as sparse files using commands like: dd if=/dev/zero of=fs.image bs=1024 seek=2000000 count=0 /sbin/mke2fs fs.image where the enormous seek value causes dd to move forward by 2GB before writing nothing at all. This result
Ubuntu 12.04時代のファイルシステムの選び方 ext4でいいじゃん編 - 旧ID:itiriのブログ
※2013年1月3日、ext2/3/4を更新。 ※2012年11月14日、NTFSの欠点を追加。 行っとけ！ Ubuntu道場！ ― 第55回 〜師範、Ubuntu 12.04の特徴を教えてください！〜 ↑の記事の3ページ目にXFSのことが書いてあった。 hito：むしろXFSが安心して使えるようになることの方が大きいかなぁ。 hito：XFSって、わりとメモリ食うんですよ。 で、システム内のメモリがなくなってきたりするとですね……。 Linux全般でどんな挙動になるでしょう、そこのやまねさん。 やまね：キャッシュやバッファを始末するために、 メモリ上に貯めてるものを「追い出す」動作がかかるね。 hito：で、その「追い出す」先がXFSだったりするわけですね。 hito：そうすると何が起こるかっつーと、 「メモリが足りない→XFS領域にデータを書きだそうとする→XFSがメモリを要求する」と
Linuxのstableカーネルにext4をぶっ壊すバグが発見される
[Phoronix] EXT4 Data Corruption Bug Hits Stable Linux Kernels このバグは、3.6.2でもたらされ、以前の安定版カーネルにもback-portされているので、3.4の最新の安定版カーネルにまで影響が及ぶらしい。 Theodore Ts'oによれば、この問題は、カーネルを短期間で二度正常にリブートすることで起こるのだそうだ。そのため、一般の普通のディストロを使っている利用者は、まずこのバグに出くわすことはない。しかし、サスペンドやハイバネートのかわりにリブートを使うラップトップ利用者や、カーネル開発者には、容易に問題が起こりうるのだとか。 なんだかだいぶ反響があるので追記。Theodore Ts'oのメールより LKML: Theodore Ts'o: Re: Apparent serious progressive ext4 da
相方が携帯紛失 » Blog Archive » ext3とext4比較
ext3とext4って何が変わったのかようしらんかったのでついでに違いを調べてみた。 ファイルシステムの最大サイズが16TBから1EB（1,048,576 TB）に ファイルの最大サイズが2TBから16TBに 最大サブディレクトリ数が32000から無制限に ファイルのデータへの参照方法が間接ブロックマッピングからエクステントに（前のエントリの下のほう参照） ファイルシステムへのデータの配置時、ブロックアロケータが1ブロックずつではなくたくさんのブロックに配置できるように（マルチブロックアロケーション） 遅延配置ができるように（ディレイドアロケーション） fsckが2から20倍の早さに ジャーナルにチェックサムつけるようになって信頼性向上 ジャーナルを使わないモードも指定できる オンラインデフラグが可能に（未実装） inodeのデフォルトが256バイトになってナノ秒まで保持するように 持続的
Improving ext4: bigalloc, inline data, and metadata checksums [LWN.net]
Improving ext4: bigalloc, inline data, and metadata checksums Please consider subscribing to LWNSubscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net. It may be tempting to see ext4 as last year's filesystem. It is soli
ext4でSSDのTrimコマンドをつかう - かみぽわーる
SSDはNANDフラッシュメモリの上書きができないという特性上、空き領域が少なくなると性能が落ちてくるし、以下略*1なわけですが、Trimコマンドで論理的に削除された領域をSSDに伝えることで性能の劣化を抑制する効果が期待できる。 ext4ファイルシステムでTrimコマンドを有効にするには、discardオプションをマウント時に指定するとよいです。 sudo mount -t ext4 -o discard /dev/sdb1 /mntこれでめでたしめでたしと思いきや、ext3からext4にするとなんかえらい書き込み性能が落ちてて、これはどうやらext4ではデフォルトでライトバリアが有効になってるのが要因ぽいので、ext3だったころとおなじ感じで使うにはライトバリアを無効にする必要があります。 sudo mount -t ext4 -o discard,barrier=0 /dev/sdb
ext3のジャーナル(lost found)再作成
Linuxのext3ファイルシステムにあるlost+foundはファイルシステムのジャーナルです。これのおかげでfsckがすぐに終わります。これを間違って消した場合やおかしくなった場合は以下のようにして再作成ができます。 まずはファイルシステムをチェック # umount /dev/sdc1 # e2fsck -fn /dev/sdc1 ext2にいったん戻して、ext3に変換。 # tune2fs -O^has_journal /dev/sdc1 # tune2fs -j /dev/sdc1
Ext4, ついに安定版リリース at nkjmkzk.net
Oracle, Open Source, Private12/24にLinux kernel 2.6.28がリリースされました。このリリースの目玉としてExt4実装があります。Ext4はExt3と互換性を保ちながらも多くの改良がなされたものになっているようです。kernelnewbies.orgに記載されているNew featureを意訳してまとめてみました。 互換性 既存のExt3ファイルシステムはExt4にリフォーマットすることなく移行可能。具体的には該当ボリュームをReadOnlyでマウントしていくつかコマンド叩くだけでOK。 より大きなファイルシステムサイズ、ファイルサイズのサポート Ext3からExt4ではそれぞれの制限は以下の通り。 ファイルシステムサイズ：16TB -> 1EB (エクサバイト） ファイルサイズ：2TB -> 16TB ちなみにEBとは、 (1 EB = 10
MySQLのデータディスクにext4を利用する場合のメモ: n-streamからのお知らせ
CentOS 5.6からext4が正式に何とかって話しがあったので、大喜びで試してみている最中です。 あれこれやっている最中に気付いたのは、MySQLのwriteパフォーマンスが著しく悪い。適当にチェックしたところ数倍遅い。 で、調べてみたところ、ext4からデフォルトでオンになっているwrite barrierとやらがちゃんと働いている証のようで。 書き込み保障のレベルが上がる代わりに、速度を犠牲にする。だったっけ。 でも、そんなのはSSD辺りが贅沢に使える金持ちが使ってたらいいわけで、こいつをオフにして書き込み速度を確保します。 fstabでext4パーテーションに、オプションでdefaults,barrier=0,remountと付けてやるだけ。 これだけでMySQLの書き込みパフォーマンスがext3並に。 ちなみに、ファイル数が大量にある場所でのlsが早いー、なんてはしゃいでいたけ
続：やっぱ ext4 が遅いよね - Ghosthacks
結論からいうと、以下のパッチを当てた kernel-2.6.35.5-2m.mo7.x86_64 は全く性能の改善が見られなかった。 http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commit;h=863f5644fd142b4dab5c281b9d040f1633eba3b7 このパッチは linux-ext4 メーリングリストなどに流れた「ext4: fix 50% disk write performance regression」なる一連のスレッドから出てきたもの、だと思う。 http://patchwork.ozlabs.org/patch/63195/ Momonga Linux 7 のリリース前から気にしていたスレッドだったのだけど、Momonga における性能低下とはあまり関係なかったようで、少々がっか
革命の日々！ ext4は遅い ３杯目
こんどはカーネルコンパイル速度を比較したけど、やっぱりext3のほうが速かったよ。というお話。 From: Jan Blunck To: linux-ext4@vger.kernel.org Subject: kernel build time After Andreas talk yesterday I did some tests on my T61. This is not really a perfect benchmark setup but Andreas said I should send the data anyway. make clean (ext3) real 0m3.073s user 0m1.324s sys 0m1.444s make -j 4 (ext3) real 6m37.377s user 10m58.081s sys 1m38.890s make c
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
zerofree - Linux Man Pages (8)
OSS Message Pedia -mid:5689-
[debian-users:50893] Re: MBRを上書きしてしまいました。