[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CF9FF112-852A-473B-99E4-3A5B790AE147@mit.edu>
Date: Mon, 21 Nov 2011 07:10:45 -0500
From: Theodore Tso <tytso@....EDU>
To: Dave Chinner <david@...morbit.com>
Cc: Theodore Tso <tytso@....edu>, xfs@....sgi.com,
linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [RFC][PATCH 0/8] xfstests: rework large filesystem testing
On Nov 21, 2011, at 6:31 AM, Dave Chinner wrote:
> ext4, however, still has serious issues with this - either we take
> the mkfs.ext4 time hit to initialise all the block groups, or we
> take it during the preallocation. IOWs, the "don't do work at mkfs
> but do it after mount" hack^Wtradeoff simply does not work for
> testing large filesystems in this manner. While it is possible to
> run large filesystem tests on ext4 using this mechanism, it is
> extremely painful to do so.
For testing, we can disable the "do it after the mount " aspect
of ext4 by using the mount option "noinit_itable". We basically
only need to zero the inode table to make sure e2fsck doesn't
confuse old inode tables as new ones in the event that the block
group descriptors get compromised and we can't trust them to
determine the high watermark of inodes used per block group,
something which is only a concern in the case of kernel bugs
or hardware failures (or power failures in no journal mode).
(We could also compare the inode crime with the fs mkfs time
in the superblock, but ext4 gets used on desktops and
on things like android tablets where I've learned through
bitter experience that we can't trust the system clock to be
correct.)
In any case it's safe to turn of the inode table initialization for
testing purposes. In the long term, once we get checksums
into the inode table block, we won't need to zero out the inode
tables at all.
As far as xfstests are concerned, if there's a convenient way
to add mount options automatically (on a per file system
basis) when --large-fs is specified, we should be able to
make this work for ext4 file systems.
Regards,
-- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists