From: Dave Chinner <david@fromorbit.com>
To: Stan Hoeppner <stan@hardwarefreak.com>
Cc: xfs@oss.sgi.com
Subject: Re: avoid mbox file fragmentation
Date: Thu, 21 Oct 2010 12:55:43 +1100 [thread overview]
Message-ID: <20101021015543.GF12506@dastard> (raw)
In-Reply-To: <4CBE5BF7.1090001@hardwarefreak.com>
On Tue, Oct 19, 2010 at 10:03:19PM -0500, Stan Hoeppner wrote:
> Dave Chinner put forth on 10/19/2010 6:42 PM:
>
> > I've explained how allocsize works, and that speculative allocation
> > gets truncated away whenteh file is closed. Hence is the application
> > is doing:
> >
> > open()
> > seek(EOF)
> > write()
> > close()
>
> I don't know if it changes anything in the sequence above, but Dovecot
> uses mmap i/o. As I've said, I'm not a dev. Just thought this
> could/might be relevant. Would using mmap be compatible with physical
> preallocation?
mmap() can't write beyond EOF or extend the file. hence it would
have to be:
open()
mmap()
ftrucate(new_size)
<write via mmap>
In this method, there is no speculative preallocation because the
there is never a delayed allocation that extends the file size. it
simply doesn't matter where the close() occurs. Hence if you use
mmap() writes like this, the only way you can avoid fragmentation is
to use physical preallocation beyond EOF before you start any
writes....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-10-21 1:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-19 23:04 avoid mbox file fragmentation Stan Hoeppner
2010-10-19 23:42 ` Dave Chinner
2010-10-20 2:36 ` Stan Hoeppner
2010-10-20 11:31 ` Peter Grandi
2010-10-20 3:03 ` Stan Hoeppner
2010-10-21 1:55 ` Dave Chinner [this message]
2010-10-20 11:50 ` Peter Grandi
2010-10-21 2:00 ` Dave Chinner
2010-10-21 16:39 ` Peter Grandi
2010-10-21 20:06 ` Best filesystems ? Andrew Daviel
2010-10-22 2:47 ` Stan Hoeppner
2010-10-23 18:13 ` Peter Grandi
2010-10-23 20:16 ` Emmanuel Florac
2010-10-26 0:55 ` hank peng
2010-10-26 7:19 ` Emmanuel Florac
2010-10-23 21:28 ` Stan Hoeppner
2010-10-24 0:17 ` Steve Costaras
2010-10-24 18:27 ` Michael Monnerie
2010-10-24 20:52 ` Emmanuel Florac
2010-10-20 11:21 ` avoid mbox file fragmentation Peter Grandi
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=20101021015543.GF12506@dastard \
--to=david@fromorbit.com \
--cc=stan@hardwarefreak.com \
--cc=xfs@oss.sgi.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