[opensuse-factory] [13.1 RC1] dd problem
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Look: cer@Eleanor4:~/bin> dd if=/dev/zero of=sample bs=100 count=1 ; l sample 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0.000910599 s, 110 kB/s - -rw-r--r-- 1 cer users 100 Oct 20 16:08 sample cer@Eleanor4:~/bin> dd if=/dev/random of=sample bs=100 count=1 ; l sample 0+1 records in 0+1 records out 22 bytes (22 B) copied, 0.00131574 s, 16.7 kB/s - -rw-r--r-- 1 cer users 22 Oct 20 16:08 sample cer@Eleanor4:~/bin> dd if=/dev/random of=sample bs=100 count=1 ; l sample 0+1 records in 0+1 records out 9 bytes (9 B) copied, 17.0424 s, 0.0 kB/s - -rw-r--r-- 1 cer users 9 Oct 20 16:08 sample cer@Eleanor4:~/bin> Why if the input is /dev/random, the size of the output file is not 100 bytes? Some times 16 bytes, some 20, some 9... However, if I run that in 12.3, I get the expected result, consistently: Telcontar:~ # dd if=/dev/random of=sample bs=100 count=1 ; l sample 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0.00013542 s, 738 kB/s - -rw-r--r-- 1 root root 100 Oct 20 16:13 sample Telcontar:~ # Two tested machines running 13.1 fail (one virtual, one real) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJj6JcACgkQtTMYHG2NR9VZzQCeM2Kbfe4fOrSPOMPKTCyDFshX LUAAnRc/rRGyeidl1dTEM3kc36a6Qbvq =yqPb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 2013-10-20 16:28, Carlos E. R. wrote:
cer@Eleanor4:~/bin> dd if=/dev/random of=sample bs=100 count=1 ; l sample 0+1 records in 0+1 records out 22 bytes (22 B) copied, 0.00131574 s, 16.7 kB/s - -rw-r--r-- 1 cer users 22 Oct 20 16:08 sample
cer@Eleanor4:~/bin> dd if=/dev/random of=sample bs=100 count=1 ; l sample 0+1 records in 0+1 records out 9 bytes (9 B) copied, 17.0424 s, 0.0 kB/s - -rw-r--r-- 1 cer users 9 Oct 20 16:08 sample cer@Eleanor4:~/bin>
Why if the input is /dev/random, the size of the output file is not 100 bytes?
Because dd stops when it the syscall returns an error. But it won't tell you that. So stop using dd already. Use ddrescue - it's saner in every aspect. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-10-20 16:46, Jan Engelhardt wrote:
On Sunday 2013-10-20 16:28, Carlos E. R. wrote:
Because dd stops when it the syscall returns an error. But it won't tell you that.
What error? 12.3 succeeds.
So stop using dd already. Use ddrescue - it's saner in every aspect.
New problem. It is not the standard ddrescue, but gnu ddrescue, which does not include dd_rhelp. And the syntax is different. How do I write a random file of exactly 100 bytes? There are no examples in the man page. Oh, there is an info page... but no examples like what I want. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
On Sunday 2013-10-20 17:17, Carlos E. R. wrote:
So stop using dd already. Use ddrescue - it's saner in every aspect.
New problem. It is not the standard ddrescue, but gnu ddrescue, which does not include dd_rhelp.
I never claimed it's "dd_rescue" :) dd_rescue is comparatively dumb - it reads sectors from start to finish (size and direction according to parameters). To support block-splitting, block-jumping and whatever else, someone came up with dd_rhelp, which is quite the hack. In gnu_ddrescue, all that is built-in and automatic.
And the syntax is different. How do I write a random file of exactly 100 bytes?
Follow what other tools do: -s for size, -i for input, -o for output. dd_rescue is rather... special with having chosen -m, -s and -S. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-10-20 at 17:55 +0200, Jan Engelhardt wrote:
On Sunday 2013-10-20 17:17, Carlos E. R. wrote:
So stop using dd already. Use ddrescue - it's saner in every aspect.
New problem. It is not the standard ddrescue, but gnu ddrescue, which does not include dd_rhelp.
I never claimed it's "dd_rescue" :)
dd_rescue is comparatively dumb - it reads sectors from start to finish (size and direction according to parameters). To support block-splitting, block-jumping and whatever else, someone came up with dd_rhelp, which is quite the hack.
In gnu_ddrescue, all that is built-in and automatic.
Hugh. More tools to learn.
And the syntax is different. How do I write a random file of exactly 100 bytes?
Follow what other tools do: -s for size, -i for input, -o for output. dd_rescue is rather... special with having chosen -m, -s and -S.
No, turns out that -i is starting position and -o is starting position in output cer@Minas-Anor:~> ddrescue -s 100 -i /dev/random -o sample ; ls -l sample ddrescue: Bad or missing numerical argument. Try 'ddrescue --help' for more information. - -rw-r--r-- 1 cer users 100 Oct 20 20:12 sample cer@Minas-Anor:~> Correct ussage is: cer@Minas-Anor:~> ddrescue -s 100 /dev/random sample ; ls -l sample GNU ddrescue 1.17 Press Ctrl-C to interrupt rescued: 100 B, errsize: 0 B, current rate: 5 B/s ipos: 0 B, errors: 0, average rate: 5 B/s opos: 0 B, time since last successful read: 0 s Finished - -rw-r--r-- 1 cer users 100 Oct 20 20:21 sample cer@Minas-Anor:~> - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJkH7IACgkQtTMYHG2NR9Vx/ACfR+Uuo9SBXONgyP/yrwMc7ZSr 9ZEAn0k8gbJ/9GYLzvOB4c3wcpxEDR1E =nPTQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/20/2013 04:46 PM, Jan Engelhardt wrote:
On Sunday 2013-10-20 16:28, Carlos E. R. wrote:
cer@Eleanor4:~/bin> dd if=/dev/random of=sample bs=100 count=1 ; l sample 0+1 records in 0+1 records out 22 bytes (22 B) copied, 0.00131574 s, 16.7 kB/s - -rw-r--r-- 1 cer users 22 Oct 20 16:08 sample
cer@Eleanor4:~/bin> dd if=/dev/random of=sample bs=100 count=1 ; l sample 0+1 records in 0+1 records out 9 bytes (9 B) copied, 17.0424 s, 0.0 kB/s - -rw-r--r-- 1 cer users 9 Oct 20 16:08 sample cer@Eleanor4:~/bin>
Why if the input is /dev/random, the size of the output file is not 100 bytes?
Because dd stops when it the syscall returns an error. But it won't tell you that.
Sorry. but that's not correct. We're talking about "short reads" here, and dd(1) behaves exactly as POSIX specifies it ([1]): search for "partial" and "short" in the specification. [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html In this case, dd(1) told us that 0 blocks were full reads and that there happened 1 partial read: 0+1 records in "%u+%u records in\n", <number of whole input blocks>, <number of partial input blocks>
So stop using dd already. Use ddrescue - it's saner in every aspect.
If you think that dd(1) has a bug or contradicts the specification, then please report a bug. Otherwise, simply use the iflag=fullblock option [2]: ‘fullblock’ Accumulate full blocks from input. The read system call may return early if a full block is not available. When that happens, continue calling read to fill the remainder of the block. This flag can be used only with iflag. This flag is useful with pipes for example as they may return short reads. In that case, this flag is needed to ensure that a ‘count=’ argument is interpreted as a block count rather than a count of read operations. [2] http://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html#dd... Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-10-20 at 19:48 +0200, Bernhard Voelker wrote:
Otherwise, simply use the iflag=fullblock option [2]:
So, I should use it like this? cer@Minas-Anor:~> dd if=/dev/random of=sample bs=100 count=1 iflag=fullblock ; l sample 1+0 records in 1+0 records out 100 bytes (100 B) copied, 10,9179 s, 0,0 kB/s - -rw-r--r-- 1 cer users 100 Oct 20 20:12 sample cer@Minas-Anor:~> Why did dd work in 12.3 and doesn't in 13.1, has something changed? - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJkHmkACgkQtTMYHG2NR9VFTwCfaVo1RU6FyX1PhBN64boI0/ad n7cAniW6+3w3lp7hEZkmc4RxPQqiyAY2 =0Ghi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/20/2013 08:18 PM, Carlos E. R. wrote:
On Sunday, 2013-10-20 at 19:48 +0200, Bernhard Voelker wrote:
Otherwise, simply use the iflag=fullblock option [2]:
So, I should use it like this?
cer@Minas-Anor:~> dd if=/dev/random of=sample bs=100 count=1 iflag=fullblock ; l sample 1+0 records in 1+0 records out 100 bytes (100 B) copied, 10,9179 s, 0,0 kB/s - -rw-r--r-- 1 cer users 100 Oct 20 20:12 sample cer@Minas-Anor:~>
yes, that's correct. This option is also useful when dd(1) reads from pipes.
Why did dd work in 12.3 and doesn't in 13.1, has something changed?
Re-reading the NEWS and the git log, I don't see a change in that area. Furthermore, this issue has already been there before. It depends on the data source, i.e. in the case of /dev/random, how many bytes the kernel can deliver before it comes to a short read. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/20/2013 08:18 PM, Carlos E. R. wrote:
So, I should use it like this?
BTW: if you want to have 100 bytes from /dev/random, then you could also use 'head -c100 /dev/random'. ;-) Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-10-20 at 22:33 +0200, Bernhard Voelker wrote:
BTW: if you want to have 100 bytes from /dev/random, then you could also use 'head -c100 /dev/random'. ;-)
Easier, true. Thanks. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJlAFsACgkQtTMYHG2NR9USNgCbB06fmIg+411qDOwqMhr4aM2z CS8An0I5whHVZ6XXStsyIkWcHdIPlz8Z =DX1g -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 20 Oct 2013 16:28:39 +0200 (CEST) Carlos E. R. wrote:
Why if the input is /dev/random, the size of the output file is not 100 bytes? Some times 16 bytes, some 20, some 9...
Not dd problem. http://superuser.com/questions/359599/why-is-my-dev-random-so-slow-when-usin... - -- WBR Kyrill -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlJj/mcACgkQkD2T1YT4wYGhfgCggn/KZPr9H/tiiod/2hoENLI6 e5EAn09lZ4uZYn/ycYst+zQAFzoObwYL =fPyS -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-10-20 at 20:01 +0400, Kyrill Detinov wrote:
On Sun, 20 Oct 2013 16:28:39 +0200 (CEST) Carlos E. R. wrote:
Why if the input is /dev/random, the size of the output file is not 100 bytes? Some times 16 bytes, some 20, some 9...
Not dd problem.
http://superuser.com/questions/359599/why-is-my-dev-random-so-slow-when-usin...
That explains why "random" is slow (which I knew), but not why dd aborts. You see, dd, pulling from /dev/random, in 12.3 yields the expected result and is reasonably fast, whereas in 13.1 it doesn't either. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJkITMACgkQtTMYHG2NR9WTfwCeIGYYmAaOXmT+1N2RRSYksaXf wjYAnA2UrCqFy9KuPozWhGfNc8zRZGxK =HBmQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. wrote:
You see, dd, pulling from /dev/random, in 12.3 yields the expected result and is reasonably fast, whereas in 13.1 it doesn't either.
Sounds like a pretty clear regression to me. Bugzilla-time. -- Per Jessen, Zürich (13.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/20/2013 01:36 PM, Per Jessen wrote:
Carlos E. R. wrote:
You see, dd, pulling from /dev/random, in 12.3 yields the expected result and is reasonably fast, whereas in 13.1 it doesn't either.
Sounds like a pretty clear regression to me. Bugzilla-time.
You need to be sure the entropy pool started with the same number of entries. If 13.1 had just been booted and 12.3 had been running for some time, that condition would not be met. Is there a difference between 12.3 and 13.1 if you feed dd from /dev/urandom? Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2013-10-21 at 00:06 -0500, Larry Finger wrote:
You need to be sure the entropy pool started with the same number of entries. If 13.1 had just been booted and 12.3 had been running for some time, that condition would not be met.
THAT could be the explanation, time since boot. I just reproduced the same short read problem in 11.4, booted right now for the purpose. cer@minas-tirith:~> time dd if=/dev/random of=sample bs=100 count=1 ; l sample ; uptime 0+1 records in 0+1 records out 17 bytes (17 B) copied, 0,0185403 s, 0,9 kB/s real 0m0.127s user 0m0.001s sys 0m0.002s - -rw-r--r-- 1 cer users 17 Oct 21 12:15 sample 12:15 up 0:05, 20 users, load average: 1,45, 1,10, 0,53 I'm continuously booting one machine or other to do tests and comparisons on 13.1, 11.4 and 12.3. So it depends on how long the particular system has been running.
Is there a difference between 12.3 and 13.1 if you feed dd from /dev/urandom?
13.1, vmplayer. cer@Eleanor4:~> time dd if=/dev/urandom of=sample bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0,000169929 s, 588 kB/s real 0m0.039s user 0m0.002s sys 0m0.010s cer@Eleanor4:~> cer@Eleanor4:~> time dd if=/dev/urandom of=sample bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0,000816311 s, 123 kB/s real 0m0.007s user 0m0.001s sys 0m0.002s cer@Eleanor4:~> time dd if=/dev/urandom of=sample bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0,00132882 s, 75,3 kB/s real 0m0.005s user 0m0.000s sys 0m0.003s cer@Eleanor4:~> time dd if=/dev/urandom of=sample bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0,00138129 s, 72,4 kB/s real 0m0.005s user 0m0.001s sys 0m0.002s cer@Eleanor4:~> time dd if=/dev/urandom of=sample bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0,00247185 s, 40,5 kB/s real 0m0.006s user 0m0.001s sys 0m0.002s cer@Eleanor4:~> 12.3: cer@eleanor3:~> time dd if=/dev/urandom of=sample bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 6,5235e-05 s, 1,5 MB/s real 0m0.023s user 0m0.000s sys 0m0.004s cer@eleanor3:~> time dd if=/dev/urandom of=sample bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0,000396105 s, 252 kB/s real 0m0.005s user 0m0.001s sys 0m0.003s cer@eleanor3:~> time dd if=/dev/urandom of=sample bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0,000155374 s, 644 kB/s real 0m0.005s user 0m0.000s sys 0m0.003s cer@eleanor3:~> time dd if=/dev/urandom of=sample bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0,000235979 s, 424 kB/s real 0m0.004s user 0m0.001s sys 0m0.002s cer@eleanor3:~> time dd if=/dev/urandom of=sample bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0,000197719 s, 506 kB/s real 0m0.006s user 0m0.000s sys 0m0.004s cer@eleanor3:~> time dd if=/dev/urandom of=sample bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0,000226242 s, 442 kB/s real 0m0.004s user 0m0.001s sys 0m0.002s cer@eleanor3:~> Very little difference. I'll use a bigger block. 13.1: cer@Eleanor4:~> time dd if=/dev/urandom of=sample bs=100 count=1000 1000+0 records in 1000+0 records out 100000 bytes (100 kB) copied, 0,0230575 s, 4,3 MB/s real 0m0.027s user 0m0.001s sys 0m0.012s cer@Eleanor4:~> time dd if=/dev/urandom of=sample bs=100 count=1000 1000+0 records in 1000+0 records out 100000 bytes (100 kB) copied, 0,0227062 s, 4,4 MB/s real 0m0.027s user 0m0.002s sys 0m0.010s cer@Eleanor4:~> 12.3 cer@eleanor3:~> time dd if=/dev/urandom of=sample bs=100 count=1000 1000+0 records in 1000+0 records out 100000 bytes (100 kB) copied, 0,0380396 s, 2,6 MB/s real 0m0.044s user 0m0.001s sys 0m0.036s cer@eleanor3:~> time dd if=/dev/urandom of=sample bs=100 count=1000 1000+0 records in 1000+0 records out 100000 bytes (100 kB) copied, 0,0381175 s, 2,6 MB/s real 0m0.044s user 0m0.000s sys 0m0.036s cer@eleanor3:~> 13.1 is actually faster. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJlAvMACgkQtTMYHG2NR9U7kQCfUIbRiSg5iTEJFbo5mR6qSt85 CPEAniom+/IeLRrBwK9v3gc9dEVcha1d =uIIW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 21/10/13 07:33, Carlos E. R. escribió:
On Monday, 2013-10-21 at 00:06 -0500, Larry Finger wrote:
You need to be sure the entropy pool started with the same number of entries. If 13.1 had just been booted and 12.3 had been running for some time, that condition would not be met.
THAT could be the explanation, time since boot. I just reproduced the same short read problem in 11.4, booted right now for the purpose.
It is the expected behaviour.. and you probably want to use /dev/urandom instead, /dev/random shall only be used for generation of long term cryptographic key material. -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-10-21 15:30, Cristian Rodríguez wrote:
El 21/10/13 07:33, Carlos E. R. escribió:
It is the expected behaviour.. and you probably want to use /dev/urandom instead, /dev/random shall only be used for generation of long term cryptographic key material.
Yes, but is easier to remember "random" than "urandom" :-) I expected 'dd' to take some time, but not to fail. This also means something else: the instructions to crate usb sticks using dd should be revised, again. I had the RC1 stick fail to boot, and had to dd it again. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJlLyIACgkQtTMYHG2NR9UoyQCfZf4C21AmrgubXIUjZRo6pQUV Z7UAnROBn0xhhYFjQcvwYzAqDem62FmV =C1nT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
"Carlos E. R."
I expected 'dd' to take some time, but not to fail.
It doesn't fail. Short reads are not a failure mode. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-10-21 15:45, Andreas Schwab wrote:
"Carlos E. R." <> writes:
I expected 'dd' to take some time, but not to fail.
It doesn't fail. Short reads are not a failure mode.
To me, it is a failure :-) - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJlNd0ACgkQtTMYHG2NR9VQuACZAcpP8+BvfVw7nBNbp7cZykGi T6wAniAkrR0wg7ylCPC0RN/IENzH3i3H =pMql -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 21/10/13 11:10, Carlos E. R. escribió:
To me, it is a failure :-)
Understood, however it is really not. -- "If debugging is the process of removing bugs, then programming must be the process of putting them in." - Edsger Dijkstra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-10-21 16:19, Cristian Rodríguez wrote:
El 21/10/13 11:10, Carlos E. R. escribió:
To me, it is a failure :-)
Understood, however it is really not.
What is exactly a short read? It is an unknown concept to me. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJlOKkACgkQtTMYHG2NR9UJdwCcCZlGxfuZ2b1pCstI/GaV4qc4 eIAAn3pWykasc09rAvFGcdcbe/luBuiZ =we4+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Oct 21, 2013 at 10:22 AM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-10-21 16:19, Cristian Rodríguez wrote:
El 21/10/13 11:10, Carlos E. R. escribió:
To me, it is a failure :-)
Understood, however it is really not.
What is exactly a short read? It is an unknown concept to me.
- -- Cheers / Saludos,
Look back at your dd output in this thread. Sometimes you have something like: cer@minas-tirith:~> time dd if=/dev/random of=sample bs=100 count=1 ; l sample ; uptime 0+1 records in 0+1 records out 17 bytes (17 B) copied, 0,0185403 s, 0,9 kB/s === That 0+1 means 0 full blocks and 1 partial block. The partial block is caused by a short read. When things go as you expect you get 1+0 in that output. That is one full bloke and 0 partial blocks. In the presence of media errors on a disk I've seen the number of partial blocks get pretty big. I suspect if you add "conv=noerror, sync", then you would still get 17 bytes of random data from /dev/random, but then dd would null fill the rest of the block. I use that arg when reading data from disk, otherwise dd will abort on the first media error. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Oct 21, 2013 at 04:22:33PM +0200, Carlos E. R. wrote:
What is exactly a short read? It is an unknown concept to me.
See the read(2) man page: On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal. With /dev/random, the number of bytes available depends on how much entropy has been gathered. You can monitor it via /proc/sys/kernel/random/entropy_avail but even checking in advance doesn't guarantee they will still be available for read() as someone else might read from /dev/random in the meantime. The only reliable way is to repeat the reads until you have the needed amount. If you don't want to wait, you can either use /dev/urandom (if you don't mind worse randomness) or get a hardware generator. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-10-22 08:25, Michal Kubecek wrote:
On Mon, Oct 21, 2013 at 04:22:33PM +0200, Carlos E. R. wrote:
What is exactly a short read? It is an unknown concept to me.
See the read(2) man page:
On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number. It is not an error if this number is smaller than the number of bytes requested; this may happen for example because fewer bytes are actually available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because read() was interrupted by a signal.
Thanks! Now I understand the phrase "short read". Yes, I knew the concept (now I see the description), since many years, but not the name given to it.
With /dev/random, the number of bytes available depends on how much entropy has been gathered. You can monitor it via
/proc/sys/kernel/random/entropy_avail
but even checking in advance doesn't guarantee they will still be available for read() as someone else might read from /dev/random in the meantime. The only reliable way is to repeat the reads until you have the needed amount. If you don't want to wait, you can either use /dev/urandom (if you don't mind worse randomness) or get a hardware generator.
Perhaps there is a list of things that increase entropy that users can do. Typical is moving or switching windows. Maybe having a tuner, listening to all network packets, watching a video... - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJmRzgACgkQtTMYHG2NR9WPdACeOZizppOLpFvpmPFf2pwowG+U m/IAnjMjqDbYzJ0Lig4ZhT8ssx/8dHbY =T5Zi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting "Carlos E. R."
I expected 'dd' to take some time, but not to fail.
This also means something else: the instructions to crate usb sticks using dd should be revised, again. I had the RC1 stick fail to boot, and had to dd it again.
Carlos, the point of dd is to read 'blocks' in chunks (size specified by bs=) until the 'END of input is reached'. /dev/random is not an 'endless' buffer and as such, once the end is reached, dd stops copying. count= means a MAX amount of blocks to be copied from input; and as many blocks as there are with bs= bytes. The 'surprise' to most is not really dd's behavior, but the fact that /dev/random can 'run out of data', which is different to /dev/null. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-10-21 16:21, Dominique Leuenberger a.k.a. Dimstar wrote:
Carlos,
the point of dd is to read 'blocks' in chunks (size specified by bs=) until the 'END of input is reached'.
Ok...
/dev/random is not an 'endless' buffer and as such, once the end is reached, dd stops copying.
I see.
count= means a MAX amount of blocks to be copied from input; and as many blocks as there are with bs= bytes.
Yes, that follows.
The 'surprise' to most is not really dd's behavior, but the fact that /dev/random can 'run out of data', which is different to /dev/null.
Yes, but I expected dd to simply wait. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
Quoting "Carlos E. R."
The 'surprise' to most is not really dd's behavior, but the fact that /dev/random can 'run out of data', which is different to /dev/null.
Yes, but I expected dd to simply wait.
you have to tell dd about your expectation with iflag=fullblock :) Different use-cases.. some need to be specified clearly. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-10-21 16:32, Dominique Leuenberger a.k.a. Dimstar wrote:
Quoting "Carlos E. R." <>:
The 'surprise' to most is not really dd's behavior, but the fact that /dev/random can 'run out of data', which is different to /dev/null.
Yes, but I expected dd to simply wait.
you have to tell dd about your expectation with iflag=fullblock :)
Sigh... :-)
Different use-cases.. some need to be specified clearly.
Yep. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
"Dominique Leuenberger a.k.a. Dimstar"
/dev/random is not an 'endless' buffer and as such, once the end is reached, dd stops copying.
/dev/random is not special wrt. short reads. Any device can return them. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Montag, 21. Oktober 2013 schrieb Dominique Leuenberger a.k.a. Dimstar:
The 'surprise' to most is not really dd's behavior, but the fact that /dev/random can 'run out of data', which is different to /dev/null.
/dev/null does not even start to run ;-) # dd if=/dev/null of=/tmp/foo bs=100 count=1 0+0 records in 0+0 records out 0 bytes (0 B) copied, 7.7241e-05 s, 0.0 kB/s For everything else, see my non-random sig ;-) *SCNR* Regards, Christian Boltz -- Immerwieder der gleiche Anfaengerfehler: /dev/null ist fuer Backup, /dev/zero ist fuer Restore. [J. P. Meier] translated: Always the same beginner's error again: /dev/null is for backup, /dev/zero is for restore. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/21/2013 01:12 PM, Christian Boltz wrote:
Hello,
Am Montag, 21. Oktober 2013 schrieb Dominique Leuenberger a.k.a. Dimstar:
The 'surprise' to most is not really dd's behavior, but the fact that /dev/random can 'run out of data', which is different to /dev/null.
/dev/null does not even start to run ;-)
# dd if=/dev/null of=/tmp/foo bs=100 count=1 0+0 records in 0+0 records out 0 bytes (0 B) copied, 7.7241e-05 s, 0.0 kB/s
Of course, you need /dev/zero. The special device /dev/null returns nothing. finger@larrylap:~> dd if=/dev/zero of=/tmp/foo bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0.000614026 s, 163 kB/s finger@larrylap:~> dd if=/dev/urandom of=/tmp/foo bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0.00104014 s, 96.1 kB/s finger@larrylap:~> dd if=/dev/random of=/tmp/foo bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0.000995256 s, 100 kB/s I had enough entries in the entropy pool to get 100 items from /dev/random. These runs were done on 13.1-RC1 on a real machine. Larry Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2013-10-21 at 13:39 -0500, Larry Finger wrote:
On 10/21/2013 01:12 PM, Christian Boltz wrote:
Hello,
Am Montag, 21. Oktober 2013 schrieb Dominique Leuenberger a.k.a. Dimstar:
The 'surprise' to most is not really dd's behavior, but the fact that /dev/random can 'run out of data', which is different to /dev/null.
/dev/null does not even start to run ;-)
# dd if=/dev/null of=/tmp/foo bs=100 count=1 0+0 records in 0+0 records out 0 bytes (0 B) copied, 7.7241e-05 s, 0.0 kB/s
Of course, you need /dev/zero. The special device /dev/null returns nothing.
Yep... that was my bad... in the haste... and Christian spotted it (as indicated in his sig, for the ones that saw it).
finger@larrylap:~> dd if=/dev/random of=/tmp/foo bs=100 count=1 1+0 records in 1+0 records out 100 bytes (100 B) copied, 0.000995256 s, 100 kB/s
I had enough entries in the entropy pool to get 100 items from /dev/random. These runs were done on 13.1-RC1 on a real machine.
Just do it multiple times in a row.. you will end up with truncated
files.. but I'm sure there have been sufficient explanations and tips by
now that it is understood... and we can let it rest.
Dominique
--
Dimstar / Dominique Leuenberger
On Mon, Oct 21, 2013 at 04:21:35PM +0200, Dominique Leuenberger a.k.a. Dimstar wrote:
the point of dd is to read 'blocks' in chunks (size specified by bs=) until the 'END of input is reached'.
/dev/random is not an 'endless' buffer and as such, once the end is reached, dd stops copying. count= means a MAX amount of blocks to be copied from input; and as many blocks as there are with bs= bytes.
This is actually not what happens. You don't get an EOF when reading
from /dev/random - but neither you get as many bytes as you requested:
mike@unicorn:~> strace -o logg dd if=/dev/random of=/dev/null bs=1K count=16
dd: warning: partial read (128 bytes); suggest iflag=fullblock
0+16 records in
0+16 records out
282 bytes (282 B) copied, 26.4863 s, 0.0 kB/s
read(0, "\0\322\214\201\304\3321\10\344/\270\260?\30}\367>\3UX\270\243G\336\303\323\374\270\16\7\375\277"..., 1024) = 128
read(0, "\223\31T\204a\307Qr0\356Z\370\356\17\210\223\7$S\326\371\365|\246\4\213i\37\332)|\330"..., 1024) = 42
read(0, "^H\26u\377\234\213S", 1024) = 8
read(0, "\34\26\373\377\275\5\2Q", 1024) = 8
read(0, "E\334\4Y\277\364\351\25", 1024) = 8
read(0, "\27c.0\202\274D\331", 1024) = 8
read(0, "+\3U\214\246=\275\21", 1024) = 8
read(0, "\354p\253\267f\344\325\336", 1024) = 8
read(0, "D\302\302\305!\26z{", 1024) = 8
read(0, "\t\370\1\331\340
Hi Michal, On 10/22/2013 08:39 AM, Michal Kubecek wrote:
strace -o logg dd if=/dev/random of=/dev/null bs=1K count=16 dd: warning: partial read (128 bytes); suggest iflag=fullblock 0+16 records in 0+16 records out 282 bytes (282 B) copied, 26.4863 s, 0.0 kB/s
did you see the warning? I just saw it a second before your mail arrived. dd only issues that warning if count > 1. I'll discuss that upstreams if this is an off-by-one, or intended. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/22/2013 08:42 AM, Bernhard Voelker wrote:
Hi Michal,
On 10/22/2013 08:39 AM, Michal Kubecek wrote:
strace -o logg dd if=/dev/random of=/dev/null bs=1K count=16 dd: warning: partial read (128 bytes); suggest iflag=fullblock 0+16 records in 0+16 records out 282 bytes (282 B) copied, 26.4863 s, 0.0 kB/s
did you see the warning? I just saw it a second before your mail arrived. dd only issues that warning if count > 1.
I'll discuss that upstreams if this is an off-by-one, or intended.
http://bugs.gnu.org/15680 Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Oct 22, 2013 at 08:42:19AM +0200, Bernhard Voelker wrote:
did you see the warning? I just saw it a second before your mail arrived. dd only issues that warning if count > 1.
Interesting... I would understand such logic if a short read followed by another read meant we are skipping some data from input but I couldn't think of any situation when this would actually happen.
I'll discuss that upstreams if this is an off-by-one, or intended.
Thank you. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michal Kubecek
On Tue, Oct 22, 2013 at 08:42:19AM +0200, Bernhard Voelker wrote:
did you see the warning? I just saw it a second before your mail arrived. dd only issues that warning if count > 1.
Interesting... I would understand such logic if a short read followed by another read meant we are skipping some data from input but I couldn't think of any situation when this would actually happen.
dd if=/dev/sdx will terminate on the first short read caused by a media error. dd if=/dev/sdx conv=noerror will not. Thus you can end up with partial blocks in the middle of the output. 4k 4k 2k (2k missing after media error) 1k (3k missing after media error) 4k That means a output file that represents a filesystem is totally unparsable after the first partial block because the offset from the start of the file is wrong. I normally solve this with conv=noerror,sync Unfortunately that null fills the rest of the block which can be a real problem if you want to use large blocks. If there is a way to invoke dd with large blocks with no risk of excessive data loss every time a media error is hit, I'd love to know about it. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-10-22 14:02, Greg Freemyer wrote:
That means a output file that represents a filesystem is totally unparsable after the first partial block because the offset from the start of the file is wrong.
I normally solve this with conv=noerror,sync
Unfortunately that null fills the rest of the block which can be a real problem if you want to use large blocks.
If there is a way to invoke dd with large blocks with no risk of excessive data loss every time a media error is hit, I'd love to know about it.
That's what "dd_rhelp" is for :-) -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
On Tue, Oct 22, 2013 at 8:55 AM, Carlos E. R.
On 2013-10-22 14:02, Greg Freemyer wrote:
That means a output file that represents a filesystem is totally unparsable after the first partial block because the offset from the start of the file is wrong.
I normally solve this with conv=noerror,sync
Unfortunately that null fills the rest of the block which can be a real problem if you want to use large blocks.
If there is a way to invoke dd with large blocks with no risk of excessive data loss every time a media error is hit, I'd love to know about it.
That's what "dd_rhelp" is for :-)
That was new to me, but per http://www.kalysto.org/utilities/dd_rhelp/index.en.html it is recommended that ddrescue be used instead. ddrescue is in 13.1 (It is in the package gnu_ddrescue) Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-10-22 18:32, Greg Freemyer wrote:
On Tue, Oct 22, 2013 at 8:55 AM, Carlos E. R. <> wrote:
That's what "dd_rhelp" is for :-)
That was new to me, but per http://www.kalysto.org/utilities/dd_rhelp/index.en.html it is recommended that ddrescue be used instead.
ddrescue is in 13.1 (It is in the package gnu_ddrescue)
Yes, I have seen that, but I'm not familiar with it yet. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
On Tue, Oct 22, 2013 at 08:42:19AM +0200, Bernhard Voelker wrote:
did you see the warning? I just saw it a second before your mail arrived. dd only issues that warning if count > 1.
I'll discuss that upstreams if this is an off-by-one, or intended.
When in doubt, look into the source. :-) In fact, dd only issues a warning about a short read if it is followed by a read which returns a positive (>0) value. This makes sense as the only way to distinguish a "natural" short read at the end of a file from a short read of the type we have with /dev/random is by checking whether the next read returns 0. With count=1, we have no way to distinguish these two cases unless we do another read() which is something dd definitely shouldn't do (or at least not by default). Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-10-22 08:42, Bernhard Voelker wrote:
Hi Michal,
On 10/22/2013 08:39 AM, Michal Kubecek wrote:
strace -o logg dd if=/dev/random of=/dev/null bs=1K count=16 dd: warning: partial read (128 bytes); suggest iflag=fullblock 0+16 records in 0+16 records out 282 bytes (282 B) copied, 26.4863 s, 0.0 kB/s
did you see the warning? I just saw it a second before your mail arrived. dd only issues that warning if count > 1.
Interesting... I'll try to keep that in mind. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
Hello, Am Montag, 21. Oktober 2013 schrieb Carlos E. R.:
This also means something else: the instructions to crate usb sticks using dd should be revised, again. I had the RC1 stick fail to boot, and had to dd it again.
If you have the 32bit version, this was probably https://bugzilla.novell.com/show_bug.cgi?id=841392 (which is fixed in the meantime, but after RC1) Regards, Christian Boltz -- general rule: if Olaf reports a bug, it is a valid bug. [Olaf Hering while reopening https://bugzilla.novell.com/show_bug.cgi?id=168595] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2013-10-21 17:26, Christian Boltz wrote:
Hello,
Am Montag, 21. Oktober 2013 schrieb Carlos E. R.:
This also means something else: the instructions to crate usb sticks using dd should be revised, again. I had the RC1 stick fail to boot, and had to dd it again.
If you have the 32bit version, this was probably https://bugzilla.novell.com/show_bug.cgi?id=841392 (which is fixed in the meantime, but after RC1)
No, it was the 64 bit version. The usb stick had the beta version, which worked. I then copied, using dd, the RC1 on top of it. It failed to boot, I don't remember the message. So I copied a hundred blocks of zeroes on the same stick (with dd), and again the RC1. This time it worked. Interestingly, the msdos label of the original stick format survives to this moment. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
В Sun, 20 Oct 2013 20:30:11 +0200 (CEST)
"Carlos E. R."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday, 2013-10-20 at 20:01 +0400, Kyrill Detinov wrote:
On Sun, 20 Oct 2013 16:28:39 +0200 (CEST) Carlos E. R. wrote:
Why if the input is /dev/random, the size of the output file is not 100 bytes? Some times 16 bytes, some 20, some 9...
Not dd problem.
http://superuser.com/questions/359599/why-is-my-dev-random-so-slow-when-usin...
That explains why "random" is slow (which I knew), but not why dd aborts.
You see, dd, pulling from /dev/random, in 12.3 yields the expected result and is reasonably fast, whereas in 13.1 it doesn't either.
Are they both physical systems or one is installed in VM? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJkiTgACgkQR6LMutpd94x8+ACdHFpGxvGFTPKbu91hyKn/41sx QngAn08D0KcSNH9kWJIBho6Tk/Fz7zLX =Q6Qg -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-10-21 03:54, Andrey Borzenkov wrote:
В Sun, 20 Oct 2013 20:30:11 +0200 (CEST) "Carlos E. R." <> пишет:
That explains why "random" is slow (which I knew), but not why dd aborts.
You see, dd, pulling from /dev/random, in 12.3 yields the expected result and is reasonably fast, whereas in 13.1 it doesn't either.
Are they both physical systems or one is installed in VM?
One is a VM (vmplayer), the other is a laptop. I can measure (time) the operation in that same laptop under 11.4 and 13.1 - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJk/Y4ACgkQtTMYHG2NR9VU3QCfUUgvEV5h64MmL+KSWqtSUtjj 7TcAn32ZjS3pW68+TNaG9/jEjF547UHP =BDfP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (15)
-
Andreas Schwab -
Andrey Borzenkov -
Bernhard Voelker -
Carlos E. R. -
Carlos E. R. -
Christian Boltz -
Cristian Rodríguez -
Dimstar / Dominique Leuenberger -
Dominique Leuenberger a.k.a. Dimstar
-
Greg Freemyer -
Jan Engelhardt -
Kyrill Detinov -
Larry Finger -
Michal Kubecek -
Per Jessen