From: Eric Sandeen <sandeen@redhat.com>
To: ext4 development <linux-ext4@vger.kernel.org>
Cc: Theodore Tso <tytso@mit.edu>, Nick Dokos <nicholas.dokos@hp.com>
Subject: [PATCH e2fsprogs] handle large extent-based files in pass1
Date: Sun, 06 Jul 2008 23:02:47 -0500 [thread overview]
Message-ID: <48719567.1090404@redhat.com> (raw)
This:
# /root/truncate bigfile 14680064000000
Truncating bigfile to 14680064000000
# e2fsck /device
Pass 1: Checking inodes, blocks, and sizes
Inode 49154, i_size is 14680064000000, should be 0. Fix<y>?
is a bit unexpected. It's because the size is being checked
against the max sizes for bitmap files, not extent-based files.
Nick saw this with his 14TB file.
Patch below applies different size limits to the different
file formats.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
--
Index: e2fsprogs/e2fsck/pass1.c
===================================================================
--- e2fsprogs.orig/e2fsck/pass1.c 2008-06-16 11:50:08.877734863 -0500
+++ e2fsprogs/e2fsck/pass1.c 2008-07-06 22:53:52.712291253 -0500
@@ -1756,6 +1756,7 @@ static void check_blocks(e2fsck_t ctx, s
struct ext2_inode *inode = pctx->inode;
int bad_size = 0;
int dirty_inode = 0;
+ int extent_fs;
__u64 size;
pb.ino = ino;
@@ -1775,6 +1776,9 @@ static void check_blocks(e2fsck_t ctx, s
pctx->ino = ino;
pctx->errcode = 0;
+ extent_fs = (ctx->fs->super->s_feature_incompat &
+ EXT3_FEATURE_INCOMPAT_EXTENTS);
+
if (inode->i_flags & EXT2_COMPRBLK_FL) {
if (fs->super->s_feature_incompat &
EXT2_FEATURE_INCOMPAT_COMPRESSION)
@@ -1794,9 +1798,7 @@ static void check_blocks(e2fsck_t ctx, s
}
if (ext2fs_inode_has_valid_blocks(inode)) {
- if ((ctx->fs->super->s_feature_incompat &
- EXT3_FEATURE_INCOMPAT_EXTENTS) &&
- (inode->i_flags & EXT4_EXTENTS_FL))
+ if (extent_fs && (inode->i_flags & EXT4_EXTENTS_FL))
check_blocks_extents(ctx, pctx, &pb);
else
pctx->errcode = ext2fs_block_iterate2(fs, ino,
@@ -1892,8 +1894,14 @@ static void check_blocks(e2fsck_t ctx, s
(pb.last_block / blkpg * blkpg != pb.last_block ||
size < (__u64)(pb.last_block & ~(blkpg-1)) *fs->blocksize))
bad_size = 3;
- else if (size > ext2_max_sizes[fs->super->s_log_block_size])
+ else if (!(extent_fs && (inode->i_flags & EXT4_EXTENTS_FL)) &&
+ size > ext2_max_sizes[fs->super->s_log_block_size])
+ /* too big for a direct/indirect-mapped file */
bad_size = 4;
+ else if ((extent_fs && (inode->i_flags & EXT4_EXTENTS_FL)) &&
+ size > (1LL << (32 + fs->super->s_log_block_size) - 1))
+ /* too big for an extent-based file - 32bit ee_block */
+ bad_size = 6;
}
/* i_size for symlinks is checked elsewhere */
if (bad_size && !LINUX_S_ISLNK(inode->i_mode)) {
reply other threads:[~2008-07-07 4:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=48719567.1090404@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=nicholas.dokos@hp.com \
--cc=tytso@mit.edu \
/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.