Take the 2-minute tour ×

How can I quickly create a large file on a Linux (Red Hat Linux) system? dd will do the job, but reading from /dev/zero and writing to the drive can take a long time when you need a file several hundreds of GBs in size for testing... If you need to do that repeatedly, the time really adds up.

I don't care about the contents of the file, I just want it to be created quickly. How can this be done?

Using a sparse file won't work for this. I need the file to be allocated disk space.

share|improve this question
Ext4 has much better file allocation performance, since whole blocks of up to 100MB can be allocated at once. –  martinus Jan 29 '09 at 16:09
The 'truncate' command creates a sparse file, by the way. E.g. see en.wikipedia.org/wiki/Sparse_file –  Jason Drew Jan 14 '11 at 18:08

11 Answers 11

dd is a good solution, but it is slow for this purpose. In Linux, we have fallocate.

For example:

fallocate -l 10G gentoo_root.img
share|improve this answer
Is it possible that dd is internally using that already? If I do 'dd if=/dev/zero of=zerofile bs=1G count=1' on a 3.0.0 kernel, the write finishes in 2 seconds, with a write data rate of over 500 megabytes per second. That's clearly impossible on a 2.5" laptop harddrive. –  lxgr Dec 5 '11 at 12:32
I have just tried on 3.0.0-14 kernel dd if=/dev/zero of=zerofile bs=1G count=1 and it was very slow: 37,3 MB/s. Maybe it depends on filesystem… –  Franta Jan 3 '12 at 14:14
fallocate is exactly what I was looking for. –  alberge Jun 28 '12 at 4:07
note that fallocate doesn't work on tmpfs filesystems. –  K3---rnc Oct 10 '13 at 20:35
This (fallocate) will also not work on a Linux ZFS filesystem - github.com/zfsonlinux/zfs/issues/326 –  Joe Nov 19 '13 at 1:51

This is a common question -- especially in today's environment of virtual environments. Unfortunately, the answer is not as straight-forward as one might assume.

