This bug has been fixed on Karmic, coreutils 7.4.
A lingering issue is to recode the logic to select the overwrite passes
(right now shred defaults to 3 passes, and all of them will be random).
Nevertheless, there is no visible performance impact anymore.
** Changed in: coreutils (Ubuntu)
Another recently committed patch upstream has taken out /dev/urandom as
the default random source for shred (the internal PRNG is back in).
shred is now at least 10 times faster.
I have opened (and marked fixed) an upstream task to signal a fix is
available on current trunk.
** Also affects: core
A recently committed patch to shred (coreutils trunk, 7.x) is reducing
the default number of passes from 25 to 3. A quick and informal test
shows a significant reduction in elapsed time. Nevertheless, all passes
are now random.
--
shred is very slow
https://bugs.launchpad.net/bugs/279598
You rece
Thanks for your time and for the links: "--random-source=/dev/zero" is
the stop-gap trick that I was searching.
--
shred is very slow
https://bugs.launchpad.net/bugs/279598
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
I am sorry. The day-to-day "earn money" piece took a toll on my
available time to keep on here. By an amazing coincidence this was
brought up at the upstream mailing list just a few days ago (see
http://lists.gnu.org/archive/html/bug-coreutils/2009-01/msg00123.html),
and it had a bit of movement to
** Changed in: coreutils (Ubuntu)
Status: Incomplete => Confirmed
--
shred is very slow
https://bugs.launchpad.net/bugs/279598
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.c
Have you finished researching?
I ask, at least, to remove the "incomplete" status: as of 8.10 (fully
updated) bug is still there, can be very easly verified by anyone and
have a nice and elegant explanation, so this is all but "incomplete".
--
shred is very slow
https://bugs.launchpad.net/bugs/2
I am unsure on the benefits of such a move: the idea behind writing the
file/disk with random data is to make an eventual recovery more
difficult. Fixing on a single value (albeit random) sort of defeats it
-- it will be just a bit more difficult to find the pattern, and
subtract it out of the sign
Thank you for reviewing my bug report.
A temporary stop-gap fix might be to pick a single value from /dev/urandom and
use it for every write of the random pass, instead of picking a different value
for every write.
Of course, every random pass must pick it's own value to strengthen the process.
Thank you for opening this bug and helping make Ubuntu better.
Indeed. From coreutils 5.x to 6.0 shred moved from an internal PRNG to
/dev/urandom (i.e., the system PRNG). It seems this move is most
probably the reason for the new high time. I am trying to get some times
from the execution of shre
10 matches
Mail list logo
