dd is producing 32MB random file instead of 1GB
I wanted to produce 1GB random file so I used following command
dd if=/dev/urandom of=output bs=1G count=1
but instead every time I launch this command I get 32MB file:
<11:58:40>$ dd if=/dev/urandom of=output bs=1G count=1
0+1 records in
0+1 records out
33554431 bytes (34 MB, 32 MiB) copied, 0,288321 s, 116 MB/s
What is wrong?
script dd random-number-generator
add a comment |
I wanted to produce 1GB random file so I used following command
dd if=/dev/urandom of=output bs=1G count=1
but instead every time I launch this command I get 32MB file:
<11:58:40>$ dd if=/dev/urandom of=output bs=1G count=1
0+1 records in
0+1 records out
33554431 bytes (34 MB, 32 MiB) copied, 0,288321 s, 116 MB/s
What is wrong?
script dd random-number-generator
add a comment |
I wanted to produce 1GB random file so I used following command
dd if=/dev/urandom of=output bs=1G count=1
but instead every time I launch this command I get 32MB file:
<11:58:40>$ dd if=/dev/urandom of=output bs=1G count=1
0+1 records in
0+1 records out
33554431 bytes (34 MB, 32 MiB) copied, 0,288321 s, 116 MB/s
What is wrong?
script dd random-number-generator
I wanted to produce 1GB random file so I used following command
dd if=/dev/urandom of=output bs=1G count=1
but instead every time I launch this command I get 32MB file:
<11:58:40>$ dd if=/dev/urandom of=output bs=1G count=1
0+1 records in
0+1 records out
33554431 bytes (34 MB, 32 MiB) copied, 0,288321 s, 116 MB/s
What is wrong?
script dd random-number-generator
script dd random-number-generator
asked 53 mins ago
Trismegistos
1115
1115
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
bs
, the buffer size, means the size of a single read() call done by dd.
(For example, both bs=1M count=1
and bs=1k count=1k
will result in a 1 MiB file, but the first version will do it in a single step, while the second will do it in 1024 small chunks.)
Regular files can be read at nearly any buffer size (as long as that buffer fits in RAM), but devices and "virtual" files often work very close to the individual calls and have some arbitrary restriction of how much data they'll produce per read() call.
For /dev/urandom
, this limit is defined in urandom_read() in drivers/char/random.c:
#define ENTROPY_SHIFT 3
static ssize_t
urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
...
}
This means that every time the function is called, it will clamp the requested size to 33554431 bytes. By default, dd will not retry after receiving less data than requested – you get the 32 MiB and that's it.
+1 because of explanation what happens under the hood.
– Kamil Maciorowski
23 mins ago
add a comment |
dd
may read less than ibs
(note: bs
specifies both ibs
and obs
), unless iflag=fullblock
is specified. 0+1 records in
indicates that 0
full blocks and 1
partial block was read. However any full or partial block increases the counter.
I don't know the exact mechanism that makes Edit: this concurrent answer explains the mechanism that makes dd
read a block that is less than 1G
in this particular case. I guess any block is read to the memory before it's written, so memory management may interfere (but this is only a guess).dd
read a block that is less than 1G
in this particular case.
Anyway, I don't recommend such large bs
. I would use bs=1M count=1024
. The most important thing is: without iflag=fullblock
any read attempt may read less than ibs
(unless ibs=1
, I think, this is quite inefficient though).
So if you need to read some exact amount of data, use iflag=fullblock
. Note iflag
is not required by POSIX, your dd
may not support it. According to this answer ibs=1
is probably the only POSIX way to read an exact number of bytes. Of course if you change ibs
then you will need to recalculate the count
. In your case lowering ibs
to 32M
or less will probably fix the issue, even without iflag=fullblock
.
In my Kubuntu I would fix your command like this:
dd if=/dev/urandom of=output bs=1M count=1024 iflag=fullblock
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1388082%2fdd-is-producing-32mb-random-file-instead-of-1gb%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
bs
, the buffer size, means the size of a single read() call done by dd.
(For example, both bs=1M count=1
and bs=1k count=1k
will result in a 1 MiB file, but the first version will do it in a single step, while the second will do it in 1024 small chunks.)
Regular files can be read at nearly any buffer size (as long as that buffer fits in RAM), but devices and "virtual" files often work very close to the individual calls and have some arbitrary restriction of how much data they'll produce per read() call.
For /dev/urandom
, this limit is defined in urandom_read() in drivers/char/random.c:
#define ENTROPY_SHIFT 3
static ssize_t
urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
...
}
This means that every time the function is called, it will clamp the requested size to 33554431 bytes. By default, dd will not retry after receiving less data than requested – you get the 32 MiB and that's it.
+1 because of explanation what happens under the hood.
– Kamil Maciorowski
23 mins ago
add a comment |
bs
, the buffer size, means the size of a single read() call done by dd.
(For example, both bs=1M count=1
and bs=1k count=1k
will result in a 1 MiB file, but the first version will do it in a single step, while the second will do it in 1024 small chunks.)
Regular files can be read at nearly any buffer size (as long as that buffer fits in RAM), but devices and "virtual" files often work very close to the individual calls and have some arbitrary restriction of how much data they'll produce per read() call.
For /dev/urandom
, this limit is defined in urandom_read() in drivers/char/random.c:
#define ENTROPY_SHIFT 3
static ssize_t
urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
...
}
This means that every time the function is called, it will clamp the requested size to 33554431 bytes. By default, dd will not retry after receiving less data than requested – you get the 32 MiB and that's it.
+1 because of explanation what happens under the hood.
– Kamil Maciorowski
23 mins ago
add a comment |
bs
, the buffer size, means the size of a single read() call done by dd.
(For example, both bs=1M count=1
and bs=1k count=1k
will result in a 1 MiB file, but the first version will do it in a single step, while the second will do it in 1024 small chunks.)
Regular files can be read at nearly any buffer size (as long as that buffer fits in RAM), but devices and "virtual" files often work very close to the individual calls and have some arbitrary restriction of how much data they'll produce per read() call.
For /dev/urandom
, this limit is defined in urandom_read() in drivers/char/random.c:
#define ENTROPY_SHIFT 3
static ssize_t
urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
...
}
This means that every time the function is called, it will clamp the requested size to 33554431 bytes. By default, dd will not retry after receiving less data than requested – you get the 32 MiB and that's it.
bs
, the buffer size, means the size of a single read() call done by dd.
(For example, both bs=1M count=1
and bs=1k count=1k
will result in a 1 MiB file, but the first version will do it in a single step, while the second will do it in 1024 small chunks.)
Regular files can be read at nearly any buffer size (as long as that buffer fits in RAM), but devices and "virtual" files often work very close to the individual calls and have some arbitrary restriction of how much data they'll produce per read() call.
For /dev/urandom
, this limit is defined in urandom_read() in drivers/char/random.c:
#define ENTROPY_SHIFT 3
static ssize_t
urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
...
}
This means that every time the function is called, it will clamp the requested size to 33554431 bytes. By default, dd will not retry after receiving less data than requested – you get the 32 MiB and that's it.
answered 25 mins ago
grawity
232k35488545
232k35488545
+1 because of explanation what happens under the hood.
– Kamil Maciorowski
23 mins ago
add a comment |
+1 because of explanation what happens under the hood.
– Kamil Maciorowski
23 mins ago
+1 because of explanation what happens under the hood.
– Kamil Maciorowski
23 mins ago
+1 because of explanation what happens under the hood.
– Kamil Maciorowski
23 mins ago
add a comment |
dd
may read less than ibs
(note: bs
specifies both ibs
and obs
), unless iflag=fullblock
is specified. 0+1 records in
indicates that 0
full blocks and 1
partial block was read. However any full or partial block increases the counter.
I don't know the exact mechanism that makes Edit: this concurrent answer explains the mechanism that makes dd
read a block that is less than 1G
in this particular case. I guess any block is read to the memory before it's written, so memory management may interfere (but this is only a guess).dd
read a block that is less than 1G
in this particular case.
Anyway, I don't recommend such large bs
. I would use bs=1M count=1024
. The most important thing is: without iflag=fullblock
any read attempt may read less than ibs
(unless ibs=1
, I think, this is quite inefficient though).
So if you need to read some exact amount of data, use iflag=fullblock
. Note iflag
is not required by POSIX, your dd
may not support it. According to this answer ibs=1
is probably the only POSIX way to read an exact number of bytes. Of course if you change ibs
then you will need to recalculate the count
. In your case lowering ibs
to 32M
or less will probably fix the issue, even without iflag=fullblock
.
In my Kubuntu I would fix your command like this:
dd if=/dev/urandom of=output bs=1M count=1024 iflag=fullblock
add a comment |
dd
may read less than ibs
(note: bs
specifies both ibs
and obs
), unless iflag=fullblock
is specified. 0+1 records in
indicates that 0
full blocks and 1
partial block was read. However any full or partial block increases the counter.
I don't know the exact mechanism that makes Edit: this concurrent answer explains the mechanism that makes dd
read a block that is less than 1G
in this particular case. I guess any block is read to the memory before it's written, so memory management may interfere (but this is only a guess).dd
read a block that is less than 1G
in this particular case.
Anyway, I don't recommend such large bs
. I would use bs=1M count=1024
. The most important thing is: without iflag=fullblock
any read attempt may read less than ibs
(unless ibs=1
, I think, this is quite inefficient though).
So if you need to read some exact amount of data, use iflag=fullblock
. Note iflag
is not required by POSIX, your dd
may not support it. According to this answer ibs=1
is probably the only POSIX way to read an exact number of bytes. Of course if you change ibs
then you will need to recalculate the count
. In your case lowering ibs
to 32M
or less will probably fix the issue, even without iflag=fullblock
.
In my Kubuntu I would fix your command like this:
dd if=/dev/urandom of=output bs=1M count=1024 iflag=fullblock
add a comment |
dd
may read less than ibs
(note: bs
specifies both ibs
and obs
), unless iflag=fullblock
is specified. 0+1 records in
indicates that 0
full blocks and 1
partial block was read. However any full or partial block increases the counter.
I don't know the exact mechanism that makes Edit: this concurrent answer explains the mechanism that makes dd
read a block that is less than 1G
in this particular case. I guess any block is read to the memory before it's written, so memory management may interfere (but this is only a guess).dd
read a block that is less than 1G
in this particular case.
Anyway, I don't recommend such large bs
. I would use bs=1M count=1024
. The most important thing is: without iflag=fullblock
any read attempt may read less than ibs
(unless ibs=1
, I think, this is quite inefficient though).
So if you need to read some exact amount of data, use iflag=fullblock
. Note iflag
is not required by POSIX, your dd
may not support it. According to this answer ibs=1
is probably the only POSIX way to read an exact number of bytes. Of course if you change ibs
then you will need to recalculate the count
. In your case lowering ibs
to 32M
or less will probably fix the issue, even without iflag=fullblock
.
In my Kubuntu I would fix your command like this:
dd if=/dev/urandom of=output bs=1M count=1024 iflag=fullblock
dd
may read less than ibs
(note: bs
specifies both ibs
and obs
), unless iflag=fullblock
is specified. 0+1 records in
indicates that 0
full blocks and 1
partial block was read. However any full or partial block increases the counter.
I don't know the exact mechanism that makes Edit: this concurrent answer explains the mechanism that makes dd
read a block that is less than 1G
in this particular case. I guess any block is read to the memory before it's written, so memory management may interfere (but this is only a guess).dd
read a block that is less than 1G
in this particular case.
Anyway, I don't recommend such large bs
. I would use bs=1M count=1024
. The most important thing is: without iflag=fullblock
any read attempt may read less than ibs
(unless ibs=1
, I think, this is quite inefficient though).
So if you need to read some exact amount of data, use iflag=fullblock
. Note iflag
is not required by POSIX, your dd
may not support it. According to this answer ibs=1
is probably the only POSIX way to read an exact number of bytes. Of course if you change ibs
then you will need to recalculate the count
. In your case lowering ibs
to 32M
or less will probably fix the issue, even without iflag=fullblock
.
In my Kubuntu I would fix your command like this:
dd if=/dev/urandom of=output bs=1M count=1024 iflag=fullblock
edited 20 mins ago
answered 25 mins ago
Kamil Maciorowski
23.9k155175
23.9k155175
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1388082%2fdd-is-producing-32mb-random-file-instead-of-1gb%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown