Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #267123 > unrolled thread
| Started by | gene heskett <gheskett@shentel.net> |
|---|---|
| First post | 2024-02-07 21:40 +0100 |
| Last post | 2024-02-09 14:20 +0100 |
| Articles | 20 on this page of 98 — 20 participants |
Back to article view | Back to linux.debian.user
Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-07 21:40 +0100
Re: Unidentified subject! Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-08 05:30 +0100
Re: Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-10 11:00 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 11:40 +0100
shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-10 13:50 +0100
Re: shred bug? [was: Unidentified subject!] tomas@tuxteam.de - 2024-02-10 14:00 +0100
Re: shred bug? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 15:00 +0100
Re: shred bug? <tomas@tuxteam.de> - 2024-02-10 15:40 +0100
Re: shred bug? Gremlin <scott-andrews@columbus.rr.com> - 2024-02-10 14:40 +0100
Re: shred bug? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 14:40 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 01:10 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-11 01:20 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 01:30 +0100
Re: shred bug? [was: Unidentified subject!] debian-user@howorth.org.uk - 2024-02-11 14:00 +0100
Re: shred bug? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 14:30 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-11 08:10 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-11 15:40 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-11 15:50 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-11 16:00 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-11 16:00 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-12 18:00 +0100
Re: shred bug? [was: Unidentified subject!] Curt <curty@free.fr> - 2024-02-12 18:00 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-12 22:00 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-12 22:10 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-13 06:50 +0100
Re: shred bug? [was: Unidentified subject!] David Wright <deblis@lionunicorn.co.uk> - 2024-02-11 16:30 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 13:20 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 13:40 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-13 13:50 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 14:00 +0100
Re: shred bug? [was: Unidentified subject!] David Wright <deblis@lionunicorn.co.uk> - 2024-02-13 16:40 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 17:30 +0100
Re: shred bug? [was: Unidentified subject!] debian-user@howorth.org.uk - 2024-02-13 18:50 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-13 22:10 +0100
Re: shred bug? [was: Unidentified subject!] <tomas@tuxteam.de> - 2024-02-14 06:50 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 19:00 +0100
Re: shred bug? [was: Unidentified subject!] Greg Wooledge <greg@wooledge.org> - 2024-02-13 20:00 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 20:40 +0100
Re: shred bug? [was: Unidentified subject!] gene heskett <gheskett@shentel.net> - 2024-02-13 20:40 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-13 20:50 +0100
Re: shred bug? [was: Unidentified subject!] gene heskett <gheskett@shentel.net> - 2024-02-13 21:30 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-13 22:10 +0100
Re: shred bug? [was: Unidentified subject!] gene heskett <gheskett@shentel.net> - 2024-02-13 22:50 +0100
Re: shred bug? [was: Unidentified subject!] David Wright <deblis@lionunicorn.co.uk> - 2024-02-15 06:40 +0100
Re: shred bug? [was: Unidentified subject!] David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 23:50 +0100
Re: shred bug? [was: Unidentified subject!] Max Nikulin <manikulin@gmail.com> - 2024-02-13 03:40 +0100
Re: shred bug? [was: Unidentified subject!] "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 16:30 +0100
Re: shred bug? [was: Unidentified subject!] Michael Stone <mstone@debian.org> - 2024-02-16 16:00 +0100
Re: Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-10 18:50 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-10 19:40 +0100
Re: Unidentified subject! gene heskett <gheskett@shentel.net> - 2024-02-10 20:30 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 00:50 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 09:10 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 21:50 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 00:40 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 09:20 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 11:10 +0100
Fast Random Data Generation (Was: Re: Unidentified subject!) Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-11 11:30 +0100
Re: Fast Random Data Generation "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 12:30 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-11 13:20 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) David Christensen <dpchrist@holgerdanske.com> - 2024-02-12 07:20 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-12 17:40 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) David Christensen <dpchrist@holgerdanske.com> - 2024-02-12 22:30 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-13 18:40 +0100
Re: Fast Random Data Generation (Was: Re: Unidentified subject!) Jeffrey Walton <noloader@gmail.com> - 2024-02-12 22:30 +0100
Re: Unidentified subject! "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-11 12:20 +0100
Re: Unidentified subject! Jeffrey Walton <noloader@gmail.com> - 2024-02-11 16:20 +0100
Re: Unidentified subject! David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 23:00 +0100
Re: Unidentified subject! Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-10 15:40 +0100
Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 16:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 17:20 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 17:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) gene heskett <gheskett@shentel.net> - 2024-02-09 09:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Ralph Aichinger <ra@h5.or.at> - 2024-02-08 18:00 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Jeffrey Walton <noloader@gmail.com> - 2024-02-08 20:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 22:00 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 22:20 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 22:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 23:10 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 22:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) gene heskett <gheskett@shentel.net> - 2024-02-09 14:00 +0100
Re: Things I don't touch with a 3.048m barge pole "Thomas Schmitt" <scdbackup@gmx.net> - 2024-02-09 14:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (WasRe: Unidentified subject!) David Christensen <dpchrist@holgerdanske.com> - 2024-02-10 07:00 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage(WasRe: Unidentified subject!) gene heskett <gheskett@shentel.net> - 2024-02-10 18:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Arno Lehmann <al@its-lehmann.de> - 2024-02-09 09:50 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Max Nikulin <manikulin@gmail.com> - 2024-02-08 18:30 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 21:40 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Gremlin <scott-andrews@columbus.rr.com> - 2024-02-08 22:10 +0100
Re: Things I don't touch with a 3.048m barge pole: USB storage (Was Re: Unidentified subject!) Andy Smith <andy@strugglers.net> - 2024-02-08 22:20 +0100
Re: Unidentified subject! Richmond <dnomhcir@gmx.com> - 2024-02-08 23:50 +0100
Re: Unidentified subject! Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-09 00:10 +0100
Re: Unidentified subject! Charles Curley <charlescurley@charlescurley.com> - 2024-02-09 00:50 +0100
Re: Unidentified subject! Richmond <dnomhcir@gmx.com> - 2024-02-09 05:50 +0100
Re: Unidentified flying subject! Charles Curley <charlescurley@charlescurley.com> - 2024-02-09 07:50 +0100
Re: Unidentified flying subject! Richmond <dnomhcir@gmx.com> - 2024-02-09 14:20 +0100
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-02-13 21:30 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I77zI-9WMS-1@gated-at.bofh.it> |
| In reply to | #267368 |
On 2/13/24 14:44, Thomas Schmitt wrote: > Hi, > > Gene Heskett wrote: >> Next experiment is a pair of 4T Silicon Power SSD's > > When f3 has (hopefully) given its OK, the topic of a full write-and-read > test will come up again. I'm looking forward to all the spin-off topics. > I'll have to admit it has been quite educational. Now, can I remember it next week? YTBD.> > Have a nice day :) You too Thomas. Take care and stay well. > Thomas Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-02-13 22:10 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I78cq-9Xkc-3@gated-at.bofh.it> |
| In reply to | #267366 |
On 2/13/24 11:31, gene heskett wrote: > Next experiment is a pair of 4T > Silicon Power SSD's When they & the startech usb3 adapters arrive. I'll > get that NAS built for amanda yet. 2.5" SATA SSD's and SATA to USB adapter cables for $187.97 + $10.99 = $198.96 each set? https://www.amazon.com/dp/B0BVLRFFWQ https://www.amazon.com/dp/B00HJZJI84 Why not external USB drives for $192.99? https://www.amazon.com/dp/B0C6XVZS4K For $7 more, you can get the "Pro edition" in black with two cables: https://www.amazon.com/dp/B0C69QD5NK You could plug those into the two USB-C 3.1 Gen 2 ports on your Asus PRIME Z370-A II motherboard. David
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-02-13 22:50 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I78P7-9XwL-1@gated-at.bofh.it> |
| In reply to | #267374 |
On 2/13/24 16:00, David Christensen wrote: > On 2/13/24 11:31, gene heskett wrote: >> Next experiment is a pair of 4T Silicon Power SSD's When they & the >> startech usb3 adapters arrive. I'll get that NAS built for amanda yet. > > > 2.5" SATA SSD's and SATA to USB adapter cables for $187.97 + $10.99 = > $198.96 each set? > > https://www.amazon.com/dp/B0BVLRFFWQ > > https://www.amazon.com/dp/B00HJZJI84 > > > Why not external USB drives for $192.99? > > https://www.amazon.com/dp/B0C6XVZS4K > > > For $7 more, you can get the "Pro edition" in black with two cables: > > https://www.amazon.com/dp/B0C69QD5NK > > > You could plug those into the two USB-C 3.1 Gen 2 ports on your Asus > PRIME Z370-A II motherboard. > Maybe, but these sata types have the the mounting bolts the usb versions don't. And fits the drive adapters I already have that put both in one drive tray. Not to mention if Taiwan has a similar product, I tend to buy it. So are the 4 2T gigastones I'll fill the next 2 drawers with so I should wind up with a 16T backup server's LVM. with a 1/2T Samsung 870 as a holding disk. Running a bpi-m5 headless, maybe < 20 watts. Whats not to like? > > David > > > . Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-02-15 06:40 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I7CDv-afGt-3@gated-at.bofh.it> |
| In reply to | #267356 |
On Tue 13 Feb 2024 at 11:21:08 (-0500), Greg Wooledge wrote: > On Tue, Feb 13, 2024 at 09:35:11AM -0600, David Wright wrote: > > On Tue 13 Feb 2024 at 07:15:48 (-0500), Greg Wooledge wrote: > > > On Mon, Feb 12, 2024 at 11:01:47PM -0600, David Wright wrote: > > > > … but not much. For me, "standard output" is /dev/fd/1, yet it seems > > > > unlikely that anyone is going to use >&1 in the manner of the example. > > > > > > Standard output means "whatever file descriptor 1 points to". That > > > could be a file, a pipe, a terminal (character device), etc. > > > > Why pick on 1? > > It's the definition. Standard input is FD 0, standard output is FD 1, > and standard error is FD 2. > > > . It demonstrates the shell syntax element required (&) in order to > > avoid truncating the file, rather than shred overwriting it. > > You are confused. You're making assumptions about shell syntax that > are simply not true. You're right. I was looking too hard at the right side of the > and neglecting the implied left side. It's always worth running these things past your eyes. Thanks for the clear exposition that followed. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-02-11 23:50 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I6qO5-9wrt-1@gated-at.bofh.it> |
| In reply to | #267294 |
On 2/11/24 06:54, Greg Wooledge wrote: > On Sun, Feb 11, 2024 at 03:45:21PM +0100, tomas@tuxteam.de wrote: >> On Sun, Feb 11, 2024 at 09:37:31AM -0500, Greg Wooledge wrote: >>> On Sun, Feb 11, 2024 at 08:02:12AM +0100, tomas@tuxteam.de wrote: >> >> [...] >> >>>> What Thomas was trying to do is to get a cheap, fast random number >>>> generator. Shred seems to have such. >>> >>> Well... I certainly wouldn't call it a bug. Maybe a feature request. >> >> Still there's the discrepancy between doc and behaviour. > > There isn't. The documentation says: > > SYNOPSIS > shred [OPTION]... FILE... I interpret the above line to be a prototype for invoking the shred(1) program: * "shred" is the program name * "[OPTION]..." is one or more option specifiers that may be omitted. Each should be described below. * "FILE..." is one or more argument specifies that should be file system paths (strings). > DESCRIPTION > Overwrite the specified FILE(s) repeatedly, in order to make it harder > for even very expensive hardware probing to recover the data. > > If FILE is -, shred standard output. I interpret the above line at face value -- if the caller provides a dash as the argument, shred(1) will operate on standard output. > In every sentence, the word FILE appears. There's nothing in there > which says "you can operate on a non-file". Dash is not a file, yet the above sentence says shred(1) can operate on it. > Once you grasp what the command is *intended* to do (rewind and overwrite > a file repeatedly), it makes absolutely perfect sense that it should > only operate on rewindable file system objects. An expert may infer what you have stated, but I prefer manual pages that are explicit. The GNU project must have found a need for the FILE='-' feature, otherwise it would not exist. The manual page should describe that need (e.g. why) and how to properly use shred(1) to solve the need. > If you want it to write a stream of data instead of performing its normal > operation (rewinding and rewriting), that's a new feature. Humans are (in)famous for doing unexpected things. > If you'd prefer the documentation to say explicitly "only regular files > and block devices are allowed", that would be an upstream documentation > *clarification* request. Apparently, shred(1) has both an info(1) page (?) and a man(1) page. The obvious solution is to write one document that is complete and correct, and use it everywhere -- e.g. DRY. David
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-02-13 03:40 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I6QSd-9Msg-1@gated-at.bofh.it> |
| In reply to | #267313 |
On 12/02/2024 05:41, David Christensen wrote: > > Apparently, shred(1) has both an info(1) page (?) and a man(1) page. The > obvious solution is to write one document that is complete and correct, > and use it everywhere -- e.g. DRY. https://www.gnu.org/prep/standards/html_node/Man-Pages.html 6.9 Man Pages in "GNU Coding Standards" > In the GNU project, man pages are secondary. It is not necessary or > expected for every GNU program to have a man page, but some of them do. A standalone man page is not the same as a section in a document describing the whole bundle. Notice that man uses direct formatting, not logical markup. E.g. there is no dedicated structure for links to other man pages. They were not designed as hypertext documents, they are to be printed on paper. In this sense texinfo is a more advanced format. P.S. I admit that in some cases "man bash" may be more convenient for searching than an info browser.
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-02-11 16:30 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I6jWi-9shk-1@gated-at.bofh.it> |
| In reply to | #267293 |
Hi, tomas@tuxteam.de wrote: > Still there's the discrepancy between doc and behaviour. Depends at which documentation you look. Obviously stemming from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=155175#36 i read in https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html "A file of ‘-’ denotes standard output. The intended use of this is to shred a removed temporary file. For example: [shell wizzardry]" It works as long as stdout is connected to a data file, or block device, or directory, or symbolic link, or to a character device that is not a terminal. (Maybe it refuses later on some of these types, but not at the location with the message "invalid file type". I wonder if i can connect stdout to a symbolic link instead of its target.) The bug would thus have to be filed against the man page https://sources.debian.org/src/coreutils/9.4-3/man/shred.1/ which says only "If FILE is \-, shred standard output." The info empire of coreutils says what above web manual says. https://sources.debian.org/src/coreutils/9.4-3/doc/coreutils.texi/#L10705 Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2024-02-16 16:00 +0100 |
| Subject | Re: shred bug? [was: Unidentified subject!] |
| Message-ID | <I87QZ-aykO-1@gated-at.bofh.it> |
| In reply to | #267272 |
On Sun, Feb 11, 2024 at 08:02:12AM +0100, tomas@tuxteam.de wrote: >What Thomas was trying to do is to get a cheap, fast random number >generator. Shred seems to have such. You're better off with /dev/urandom, it's much easier to understand what it's trying to do, vs the rather baroque logic in shred. In fact, there's nothing in shred's documenation AFAICT that suggests it should be used as a random number generator. For pure speed, playing games with openssl enc and /dev/zero will generally win. If speed doesn't matter, we're back to /dev/urandom as the simplest and most direct solution. FWIW, the main use for shred in 2024 is: to be there so someone's old script doesn't break. There's basically no good use case for it, and it probably shouldn't have gotten into coreutils in the first place. The multipass pattern stuff is cargo-cult voodoo--a single overwrite with zeros will be as effective as anything else--and on modern storage/filesystems there's a good chance your overwrite won't overwrite anything anyway. Probably the right answer is a kernel facility (userspace can't guarantee anything). If you're really sure that overwrites work on your system, `shred -n0 -z` will be the fastest way to do that. The docs say don't do that because SSDs might optimize that away, but SSDs probably aren't overwriting anything anyway (also mentioned in the docs). ¯\_(ツ)_/¯
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-02-10 18:50 +0100 |
| Message-ID | <I5ZEd-9fYL-1@gated-at.bofh.it> |
| In reply to | #267220 |
On 2/10/24 05:39, Thomas Schmitt wrote:
> Hi,
>
> Gene Heskett wrote:
>> Is bash not actually bash these days? It is not doing for loops for me.
>
> Come on Gene, be no sophie. Copy+paste your failing line here. :))
>
Alexander M. posted it a few days ago but my fading eyesight couldn't
see the diffs between () and {} in a 6 point font. I need a bigger,
more legible font in t-bird. Or blow it up about 3x. Which doesn't
stick, its gone with next msg. Grrrr.
Thank Thomas.
[...]> Have a nice day :)
>
> Thomas
>
> .
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-02-10 19:40 +0100 |
| Message-ID | <I60qB-9guv-3@gated-at.bofh.it> |
| In reply to | #267240 |
Hi,
gene heskett wrote:
> my fading eyesight couldn't see
> the diffs between () and {} in a 6 point font. I need a bigger, more
> legible font in t-bird.
That's why i propose to copy+paste problematic command lines.
Your mouse can read it, your mail client can send it, and we have
youngsters here of merely 60 years who will be glad to tell our
most senior regular why the lines don't work.
With some luck this creates nostalgic tangents about how the used features
evolved since the early 1980s.
In the other thread about the /dev/sdm test:
> Creating file 39.h2w ... 1.98% -- 1.90 MB/s -- 257:11:32
> but is taking a few bytes now and then.
> [...]
> $ ls -l
> total 40627044
> [...]
> $ sudo f3probe --destructive --time-ops /dev/sdm
> Bad news: The device `/dev/sdm' is a counterfeit of type limbo
> Device geometry:
> *Usable* size: 59.15 GB (124050944 blocks)
> Announced size: 1.91 TB (4096000000 blocks)
That's really barefaced.
How can the seller believe to get away with a problem which will show
already after a few dozen GB were written ?
> Probe time: 2.07s
That's indeed a quick diagnosis. Congrats to the developers of f3probe.
Have a nice day :)
Thomas
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2024-02-10 20:30 +0100 |
| Message-ID | <I61d0-9gZC-3@gated-at.bofh.it> |
| In reply to | #267243 |
On 2/10/24 13:30, Thomas Schmitt wrote:
> Hi,
>
> gene heskett wrote:
>> my fading eyesight couldn't see
>> the diffs between () and {} in a 6 point font. I need a bigger, more
>> legible font in t-bird.
>
> That's why i propose to copy+paste problematic command lines.
>
> Your mouse can read it, your mail client can send it, and we have
> youngsters here of merely 60 years who will be glad to tell our
> most senior regular why the lines don't work.
>
> With some luck this creates nostalgic tangents about how the used features
> evolved since the early 1980s.
>
Or even the later 1970's when I made a cosmac super elf RCA 1802 board
do anything I could dream up. Made the video hdwe, and the interface to
control a broadcast vcr. S-100 bus adapter was the only thing I bought,
and had to build that from a kit. Built it for KRCR-TV in Redding CA,
it was so useful to the production folks they used it many times a day
from '79 to mid 90's when it burnt to the ground, That's eons in a tv
station control room where stuff is often replaced before its fully
written off tax wise in 5 years. Fun times back then. Now I'm searching
amazon for a pi-clone hat with a 6 pack of sata-iii sockets on it, and
coming up MT. Sniff...
>
> In the other thread about the /dev/sdm test:
>> Creating file 39.h2w ... 1.98% -- 1.90 MB/s -- 257:11:32
>> but is taking a few bytes now and then.
>> [...]
>> $ ls -l
>> total 40627044
>> [...]
>> $ sudo f3probe --destructive --time-ops /dev/sdm
>> Bad news: The device `/dev/sdm' is a counterfeit of type limbo
>> Device geometry:
>> *Usable* size: 59.15 GB (124050944 blocks)
>> Announced size: 1.91 TB (4096000000 blocks)
>
> That's really barefaced.
> How can the seller believe to get away with a problem which will show
> already after a few dozen GB were written ?
>
>
>> Probe time: 2.07s
>
> That's indeed a quick diagnosis. Congrats to the developers of f3probe.
>
>
> Have a nice day :)
>
> Thomas
>
> .
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-02-11 00:50 +0100 |
| Message-ID | <I65gB-9jkF-1@gated-at.bofh.it> |
| In reply to | #267243 |
On 2/10/24 10:28, Thomas Schmitt wrote: > In the other thread about the /dev/sdm test: >> Creating file 39.h2w ... 1.98% -- 1.90 MB/s -- 257:11:32 >> but is taking a few bytes now and then. >> [...] >> $ ls -l >> total 40627044 >> [...] >> $ sudo f3probe --destructive --time-ops /dev/sdm >> Bad news: The device `/dev/sdm' is a counterfeit of type limbo >> Device geometry: >> *Usable* size: 59.15 GB (124050944 blocks) >> Announced size: 1.91 TB (4096000000 blocks) >> ... >> Probe time: 2.07s Which other thread? Please provide a URL to archived post. So, the 2 TB USB SSD's are really scam 64 GB devices? David
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-02-11 09:10 +0100 |
| Message-ID | <I6d4t-9oeV-7@gated-at.bofh.it> |
| In reply to | #267257 |
Hi, i wrote: > > In the other thread about the /dev/sdm test: Gene Heskett wrote: > > > Creating file 39.h2w ... 1.98% -- 1.90 MB/s -- 257:11:32 > > > [...] > > > $ sudo f3probe --destructive --time-ops /dev/sdm > > > Bad news: The device `/dev/sdm' is a counterfeit of type limbo > > > Device geometry: > > > *Usable* size: 59.15 GB (124050944 blocks) > > > Announced size: 1.91 TB (4096000000 blocks) David Christensen wrote: > Which other thread? Please provide a URL to archived post. https://lists.debian.org/msgid-search/e7a0c1a1-f973-4007-a86d-8d91d8d915aa@shentel.net https://lists.debian.org/msgid-search/b566504b-5677-4d84-b5b3-b0de632304b6@shentel.net > So, the 2 TB USB SSD's are really scam 64 GB devices? The manufacturer would probably state that it's no intentional scam but just poor product quality. (Exploiting Hanlon's Razor.) It might be intentional that the write speed gets slower and slower as the end of the usable area is approached. This avoids the need for confessing the failure to the operating system. But it might also be an honest attempt of the disk's firmware to find some blocks which can take and give back the arriving data. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-02-11 21:50 +0100 |
| Message-ID | <I6oVX-9vkn-15@gated-at.bofh.it> |
| In reply to | #267273 |
On 2/11/24 00:07, Thomas Schmitt wrote: >>> In the other thread about the /dev/sdm test: > Gene Heskett wrote: >>>> Creating file 39.h2w ... 1.98% -- 1.90 MB/s -- 257:11:32 >>>> [...] >>>> $ sudo f3probe --destructive --time-ops /dev/sdm >>>> Bad news: The device `/dev/sdm' is a counterfeit of type limbo >>>> Device geometry: >>>> *Usable* size: 59.15 GB (124050944 blocks) >>>> Announced size: 1.91 TB (4096000000 blocks) > > David Christensen wrote: >> Which other thread? Please provide a URL to archived post. > > https://lists.debian.org/msgid-search/e7a0c1a1-f973-4007-a86d-8d91d8d915aa@shentel.net > https://lists.debian.org/msgid-search/b566504b-5677-4d84-b5b3-b0de632304b6@shentel.net Thank you. :-) David
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-02-11 00:40 +0100 |
| Message-ID | <I656W-9jhs-11@gated-at.bofh.it> |
| In reply to | #267220 |
On 2/10/24 02:38, Thomas Schmitt wrote: > I have an own weak-random generator, but shred beats it by a factor of 10 > when writing to /dev/null. As a baseline, here is a 2011 Dell Latitude E6520 with Debian generating a non-repeatable 1 GiB stream of cryptographically secure pseudo-random numbers: 2024-02-10 14:10:27 dpchrist@laalaa ~ $ lscpu | grep 'Model name' Model name: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz 2024-02-10 14:01:25 dpchrist@laalaa ~ $ cat /etc/debian_version ; uname -a 11.8 Linux laalaa 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux 2024-02-10 14:01:47 dpchrist@laalaa ~ $ bash --version | head -n 1 GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu) 2024-02-10 14:13:08 dpchrist@laalaa ~ $ time dd if=/dev/urandom bs=8K count=128K | wc -c 1073741824 131072+0 records in 131072+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.30652 s, 249 MB/s real 0m4.311s user 0m0.107s sys 0m4.695s If the OP has a known good storage device of equal or larger size than the UUT(s), I suggest using /dev/urandom and tee(1) to write the same CSPRN stream to all of the devices and using cmp(1) to validate. I use Perl. When I needed a CSPRNG, I searched and found: https://metacpan.org/pod/Math::Random::ISAAC::XS Using Perl and Math::Random::ISAAC::XS to generate a repeatable stream of cryptographically secure pseudo-random numbers: 2024-02-10 14:09:12 dpchrist@laalaa ~ $ perl -v | head -n 2 | grep . This is perl 5, version 32, subversion 1 (v5.32.1) built for x86_64-linux-gnu-thread-multi 2024-02-10 14:09:53 dpchrist@laalaa ~ $ perl -MMath::Random::ISAAC::XS -e 'print $Math::Random::ISAAC::XS::VERSION, $/' 1.004 2024-02-10 14:10:32 dpchrist@laalaa ~ $ time perl -MMath::Random::ISAAC::XS -e '$i=Math::Random::ISAAC::XS->new(12345678); print pack 'L',$i->irand while 1' | dd bs=8K count=128K | wc -c 1073741824 131072+0 records in 131072+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 82.6523 s, 13.0 MB/s real 1m22.657s user 1m22.892s sys 0m5.810s The 'perl ... | dd ...' pipeline appears to be limited to a block size of 8,192 bytes. I do not know if this is due to bash(1), perl(1), or dd(1) (?). The repeatability of the ISAAC stream would substitute for the known good storage device, but the throughput is ~19x slower than /dev/urandom. A drive capacity validation tool would want to feature concurrent threads and I/O on SMP machines. David
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-02-11 09:20 +0100 |
| Message-ID | <I6dea-9oi8-3@gated-at.bofh.it> |
| In reply to | #267256 |
Hi, David Christensen wrote: > $ time dd if=/dev/urandom bs=8K count=128K | wc -c > [...] > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.30652 s, 249 MB/s This looks good enough for practical use on spinning rust and slow SSD. Maybe the "wc" pipe slows it down ? ... not much on 4 GHz Xeon with Debian 11: $ time dd if=/dev/urandom bs=8K count=128K | wc -c ... 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.13074 s, 260 MB/s $ time dd if=/dev/urandom bs=8K count=128K of=/dev/null ... 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.95569 s, 271 MB/s Last time i tested /dev/urandom it was much slower on comparable machines and also became slower as the amount grew. Therefore i still have my amateur RNG which works with a little bit of MD5 and a lot of EXOR. It produces about 1100 MiB/s on the 4 GHz machine. No cryptographical strength, but chaotic enough to avoid any systematic pattern which could be recognized by a cheater and represented with some high compression factor. The original purpose was to avoid any systematic interference with the encoding of data blocks on optical media. I am sure there are faster RNGs around with better random quality. > $ time perl -MMath::Random::ISAAC::XS -e '$i=Math::Random::ISAAC::XS->new(12345678); print pack 'L',$i->irand while 1' | dd bs=8K count=128K | wc -c > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 82.6523 s, 13.0 MB/s Now that's merely sufficient for shredding the content of a BD-RE medium or a slow USB stick. > I suggest using /dev/urandom and tee(1) to write the same CSPRN > stream to all of the devices and using cmp(1) to validate. I'd propose to use a checksummer like md5sum or sha256sum instead of cmp: $random_generator | tee $target | $checksummer dd if=$target bs=... count=... | $checksummer This way one can use unreproducible random streams and does not have to store the whole stream on a reliable device for comparison. Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2024-02-11 11:10 +0100 |
| Message-ID | <I6eWC-9plk-7@gated-at.bofh.it> |
| In reply to | #267274 |
On 2/11/24 00:11, Thomas Schmitt wrote: > Hi, > > David Christensen wrote: >> $ time dd if=/dev/urandom bs=8K count=128K | wc -c >> [...] >> 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.30652 s, 249 MB/s > > This looks good enough for practical use on spinning rust and slow SSD. Yes. > Maybe the "wc" pipe slows it down ? > ... not much on 4 GHz Xeon with Debian 11: > > $ time dd if=/dev/urandom bs=8K count=128K | wc -c > ... > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.13074 s, 260 MB/s > $ time dd if=/dev/urandom bs=8K count=128K of=/dev/null > ... > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.95569 s, 271 MB/s My CPU has a Max Turbo Frequency of 3.3 GHz. I would expect a 4 GHz processor to be ~21% faster, but apparently not. Baseline with pipeline, wc(1), and bs=8K due to unknown Bash pipeline bottleneck (?): 2024-02-11 01:18:33 dpchrist@laalaa ~ $ dd if=/dev/urandom bs=8K count=128K | wc -c 1073741824 131072+0 records in 131072+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.27283 s, 251 MB/s Eliminate pipeline and wc(1): 2024-02-11 01:18:44 dpchrist@laalaa ~ $ dd if=/dev/urandom of=/dev/null bs=8K count=128K 131072+0 records in 131072+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.75946 s, 286 MB/s Increase block size: 2024-02-11 01:18:51 dpchrist@laalaa ~ $ dd if=/dev/urandom of=/dev/null bs=1M count=1K 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.62874 s, 296 MB/s Concurrency: threads throughput 1 296 MB/s 2 285+286=571 MB/s 3 271+264+266=801 MB/s 4 249+250+241+262=1,002 MB/s 5 225+214+210+224+225=1,098 MB/s 6 223+199+199+204+213+205=1,243 MB/s 7 191+209+210+204+213+201+197=1,425 MB/s 8 205+198+180+195+205+184+184+189=1,540 MB/s > Last time i tested /dev/urandom it was much slower on comparable machines > and also became slower as the amount grew. Did you figure out why the Linux random number subsystem slowed, and at what amount? > Therefore i still have my amateur RNG which works with a little bit of > MD5 and a lot of EXOR. It produces about 1100 MiB/s on the 4 GHz machine. > No cryptographical strength, but chaotic enough to avoid any systematic > pattern which could be recognized by a cheater and represented with > some high compression factor. > The original purpose was to avoid any systematic interference with the > encoding of data blocks on optical media. > > I am sure there are faster RNGs around with better random quality. I assume the Linux kernel in Debian 11 is new enough to support RDRAND (?): https://en.wikipedia.org/wiki/RdRand But, my processor is too old to have Secure Key. >> $ time perl -MMath::Random::ISAAC::XS -e '$i=Math::Random::ISAAC::XS->new(12345678); print pack 'L',$i->irand while 1' | dd bs=8K count=128K | wc -c >> 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 82.6523 s, 13.0 MB/s > > Now that's merely sufficient for shredding the content of a BD-RE medium > or a slow USB stick. Okay. >> I suggest using /dev/urandom and tee(1) to write the same CSPRN >> stream to all of the devices and using cmp(1) to validate. > > I'd propose to use a checksummer like md5sum or sha256sum instead of cmp: > > $random_generator | tee $target | $checksummer > dd if=$target bs=... count=... | $checksummer > > This way one can use unreproducible random streams and does not have to > store the whole stream on a reliable device for comparison. TIMTOWTDI. :-) David
[toc] | [prev] | [next] | [standalone]
| From | Linux-Fan <Ma_Sys.ma@web.de> |
|---|---|
| Date | 2024-02-11 11:30 +0100 |
| Subject | Fast Random Data Generation (Was: Re: Unidentified subject!) |
| Message-ID | <I6ffX-9pry-7@gated-at.bofh.it> |
| In reply to | #267276 |
[Multipart message — attachments visible in raw view] — view raw
David Christensen writes: > On 2/11/24 00:11, Thomas Schmitt wrote: [...] > Increase block size: > > 2024-02-11 01:18:51 dpchrist@laalaa ~ > $ dd if=/dev/urandom of=/dev/null bs=1M count=1K > 1024+0 records in > 1024+0 records out > 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.62874 s, 296 MB/s Here (Intel Xeon W-2295) | $ dd if=/dev/urandom of=/dev/null bs=1M count=1K | 1024+0 records in | 1024+0 records out | 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.15018 s, 499 MB/s > Concurrency: > > threads throughput > 1 296 MB/s > 2 285+286=571 MB/s > 3 271+264+266=801 MB/s > 4 249+250+241+262=1,002 MB/s > 5 225+214+210+224+225=1,098 MB/s > 6 223+199+199+204+213+205=1,243 MB/s > 7 191+209+210+204+213+201+197=1,425 MB/s > 8 205+198+180+195+205+184+184+189=1,540 MB/s I wrote a program to automatically generate random bytes in multiple threads: https://masysma.net/32/big4.xhtml Before knowing about `fio` this way my way to benchmark SSDs :) Example: | $ big4 -b /dev/null 100 GiB | Ma_Sys.ma Big 4.0.2, Copyright (c) 2014, 2019, 2020 Ma_Sys.ma. | For further info send an e-mail to Ma_Sys.ma@web.de. | | 0.00% +0 MiB 0 MiB/s 0/102400 MiB | 3.48% +3562 MiB 3255 MiB/s 3562/102400 MiB | 11.06% +7764 MiB 5407 MiB/s 11329/102400 MiB | 19.31% +8436 MiB 6387 MiB/s 19768/102400 MiB | 27.71% +8605 MiB 6928 MiB/s 28378/102400 MiB | 35.16% +7616 MiB 7062 MiB/s 35999/102400 MiB | 42.58% +7595 MiB 7150 MiB/s 43598/102400 MiB | 50.12% +7720 MiB 7230 MiB/s 51321/102400 MiB | 58.57% +8648 MiB 7405 MiB/s 59975/102400 MiB | 66.96% +8588 MiB 7535 MiB/s 68569/102400 MiB | 75.11% +8343 MiB 7615 MiB/s 76916/102400 MiB | 83.38% +8463 MiB 7691 MiB/s 85383/102400 MiB | 91.74% +8551 MiB 7762 MiB/s 93937/102400 MiB | 99.97% +8426 MiB 7813 MiB/s 102368/102400 MiB | | Wrote 102400 MiB in 13 s @ 7812.023 MiB/s [...] Secure Random can be obtained from OpenSSL: | $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 * 1024)); done | | real 0m49.288s | user 0m44.710s | sys 0m4.579s Effectively 2078 MiB/s (quite OK for single-threaded operation). It is not designed to generate large amounts of random data as the size is limited by integer range... HTH Linux-Fan öö
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2024-02-11 12:30 +0100 |
| Subject | Re: Fast Random Data Generation |
| Message-ID | <I6gc1-9pZS-11@gated-at.bofh.it> |
| In reply to | #267279 |
Hi, Linux-Fan wrote: > I wrote a program to automatically generate random bytes in multiple > threads: > https://masysma.net/32/big4.xhtml > ... > || Wrote 102400 MiB in 13 s @ 7812.023 MiB/s That's impressive. > Secure Random can be obtained from OpenSSL: > > | $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 * 1024)); done > | > | real 0m49.288s > | user 0m44.710s > | sys 0m4.579s > Effectively 2078 MiB/s (quite OK for single-threaded operation). Probably the best choice for sceptics who critizise a reproducible random stream or mistrust random people's aptness to produce random. (If the number of desired loops gets larger, then one could do arithmetik in a "while" loop instead of "for" and "seq".) Have a nice day :) Thomas
[toc] | [prev] | [next] | [standalone]
| From | Gremlin <scott-andrews@columbus.rr.com> |
|---|---|
| Date | 2024-02-11 13:20 +0100 |
| Subject | Re: Fast Random Data Generation (Was: Re: Unidentified subject!) |
| Message-ID | <I6gYp-9qvd-7@gated-at.bofh.it> |
| In reply to | #267279 |
On 2/11/24 05:26, Linux-Fan wrote: > David Christensen writes: > >> On 2/11/24 00:11, Thomas Schmitt wrote: > > [...] > >> Increase block size: >> >> 2024-02-11 01:18:51 dpchrist@laalaa ~ >> $ dd if=/dev/urandom of=/dev/null bs=1M count=1K >> 1024+0 records in >> 1024+0 records out >> 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.62874 s, 296 MB/s > > Here (Intel Xeon W-2295) > > | $ dd if=/dev/urandom of=/dev/null bs=1M count=1K > | 1024+0 records in > | 1024+0 records out > | 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.15018 s, 499 MB/s > Raspberry pi 5: dd if=/dev/urandom of=/dev/null bs=1M count=1K 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.0122 s, 356 MB/s Now lets do it right and use random.............. dd if=/dev/random of=/dev/null bs=1M count=1K 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.9859 s, 360 MB/s > Secure Random can be obtained from OpenSSL: > > | $ time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * > 1024 * 1024)); done > | > | real 0m49.288s > | user 0m44.710s > | sys 0m4.579s time for i in `seq 1 100`; do openssl rand -out /dev/null $((1024 * 1024 * 1024)); done real 1m30.884s user 1m24.528s sys 0m6.116s
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | linux.debian.user
csiph-web