From: Andreas Dilger <adilger@sun.com>
To: Josef Bacik <jbacik@redhat.com>
Cc: "Bock, Tony" <tony.bock@intel.com>, linux-fsdevel@vger.kernel.org
Subject: Re: ext3 block layout after deleting previous drive contents
Date: Mon, 14 Apr 2008 13:46:25 -0600 [thread overview]
Message-ID: <20080414194625.GH3106@webber.adilger.int> (raw)
In-Reply-To: <20080408170809.GP22429@unused.rdu.redhat.com>
On Apr 08, 2008 13:08 -0400, Josef Bacik wrote:
> On Tue, Apr 08, 2008 at 09:33:32AM -0700, Bock, Tony wrote:
> > Is there any ext3 feature that would cause disk layout to vary if
> > one were to delete all the files on disk and then rewrite them in the
> > same order? We've been doing some simple read/write file system tests
> > in our lab that sometimes result in short delays being distributed
> > throughout several files. As long as we don't re-wipe the drive,
> > these delays occur at repeatable offsets within the affected files,
> > suggesting disk seeks at the affected locations.
> >
> > To my understanding, deleting a file should mark all the data blocks
> > as free. Thus, any previous disk state should no longer affect files
> > that are written thereafter. Is this correct?
>
> As a general rule you cannot re-use the blocks (in ordered mode anyway)
> that are involved in a truncate until the transaction for the truncate
> is completed in order to make sure that everything is consistent after
> a recovery in the case of a crash. So if you are rm -rf *'ing and then
> immediately re-writing stuff you are going to end up with weirdness, as
> there will be blocks that cannot be reused until the entire truncate is
> completed. Best bet is to do you rm -rf * and then run sync, and then
> do your writing, that should garuntee that the blocks that you have freed
> up from the truncate are actually able to be used by new stuff.
In addition, every 125MB or so there has to be a break in the file data
because of metadata. In ext4 with the "flex_bg" patch the metadata will
be more localized and spread around 16GB apart (configurable).
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2008-04-14 19:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-08 16:33 ext3 block layout after deleting previous drive contents Bock, Tony
2008-04-08 17:08 ` Josef Bacik
2008-04-14 19:46 ` Andreas Dilger [this message]
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=20080414194625.GH3106@webber.adilger.int \
--to=adilger@sun.com \
--cc=jbacik@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tony.bock@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).