From: LA Walsh <xfs@tlinx.org>
To: xfs-oss <xfs@oss.sgi.com>
Subject: Q: about xfs pre-allocation
Date: Tue, 10 Dec 2013 10:06:24 -0800 [thread overview]
Message-ID: <52A75820.9090004@tlinx.org> (raw)
Could someone comment on my [mis-]understanding in regards to
what the note below said that was posted by someone else
to another list. The pre-allocation behavior for XFS that the
note describes doesn't jive w/what I thought happened and I
was wondering if my brain was out of date or something (at
least in regards to this topic! ;-)). Names elided from
Original Message, below for no great reason...
I thought file space pre-allocation ended when you closed the file??
But this note from the open-suse list indicates that, at least
with ext2, a kernel thread removes this later.
I thought the FS-space allocator gave *preference* to having the
next file start at least "filesize%('allocsize || 64K')" from
the end of the previous, BUT, if needed it will allocate space
from the end of the previous file (rounded to fs-blocksize) if
space is really that tight.
-------- Original Message --------
FFFF,
Modern filesystems use preallocation.
Per <http://ext2.sourceforge.net/2005-ols/paper-html/node6.html> ext2
already had it by 2005.
That means when a file is created and written to they automatically
allocate a unused tail at the end of each file.
Then some time later (hours / days) they have a background kernel
thread that scavenges any tails that are still unused.
The positive is that files (like logs) growing slowly over time won't
get fragmented so badly.
The bad is that for highspeed filesystem filling tasks like a massive
rsync, the disk usage is anomalously high for a while (hours / days).
With XFS you can disable pre-allocation via the allocsize mount
parameter. (That parameter has been around many years. so yes 11.4
has preallocation for XFS at a minimum and ext3/ext4 I think.)
allocsize=size
Sets the buffered I/O end-of-file preallocation size when doing
delayed allocation writeout (default size is 64KiB). Valid values for
this option are page size (typically 4KiB) through to 1GiB, inclusive,
in power-of-2 increments.
size = 0 disables preallocation and is probably smart on your
distination backup disk.
I assume other filesystems have a way to disable preallocation as well.
FYI: I don't know how to determine the total amount of preallocation
space on a filesystem. I'm sure it can be done somehow.
gggg
----
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse+owner@opensuse.org
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2013-12-10 18:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-10 18:06 LA Walsh [this message]
2013-12-11 1:46 ` Q: about xfs pre-allocation Dave Chinner
2013-12-11 4:12 ` LA Walsh
2013-12-11 1:49 ` Brian Foster
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=52A75820.9090004@tlinx.org \
--to=xfs@tlinx.org \
--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