I am trying to test a disk space monitor we have setup. For that purpose, I ran truncate -s 125G /publish/data/bigFile which should claim enough space for the alert to be triggered.

However, df -h shows for that partition: /dev/vdb1 196G 66G 121G 36% /publish/data (which is to say, free space has not changed after running the truncate command.)

ls -lh on the file shows: -rw-r--r-- 1 username users 126G Aug 7 11:27 /publish/data/bigFile

mount output for /publish/data: /dev/vdb1 on /publish/data type ext4 (rw,relatime,data=ordered)

Edit: I also just realize, the numbers do not make sense: 196-66=130gb, so why df says 121gb free in the first place?


2 Answers 2


Can't see any documentation that supports it, but truncate must be creating a sparse file:

TEST truncate -s 10G testfile

du testfile # shows the occupied size

   0  testfile

du -h --apparent-size # shows apparent size

   10G   testfile

From the du man page:

          print   apparent  sizes,  rather  than  disk  usage;
          although the apparent size is  usually  smaller,  it
          may  be  larger  due  to  holes in ('sparse') files,
          internal fragmentation,  indirect  blocks,  and  the


Try using fallocate, it's very quick and does not create sparse files.

fallocate -l 125G filename
  • That did the trick, thank you! how do we open a docs bug for truncate, for the docs to reflect this minor detail, in future builds? Aug 7, 2019 at 19:07
  • I emailed an enquiry to bug-coreutils@gnu.org and received an auto reply which has generated a bug #36963. If you want you can provide more info to the maintainers by emailing 36963@debbugs.gnu.org.
    – suspectus
    Aug 7, 2019 at 20:48
  • @Carmageddon the author has updated the truncate docs: git.savannah.gnu.org/cgit/coreutils.git/commit
    – suspectus
    Aug 8, 2019 at 13:57
  • That was super fast. thanks! Aug 9, 2019 at 6:47
  • If your on Mac OS X which doesn't have fallocate, try mkfilestackoverflow.com/a/33478049/714112 Jul 23, 2020 at 19:48

I would suspect you're seeing sparse file allocation at work. You can create a huge file but until you write data to it the actual space on the drive isn't committed.

There are probably ways to allocate and actually commit the space but I've not run across them. If you want to ensure the space is physically allocated you can code a simple program to just append data to a file until it is the proper size.

  • I tried to echo "test >> /publish/data/bigFileand that didnt do it Aug 7, 2019 at 16:50
  • Try something line this: "echo 1234567890>x" and then "cat x x x x x x>xx" and then "cat xx xx xx xx xx>x" repeat the second two commands repeatedly until you get the size of file you want.
    – nutcase
    Aug 8, 2019 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.