Used truncate to create huge file - df is not showing decrease in available space

Question

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?

possible duplicate of https://serverfault.com/questions/379831/disk-space-usage-doesnt-add-up-with-df-du ? — suspectus, Aug 07 '19 at 15:48
That one is about freeing up space. Mine is about filling it up :) I havent found anything like that — Carmageddon, Aug 07 '19 at 16:54

score 3 · Accepted Answer · answered Aug 07 '19 at 17:35

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

answered Aug 07 '19 at 17:35

suspectus

548
1
4
11

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 07 '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 07 '19 at 20:48
@Carmageddon the author has updated the truncate docs: http://git.savannah.gnu.org/cgit/coreutils.git/commit/ – suspectus Aug 08 '19 at 13:57
That was super fast. thanks! – Carmageddon Aug 09 '19 at 06:47
If your on Mac OS X which doesn't have `fallocate`, try `mkfile`https://stackoverflow.com/a/33478049/714112 – Sridhar Sarnobat Jul 23 '20 at 19:48

score 0 · Answer 2 · answered Aug 07 '19 at 16:03

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.

answered Aug 07 '19 at 16:03

nutcase

80
7

I tried to `echo "test >> /publish/data/bigFile`and that didnt do it – Carmageddon Aug 07 '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 08 '19 at 16:02

Used truncate to create huge file - df is not showing decrease in available space

2 Answers2

fallocate