Q: about xfs pre-allocation

Q: about xfs pre-allocation

[LA Walsh]

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

Re: Q: about xfs pre-allocation

[Dave Chinner]

On Tue, Dec 10, 2013 at 10:06:24AM -0800, LA Walsh wrote:
> 
> 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...

It's mostly wrong information.

Just a suggestion: take anything advice given about XFS on lists
other than this one with a grain of salt. There's lots of people out
there who *think* they know how XFS works, but there's very few who
actually know how XFS works.

> I thought file space pre-allocation ended when you closed the file??

In some cases, yes. In others, no. it depends on the workload and
what is optimal for minimising fragmentation for that workload.
If it wasn't removed, then oncthe file has been clean for 5 minutes
it gets removed by a background worker.

> But this note from the open-suse list indicates that, at least
> with ext2, a kernel thread removes this later.

ext2 does not use tail preallocationm, background kernel threads or
workqueues to do stuff in the background anymore. It uses
reservation windows to keep concurrent allocations apart. i.e. it
now uses the algorithm that the link talks about being designed for
ext3. :P

> 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.

It depends on the context. delayed allocation is where XFS does all
this stuff, and it is quite complex to get it to behave in a sane
manner.

> -------- Original Message --------
> 
> FFFF,
> 
> Modern filesystems use preallocation.
> 
> Per <http://ext2.sourceforge.net/2005-ols/paper-html/node6.html> ext2
> already had it by 2005.

Irix used tail preallocation like ext2 did with EFS back in the late
1980s. XFS improved on it in the 90s via delayed allocation, before
ext2 was even conceived. So using ext2 as an example of a filesystem
using tail preallaction when talking about what XFS does today is
kinda funny.... :P

> With XFS you can disable pre-allocation via the allocsize mount
> parameter.

Wrong. It only allows you to fix the pre-allocation size - it cannot
be turned off.

> (That parameter has been around many years. so yes 11.4
> has preallocation for XFS at a minimum and ext3/ext4 I think.)

It's probably been around longer than ext2....

> allocsize=size
> 
> Sets the buffered I/O end-of-file preallocation size when doing
> delayed allocation writeout (default size is 64KiB).

Wrong. The default behaviour is dynamic preallocation.

> 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.

No it doesn't - it's invalid.

# mount -o allocsize=0 /dev/vda /mnt/test
mount: wrong fs type, bad option, bad superblock on /dev/vda,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
# dmesg |tail -3
[23843.767642] XFS (vda): Mounting Filesystem
[23843.835922] XFS (vda): Ending clean mount
[95648.513436] XFS (vda): invalid log iosize: 255 [not 12-30]
#

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Q: about xfs pre-allocation

[LA Walsh]

On 12/10/2013 5:46 PM, Dave Chinner wrote:
> On Tue, Dec 10, 2013 at 10:06:24AM -0800, LA Walsh wrote:
>> Could someone comment on my [mis-]understanding in regards to
>> what the note below said 
> 
> It's mostly wrong information.
> 
> Just a suggestion: take anything advice given about XFS on lists
> other than this one with a grain of salt. There's lots of people out
> there who *think* they know how XFS works, but there's very few who
> actually know how XFS works.
---

Well, even thinking I had a clue, I wanted to check here, cuz, things
change and I might give out totally wrong info... yuck...




I appreciate your expertise and tireless[?] efforts on a great FS.

=====
Brian,
Thanks  for the different detail and emphasis...
Sometimes I need to read something in multiple ways to fully get it
(assuming I 'get' it...)



_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Q: about xfs pre-allocation

[Brian Foster]

On 12/10/2013 01:06 PM, LA Walsh wrote:
> 
> 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??
> 

XFS normally frees post-eof preallocation on close, but there is the
possibility for the preallocated space to hang around longer if a file
is opened, written and closed repeatedly. You could observe this by
repeatedly doing an open/write/close cycle on a file with xfs_io. After
a few cycles, you'll see the blocks allocated to the file exceed the
size of 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.
> 

XFS has a background scanning thread for this purpose as of 3.8. It runs
on a 5 minute interval by default and trims the speculative
preallocation from inodes that haven't been written to recently.

Brian

> 
> -------- 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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs