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 kb
概要 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
ハードディスクの前回のマウントが将来時刻になった場合、fsckを 実行すると良い場合もある。 (Linuxは何事も自己責任、ご注意ください。特にfsckは、アンマウントとか、シングルユーザーモードとかよく調べてから。) 私の体験したのは、debian squeeze amd64で起動時に、 Superblock last mount time (日付・時刻・年, now = 日付・時刻・年) is in the future. の表示のうち、前回のマウント時刻が次の月にずれるというものだった。時間が合わないので、そのまま起動が続けられない。「fsckをしろ」とは表示されるものの、そうしてよいものか？ 普通はUTCの受け入れができていないとかで、そこを直せば良いのだが、こういう例は検索してもなかった。だから書く価値があると思うので、書くが、現時点でこの条件であるので、他の場合は参考程度に考え
#概要 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にファイルシステムを変更し検証をしております。 ### z
Before doing anything: backup your sensible data! To extend a partition and it’s filesystem, you have to: Extend the partition Extend the filesystem To shrink a partition and it’s filesystem, you have to: Shrink the filesystem Shrink the partition For an ext3 partition, simply use parted: parted /dev/sdx print resize N Parted doesn’t support ext4 (yet?). For an ext4 partition or if parted refuses
結論 ext4magic 最高！！！！１１１ やったこと % ext4magic “デバイス名に” -r -a “このunixtimeから” -b “このunixtimeまで存在していた” -f “このファイル名のファイルを復旧する” 実例 /dev/md0 上の昨日の20:00から20:30の間まで存在していた udonchan/backup.tar を復旧させたい % ext4magic /dev/md0 -r -a $(date -d "-1day 20:00 +%s") -b $(date -d “-1day 20:30 +%s) -f "udonchan/backup.tar" どうしてこうなった 年末なので OSX をクリーンインストールしようとして ~ をバックアップしたが間違って上書きして消した。 具体的に？ ~ をサーバ上にバックアップするぜ % tar cf -C /U
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
bl[email protected] 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で行いました。 以下す
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
※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がメモリを要求する」と
２０１１年３月４日（金）晴れ 今日も寒かった 以前にも書いたが、ext3は巨大ファイルの削除が遅い。WindowsのNTFSならあっという間に削除される。サーバOS(用途?)のLinuxがDISK I/O関係でWindowsに負けるなんて悔しいです。 それもDECのお下がりのNTFSに。。。 5GBのファイルを削除すると、私の環境では８秒かかる。BSの２時間ドラマのファイルであれば１６GBになり、３０秒近くかかる場合がある。おまけにファイル削除中は該当DISKへのアクセスが全て止まってしまう。ほんとシステム全体が止まった状態になる。 で、以前から対策ができなか調べていた。 最近、RegzaのHDDのファイルシステムがXFSであることが分かり、ext3からXFSにすれば削除が速いのでは？と思ったが、なんとネットで調べるとXFSは削除がext3より更に遅いらしい。 更に「ext3 削除 遅い」
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
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 It may be tempting to see ext4 as last year's filesystem. It is solid and reliable, but it is based on an old design; all the action is to be found in next-generation filesystems like Btrfs. But it may be a while until Btrfs earns the necessary level of confidence in the wider user community; meanwhile, ext4's growing user base has not
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
2008年05月11日06:09 ext3のジャーナル(lost+found)再作成 カテゴリext3IT技術 Linuxのext3ファイルシステムにあるlost+foundはファイルシステムのジャーナルです。これのおかげでfsckがすぐに終わります。これを間違って消した場合やおかしくなった場合は以下のようにして再作成ができます。 まずはファイルシステムをチェック umount /dev/sdc1 e2fsck -fn /dev/sdc1 ext2にいったん戻して、ext3に変換。 tune2fs -Ohas_journal /dev/sdc1 tune2fs -j /dev/sdc1 「ext3」カテゴリの最新記事
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
