hydra-users
[Top][All Lists]
Advanced

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

df fails to read file system list? no sparse file support?


From: Jim Meyering
Subject: df fails to read file system list? no sparse file support?
Date: Mon, 31 Jan 2011 12:18:05 +0100

Hi!

What type of file system do we get for jobs like these?

  http://hydra.nixos.org/jobset/gnu/coreutils-master

I've just noticed that one of coreutils tests
is failing (a new one) and it suggests that there
is a problem with df, or possibly with the gnulib
mountlist module.

Here's the "raw" log:

    http://hydra.nixos.org/build/875237/nixlog/1/raw

The interesting part is here:

    Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.
    + df -T -t btrfs -t xfs -t ext4 -t ocfs2 .
    df: Warning: cannot read table of mounted file systems: No such file or 
directory
    Filesystem    Type   1K-blocks      Used Available Use% Mounted on
    -                -   236456305 120987303 103454513  54% /
    + timeout 10 truncate -s1T f
    truncate: failed to truncate `f' at 1099511627776 bytes: File too large
    + framework_failure_
    + warn_ 'fiemap-perf: set-up failure: '
    + echo 'fiemap-perf: set-up failure: '

Those lines correspond to these commands from
coreutils/tests/cp/fiemap-perf:

    # Require a fiemap-enabled FS.
    df -T -t btrfs -t xfs -t ext4 -t ocfs2 . \
      || skip_ "this file system lacks FIEMAP support"

    # Create a large-but-sparse file.
    timeout 10 truncate -s1T f || framework_failure_

That first command tells df to fail if "." is not
of one of the 4 selected types, and the log above suggests
that in spite of the warning and the "-" in the listing
that the type was indeed one of the four.

However, that df printed that warning, and that the subsequent
truncate failed to create a 1TiB sparse file makes me think
something deeper is failing.  On any of those FS types, truncate
should succeed, creating a file that occupies only a block or two,
yet here it failed.  So are we using some other type file system?

Also odd: a failing df or timeout there should lead to a
"skipped test: ..." diagnostic, but here, the test failed.

Jim

P.s. is there a way to get shell access to a build environment
or similarly configured system?  Then I could just debug things
like this, rather than take the time to post about it.

PPS: thanks a lot for providing this service!



reply via email to

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