3

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
3

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:

   --apparent-size
          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
          like

fallocate

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

fallocate -l 125G filename
5
  • 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? – Carmageddon Aug 7 '19 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 '19 at 20:48
  • @Carmageddon the author has updated the truncate docs: git.savannah.gnu.org/cgit/coreutils.git/commit – suspectus Aug 8 '19 at 13:57
  • That was super fast. thanks! – Carmageddon Aug 9 '19 at 6:47
  • If your on Mac OS X which doesn't have fallocate, try mkfilestackoverflow.com/a/33478049/714112 – Sridhar Sarnobat Jul 23 '20 at 19:48
0

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.

2
  • I tried to echo "test >> /publish/data/bigFileand that didnt do it – Carmageddon Aug 7 '19 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 '19 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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