From: Eric Sandeen <sandeen@redhat.com>
To: Justin Maggard <jmaggard10@gmail.com>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: >2TB file issue with e2fsck
Date: Thu, 18 Mar 2010 16:38:30 -0500 [thread overview]
Message-ID: <4BA29D56.4040607@redhat.com> (raw)
In-Reply-To: <150c16851003181425s3cea7067o1505279f9d01b0a9@mail.gmail.com>
On 03/18/2010 04:25 PM, Justin Maggard wrote:
> Ran into an interesting issue, and thought I'd report it. I created a
> 4TB file using posix_fallocate() on a freshly-created ext4 filesystem,
> unmounted, and then ran e2fsck -f on it. Using e2fsprogs 1.41.9,
> e2fsck ran through with no issues. Versions 1.41.10 and 1.41.11,
> however, reported finding an error. Output was the same for both
> 1.41.10 and 1.41.11:
>
> e2fsck 1.41.10 (10-Feb-2009)
> Pass 1: Checking inodes, blocks, and sizes
> Inode 12, i_blocks is 8589935432, should be 840. Fix? yes
# bc
obase=16
8589935432
200000348
840
348
oops, so looks like another 32-bit overflow.
we go there if:
if ((pb.num_blocks != ext2fs_inode_i_blocks(fs, inode)) || ...
but:
struct process_block_struct {
ext2_ino_t ino;
unsigned is_dir:1, is_reg:1, clear:1, suppress:1,
fragmented:1, compressed:1, bbcheck:1;
blk_t num_blocks;
and:
typedef __u32 blk_t;
we can't fit 8589935432 into a u32; looks like this one needs a blk64_t
overhaul as well.
commmit 8a8f36540bbf5d4397cf476e216e9a720b5c1d8e added handling of
the high i_blocks number, but did not enlarge the container it
went into:
- if ((pb.num_blocks != inode->i_blocks) ||
+ if ((pb.num_blocks != ext2fs_inode_i_blocks(fs, inode)) ||
-Eric
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
>
> c: ***** FILE SYSTEM WAS MODIFIED *****
> c: 12/90523648 files (0.0% non-contiguous), 1079543383/1448361984 blocks
>
> I'm in the process of trying it again using dd to create the large
> file instead of posix_fallocate(), but I suspect the results will be
> the same. Writing out such a huge file using dd takes a lot longer,
> since as was discussed on this list a couple weeks ago, large
> sequential writes on ext4 max out around 350MB/s. :)
>
> -Justin
> --
> 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
next prev parent reply other threads:[~2010-03-18 21:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-18 21:25 >2TB file issue with e2fsck Justin Maggard
2010-03-18 21:38 ` Eric Sandeen [this message]
2010-03-18 21:57 ` Eric Sandeen
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=4BA29D56.4040607@redhat.com \
--to=sandeen@redhat.com \
--cc=jmaggard10@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.