xfs
[Top] [All Lists]

Re: avoid mbox file fragmentation

To: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Subject: Re: avoid mbox file fragmentation
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 21 Oct 2010 12:55:43 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <4CBE5BF7.1090001@xxxxxxxxxxxxxxxxx>
References: <4CBE2403.8070108@xxxxxxxxxxxxxxxxx> <20101019234217.GD12506@dastard> <4CBE5BF7.1090001@xxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
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@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>