dd is the obvious first choice, but dd is essentially a copy and that forces you to write every block of data (thus, initializing the file contents)... And that initialization is what takes up so much I/O time. (Want to make it take even longer? Use /dev/random instead of /dev/zero! Then you'll use CPU as well as I/O time!) In the end though, dd is a poor choice (though essentially the default used by the VM "create" GUIs).

truncate is another choice -- and is likely the fastest... But that is because it creates a "sparse file". Essentially, a sparse file is a section of disk that has a lot of the same data, and the underlying filesystem "cheats" by not really storing all of the data, but just "pretending" that it's all there. Thus, when you use truncate to create a 20 GB drive for your VM, the filesystem doesn't actually allocate 20 GB, but it cheats and says that there are 20 GB of zeros there, even though as little as one track on the disk may actually (really) be in use.

fallocate is the final -- and best -- choice for use with VM disk allocation, because it essentially "reserves" (or "allocates" all of the space you're seeking, but it doesn't bother to write anything. So, when you use fallocate to create a 20 GB virtual drive space, you really do get a 20 GB file (not a "sparse file", and you won't have bothered to write anything to it -- which means virtually anything could be in there -- kind of like a brand new disk!)

share|improve this answer
+1 very nice explanation! –  Saif Asif May 13 at 9:39
+1 truncate is functional on JFS; fallocate, not so much. One point: you can't include a decimal in the number, I needed to specify 1536G, not 1.5T. –  Calrion Sep 11 at 8:08
truncate -s 10M output.file

will create a 10 M file instantaneously (M stands for 1024*1024 bytes, MB stands for 1000*1000 - same with K, KB, G, GB...)

EDIT: as many have pointed out, this will not physically allocate the file on your device. With this you could actually create an arbitrary large file, regardless of the available space on the device

So, when doing this, you will be deferring physical allocation until the file is accessed. If you're mapping this file to memory, you may not have the expected performance.

But this is still a useful command to know

share|improve this answer
Tried this, but it doesn't affect available disk space. Must because it is a sparse file as described previously. –  Gringo Suave Feb 20 '13 at 3:34
This shouldn't be the top answer as it doesn't solve the problem, the fallocate answer below does. –  Gringo Suave Feb 20 '13 at 3:58
@GringoSuave but this is still useful for some people that may have a similar-but-slightly-different problem. –  AJMansfield Jun 18 '13 at 20:41
@GringoSuave: It seems to create a large file as requested, why does it not solve the problem? Also there are notes under the fallocate answer that it doesn't even work in most cases. –  Pavel Šimerda Jul 8 at 5:13
The file is not actually allocated, it is "sparse." –  Gringo Suave Jul 25 at 22:57

Where seek is the size of the file you want in bytes - 1.

share|improve this answer
I like this approach, but the commenter doesn't want a sparse file for some reason. :( –  ephemient Nov 3 '08 at 15:19
dd if=/dev/zero of=1GBfile bs=1000 count=1000000 –  Damien Oct 7 '10 at 18:20
dd if=/dev/zero of=01GBfile bs=1024 count=$((1024 * 1024)) –  Xavier Decoret Aug 31 '11 at 10:01
For sparse files, truncate seems to be much better. –  Pavel Šimerda Jul 8 at 5:16

Try mkfile <size> myfile as an alternative of dd

# mkfile 10240m 10Gigfile

with the -n option the size is noted, but disk blocks aren't allocated until data is written to them. Without the -n option, the space is zero-filled, which means writing to the disk, which means taking time.

mkfile is derived from SunOS and is not available everywhere. Most Linux systems have xfs_mkfile which works exactly the same way, and not just on XFS file systems despite the name.

Most Linux systems also have fallocate, which only works on certain file systems (such as btrfs, ext4, ocfs2, and xfs), but is the fastest, as it allocates all the file space (creates non-holey files) but does not initialize any of it.

share|improve this answer
Where is this mkfile of which you speak, stranger? It's not in the default RHEL install. –  paxdiablo Nov 3 '08 at 3:33
It's a solaris utility. if you search for gpl mkfile you will find some source code examples. –  Martin Beckett Nov 3 '08 at 4:54
Hmm. The OP wanted to know about Linux. I also see that OSX has mkfile, but I couldn't find one for Linux (except for xfs). Funny that this answer got accepted as correct. –  Martin v. Löwis Nov 3 '08 at 5:40
Works as a charme on OS X: mkfile 1g DELETE_IF_LOW_ON_SSD_SPACE.img –  Volker Rose Jun 3 '13 at 7:12

Examples where seek is the size of the file you want in bytes

dd if=/dev/zero of=filename bs=1 count=0 seek=200K




From the dd manpage:

BLOCKS and BYTES may be followed by the following multiplicative suffixes: c=1, w=2, b=512, kB=1000, K=1024, MB=1000*1000, M=1024*1024, GB =1000*1000*1000, G=1024*1024*1024, and so on for T, P, E, Z, Y.

share|improve this answer
This looks much better than the n-1 way, so it's basically equivalent to truncate. –  Pavel Šimerda Jul 8 at 5:18

I don't know a whole lot about Linux, but here's the C Code I wrote to fake huge files on DC Share many years ago.

#include < stdio.h >
#include < stdlib.h >

int main() {
    int i;
    FILE *fp;


    for(i=0;i<(1024*1024);i++) {
share|improve this answer
You have my special award!!! :-) –  Notinlist Mar 20 '13 at 1:54

I don't think you're going to get much faster than dd. The bottleneck is the disk; writing hundreds of GB of data to it is going to take a long time no matter how you do it.

But here's a possibility that might work for your application. If you don't care about the contents of the file, how about creating a "virtual" file whose contents are the dynamic output of a program? Instead of open()ing the file, use popen() to open a pipe to an external program. The external program generates data whenever it's needed. Once the pipe is open, it acts just like a regular file in that the program that opened the pipe can fseek(), rewind(), etc. You'll need to use pclose() instead of close() when you're done with the pipe.

If your application needs the file to be a certain size, it will be up to the external program to keep track of where in the "file" it is and send an eof when the "end" has been reached.

share|improve this answer

One approach: if you can guarantee unrelated applications won't use the files in a conflicting manner, just create a pool of files of varying sizes in a specific directory, then create links to them when needed.

For example, have a pool of files called:

  • /home/bigfiles/512M-A
  • /home/bigfiles/512M-B
  • /home/bigfiles/1024M-A
  • /home/bigfiles/1024M-B

Then, if you have an application that needs a 1G file called /home/oracle/logfile, execute a "ln /home/bigfiles/1024M-A /home/oracle/logfile".

If it's on a separate filesystem, you will have to use a symbolic link.

The A/B/etc files can be used to ensure there's no conflicting use between unrelated applications.

The link operation is about as fast as you can get.

share|improve this answer
good solution IF you have the disk space ready. –  hayalci Nov 3 '08 at 3:38
You can have a small pool or a large pool, it's your choice. You were going to need at least one file anyway, since that's what the questioner asked for. If your pool consists of one file, you lose nothing. If you have bucketloads of disk (and you should, given its low price), there's no issue. –  paxdiablo Nov 3 '08 at 3:50

The GPL mkfile is just a (ba)sh script wrapper around dd; BSD's mkfile just memsets a buffer with non-zero and writes it repeatedly. I would not expect the former to out-perform dd. The latter might edge out dd if=/dev/zero slightly since it omits the reads, but anything that does significantly better is probably just creating a sparse file.

Absent a system call that actually allocates space for a file without writing data (and Linux and BSD lack this, probably Solaris as well) you might get a small improvement in performance by using ftrunc(2)/truncate(1) to extend the file to the desired size, mmap the file into memory, then write non-zero data to the first bytes of every disk block (use fgetconf to find the disk block size).

share|improve this answer
BSD and Linux have fallocate actually (edit: it's now POSIX and widely available). –  Tobu Apr 24 '13 at 10:05

You can use "yes" command also. The syntax is fairly simple:

#yes >> myfile

Press "Ctrl + C" to stop this, else it will eat up all your space available.

To clean this file run:


will clean this file.

share|improve this answer

Your Answer


