From: Eric Sandeen <sandeen@redhat.com>
To: Utako Kusaka <u-kusaka@wm.jp.nec.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: BUG: i_size and i_blocks corruption on ext4 with ^huge_file
Date: Tue, 06 Sep 2011 10:58:59 -0500 [thread overview]
Message-ID: <4E664343.8020009@redhat.com> (raw)
In-Reply-To: <4E5AEF3B.8090207@wm.jp.nec.com>
On 8/28/11 8:45 PM, Utako Kusaka wrote:
> Hi,
>
> In ext4 with ^huge_file, s_maxbytes is 2199023251456. But when I create a file
> size of 2199023251456 bytes, i_size and i_blocks are corrupted.
>
> If a file size of 2TB is created, i_blocks including metadata blocks will be
> over 32bit.
For what sized filesystem block? 2T/4k is 2^29...
Oh right, i_blocks is 512 units in this case. :( Argh.
> So ext4_inode_blocks_set returns EFBIG, and i_size and i_blocks
> are not updated in ext4_do_update_inode.
Seems like this could get quite tricky.
What if there is a very badly fragmented file which requires a lot of metadata?
How could we calculate s_maxbytes to stop i_blocks from overflowing 32 bits?
In ext3 we could calculate metadata blocks for a given size, but not in this case...
I suppose we could refuse to add blocks if we would overflow, but then s_maxbytes
is misleading.
-Eric
> e.g. fallocate
>
> ext4_fallocate
> ext4_map_blocks
> ext4_falloc_update_inode
> ext4_mark_inode_dirty
> ext4_do_update_inode
> ext4_inode_blocks_set <---- error
>
>
> # uname -a
> Linux mcds1 3.0.0 #2 SMP Mon Aug 8 17:58:28 JST 2011 x86_64 x86_64 x86_64 GNU/Linux
> # mkfs -t ext4 -O ^huge_file /dev/vg0/lv0
> # mount /dev/vg0/lv0 /mnt/mp1
> # fallocate -o 0 -l 2199023251456 /mnt/mp1/testfile
> # stat /mnt/mp1/testfile
> File: `/mnt/mp1/testfile'
> Size: 2199023251456 Blocks: 4294967688 IO Block: 4096 regular file
> Device: fd00h/64768d Inode: 12 Links: 1
> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2011-08-09 10:20:31.008699267 +0900
> Modify: 2011-08-09 10:20:31.008699267 +0900
> Change: 2011-08-09 10:20:42.769699811 +0900
>
> # umount /mnt/mp1
> # e2fsck -ttf /dev/vg0/lv0
> e2fsck 1.41.12 (17-May-2010)
> Pass 1: Checking inodes, blocks, and sizes
> Inode 12, i_size is 2198888873984, should be 2199023251456. Fix<y>? yes
>
> Inode 12, i_blocks is 4294705232, should be 4294967688. Fix<y>? yes
>
> :
>
> --
> Utako Kusaka
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2011-09-06 15:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-29 1:45 BUG: i_size and i_blocks corruption on ext4 with ^huge_file Utako Kusaka
2011-09-06 15:58 ` Eric Sandeen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E664343.8020009@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=u-kusaka@wm.jp.nec.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).