From: Dave Chinner <david@fromorbit.com>
To: "Arkadiusz Miśkiewicz" <arekm@maven.pl>
Cc: xfs@oss.sgi.com
Subject: Re: df bigger than ls?
Date: Thu, 8 Mar 2012 21:03:13 +1100 [thread overview]
Message-ID: <20120308100313.GR3592@dastard> (raw)
In-Reply-To: <201203080904.12362.arekm@maven.pl>
On Thu, Mar 08, 2012 at 09:04:12AM +0100, Arkadiusz Miśkiewicz wrote:
> On Wednesday 07 of March 2012, Eric Sandeen wrote:
>
> > XFS speculatively preallocates space off the end of a file. The amount of
> > space allocated depends on the present size of the file, and the amount of
> > available free space. This can be overridden
> > with mount -o allocsize=64k (or other size for example)
>
> What was the default before speculative preallocation was added (or changed
> somewhere in 2.6.3x line afaik) ?
It's changed many times over the life of XFS.
Originally it was quite a large number and could happen anywhere in
the file - I can't remember exactly what it was but some time around
1997 on Irix it got brought back to 16 blocks per written region
because of issues with Irix NFS servers keeping tens of thousands of
files open (and hence never having speculative preallocation
removed) with multiple preallocations all through sparse files and
hence running filesystems and user quotas out of space.
This 16 block size was the default when ported to linux when porting
to Linux, but would also round up to stripe unit size if the file
was larger than 512kb. In 2004 the speculative preallocation was
reduced to EOF preallocation only instead of anywhere in a hole in a
file. Somewhere along the line the default size got changed to
PAGE_SIZE rather than 16 blocks. Then the allocsize mount option was
introduced in 2005 to enable it to be increased for those that
needed large preallocation (typically PVR users), and the maximum
increased to 1GB.
It got broken by changes in 2008, fixed in 2009, and then made
dynamic in 2.6.38 and now it behaves more like it did in 1995 for
files being extended.
So there's a long history of changing the speculative preallocation
behaviour of XFS to adapt to changing storage characteristics,
workloads and capacities.....
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:[~2012-03-08 10:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-07 15:54 df bigger than ls? Brian Candler
2012-03-07 17:16 ` Brian Candler
2012-03-07 18:04 ` Eric Sandeen
2012-03-08 2:10 ` Dave Chinner
2012-03-08 2:17 ` Eric Sandeen
2012-03-08 9:10 ` Brian Candler
2012-03-08 9:28 ` Dave Chinner
2012-03-08 16:23 ` Ben Myers
2012-03-09 0:17 ` Dave Chinner
2012-03-09 1:56 ` Ben Myers
2012-03-09 2:57 ` Dave Chinner
2012-03-08 8:04 ` Arkadiusz Miśkiewicz
2012-03-08 10:03 ` Dave Chinner [this message]
2012-03-08 8:50 ` Brian Candler
2012-03-08 9:59 ` Brian Candler
2012-03-08 10:22 ` Dave Chinner
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=20120308100313.GR3592@dastard \
--to=david@fromorbit.com \
--cc=arekm@maven.pl \
--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