All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.