[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <20080623205501.GW6239@webber.adilger.int>
Date: Mon, 23 Jun 2008 14:55:01 -0600
From: Andreas Dilger <adilger@....com>
To: Holger Kiehl <Holger.Kiehl@....de>
Cc: Theodore Tso <tytso@....edu>, Eric Sandeen <sandeen@...hat.com>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
Jan Kara <jack@...e.cz>, Solofo.Ramangalahy@...l.net,
Nick Dokos <nicholas.dokos@...com>, linux-ext4@...r.kernel.org,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Performance of ext4
On Jun 20, 2008 09:21 +0000, Holger Kiehl wrote:
> When the benchmark runs it writes to stdout and with tee to the result
> file. It first writes some information about the system, prepares the
> test files (creates lots of small files), calls sync and then starts
> the test. Then every minute one line gets written to the result file.
> Often I have seen that everything after the sync was missing. But
> sometimes it happened that some parts at the end are missing. But it
> was always a clean cut, that is there where no lines that where cut
> partially. The lines where always complete.
Could you enhance your test to record the file size from "stat -c %s {file}"
at the end of the test, and also "dumpe2fs -c -R 'stat <inum>' {dev}"
where <inum> is from "stat -c %i {file}". If these two don't match after
60s, or after a "sync; sync" then there will likely be a data loss.
With delalloc it is expected that the "debugfs" output will not match up
to 30s+ after the last modification, because the write is only in memory.
With ext3 this window would be much smaller, and in fact not visible from
userspace because "debugfs" would be accessing the same (in memory) buffer
as the kernel, so it can't even access the stale data on disk.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
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