coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tests: fix false du failure on newer XFS


From: Bernhard Voelker
Subject: Re: [PATCH] tests: fix false du failure on newer XFS
Date: Tue, 16 Sep 2014 19:00:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

On 09/16/2014 03:38 PM, Pádraig Brady wrote:
> Bernhard it would be worth mentioning the above two points in the
> commit message as they're not obvious, and then the patch is fine to push.

Thanks, push with the following commit message:

http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=ed0c3c33c6

    tests: fix false du failure on newer XFS

    On XFS, when creating the ~2G test file 'big' in a for-loop by
    appending 20M each time, the file ends up using ~4G - visible in
    'st_blocks'.  The unused space would be reclaimed later.
    This feature is called "speculative preallocation" which aims at
    avoiding fragmentation.
    According to the XFS FAQ [1], there are two particular aspects of
    XFS speculative preallocation that are triggering this:

      1. "Applications that repeatedly trigger preallocation and reclaim
         cycles [after file close] can cause fragmentation.
         Therefore, this pattern is detected and causes the preallocation
         to persist beyond the lifecycle of the file descriptor."

      2. "Preallocation sizes grow as files grow larger."

    [1] http://xfs.org/index.php/XFS_FAQ

    Avoid one of the above by only doing a single close (reclaim cycle).

    * tests/du/2g.sh: Similar to the fix for a dd test (see commit
    v8.22-65-g7c03fe2), avoid speculative preallocation by creating
    the 'big' file in one go instead of appending to it in the loop.
    Remove debugging statements as the output with 'set -x' is
    sufficient nowadays.

After all, I consider this a useful feature, however, IMHO it should
not be visible to the user in 'st_blocks': this is some magic that I,
as a user, would expect from a file system, but I would never want to
(have to) know about it.

Have a nice day,
Berny




reply via email to

[Prev in Thread] Current Thread [Next in Thread]