xfs
[Top] [All Lists]

Re: xfs speculative preallocation -- fragmentation issue with sparse fil

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: xfs speculative preallocation -- fragmentation issue with sparse file handling?
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 19 Feb 2013 10:39:34 +1100
Cc: Mark Tinguely <tinguely@xxxxxxx>, Dave Chinner <dchinner@xxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <5122B93E.7060702@xxxxxxxxxx>
References: <51229835.5090707@xxxxxxxxxx> <51229C21.4040102@xxxxxxx> <5122B93E.7060702@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Feb 18, 2013 at 06:29:02PM -0500, Brian Foster wrote:
> On 02/18/2013 04:24 PM, Mark Tinguely wrote:
> > On 02/18/13 15:08, Brian Foster wrote:
> > ... the patched version increases in doubles
> > 
> > +    if (imap[0].br_startblock == HOLESTARTBLOCK)
> > +        return 0;
> > 
> >     vvvvvv
> > +    if (imap[0].br_blockcount <= (MAXEXTLEN >> 1))
> > +        return imap[0].br_blockcount;
> >     ^^^^^^
> > 
> > +    return XFS_B_TO_FSB(mp, XFS_ISIZE(ip));
> > +}
> > 
> > have you experimented without the middle if statement.
> > If I remember correctly when I reviewed the code, that should be moving
> > code closer to the original code; namely use the file size as the
> > preallocation value.
> > 
> 
> Just a quick update...
> 
> I've tested the change above and a suggestion Dave made on IRC to return
> (imap[0].br_blockcount << 1) and both resolve the immediate issue. I
> need to verify the original test case still works and I'll post a patch.
> Thanks...

Though I think you'll find Mark's suggestion reverts preallocation
on sparse files back to the old, undesirable behaviour as it will
prealloc based on the file size on the second 4k of the write at
EOF....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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