The below command should do the trick.
dd if=/dev/zero count=1 bs=30M of=/tmp/file_with_specified_size
Hi @Trevor ,
As I do not see the usual note "RHCE-level and below is the intended audience for this query!", can I share my answer ? Or a hint ?
Regards,
Tshimanga
TM, because of your courtesy and consideration,
I will gladly open the door for you to provide an
answer, or a hint!!!
The below command should do the trick.
dd if=/dev/zero count=1 bs=30M of=/tmp/file_with_specified_size
Love the response TM!!!
Now, for that not-so-seasoned Linux person, I'd like to
pose a couple of separate questions, based on your
answer:
Question1: For the output file (of=/tmp/....), you were
specific with the directory (/tmp) that the file would be
created, but generic with the name of the file (file_with...).
My question is, does the file HAVE TO BE created in the
/tmp directory?
Question2: Your use of count=1 and bs=30M, is certainly
acceptable. My question is, do I lose (or gain) anything if
I use either of the following combos of count and bs, instead
of the values that you used in your answer:
- count=10 bs=3M
- count=30 bs=1M
Thanks again TM!!!!
"of=" just means the path for the output file, it can be anywhere you need your file to be created.
As for the byte sector (bs) argument... it depends on what device you are reading and writing to. Tiny read sizes (eg: 1byte) will hurt your performance because most devices will have a minimal block size much larger than that (eg, in older hard drives it's just not possible to read less than 512bytes, or 4096bytes/4k in newer drives). So if you use bs=1byte, you'll read the first sector 512 times instead of just one.
Same for writing, if you use a BS smaller than the actual size of the device, you'll be overwriting the same data again and again for no good reason.
Why then not just set up a huge BS , like 1G? In case you are reading broken media (failing hard drive, failing tapes, etc), you want to pinpoint exactly how many sectors you can't read, because otherwise your page will be blank and zeros will be written to destination instead of the actual content. Also ibs (input BS) and obs (output BS) can be used for these situations, ad well as conv=sync to ensure readable data is still padded into the right location after failed unreadable data.
Love the additional info Fran.
Regarding my first query,
"... does the file HAVE TO BE created in the
/tmp directory?",
is it possible to give me a YES or NO
on that one?
No - it can be created in whatever directory you need
FWIW you can also use truncate to create blank files - if the file doesn't exist it's initialized with zeros (and size is expressed in bytes):
truncate --size=313 /tmp/example.dat
First, let me begin Fran, by thanking you for the
short answer - to my initial query. No never
looked so good!!!
Also, thank you for elevating our knowledge by
introducing the "truncate" command. I say introducing
because I don't believe that command is a part of
either the RH134 or RH294 courses. This is the
beauty of bring questions to the community - the
needle on the knowlebase will be moved.
Regarding your example using the "truncate" command,
I do find it interesting that you used a value of "313" -
only because my query at the outset made reference
to a 30M file size. No biggee though. I'm guessing
you just wanted to see if readers were paying attention
Thanks for the great response Fran!!!
Or you can just use fallocate that works on some file systems. It is very fast because it does not write anything but only reserves the space:
fallocate -l 30M /tmp/file_with_specified_size
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.