GNU bug report logs -
#30174
shred bug - 1st byte written is wrong sometimes
Previous Next
Reported by: devzero <at> web.de
Date: Fri, 19 Jan 2018 18:23:02 UTC
Severity: normal
Tags: notabug
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
Full log
Message #13 received at control <at> debbugs.gnu.org (full text, mbox):
tag 30174 notabug
close 30174
stop
On 19/01/18 10:19, devzero <at> web.de wrote:
> Hi,
>
> i`m testing wear-levelling of an SLC USB Stick (cheap one i want to
> use them for long-term data-logging) and found shred to be a useful
> and fast utility to repeatedly overwrite a file's region (the
> datalogger i'm building will use rrdtool)
>
> As i already did some other testing before, shred made me believe
> my usb stick would already be "worn out", because i was seeing 1st
> byte flip occasionally when taking a look into the written data with
> xxd.
>
> I investigated and as you can see below, when repeatedly writing to
> the same file with shred, we can see with strace that shred is doing
> wrong.
>
> Looks like a bug to me.
>
> I tested this on recent CentOS7 (shred 8.22) and older Ubuntu based
> system with shred 8.25. I also compiled coreutils 8.29 and tested
> with the recent shred release - they all show this behaviour.
>
> regards
> Roland
>
>
> shred -n 10000000 -s 100 file &
>
> # cat file |xxd
> 0000000: 7fff ffff ffff ffff ffff ffff ffff ffff ................ <- (!)
This is intentional.
From the source:
/* The following patterns have the first bit per 512 byte block flipped */
8, 0x1000, 0x1249, 0x1492, 0x16DB, 0x1924, 0x1B6D, 0x1DB6, 0x1FFF,
14, 0x1111, 0x1222, 0x1333, 0x1444, 0x1555, 0x1666, 0x1777,
0x1888, 0x1999, 0x1AAA, 0x1BBB, 0x1CCC, 0x1DDD, 0x1EEE,
There was no mention why unfortunately.
cheers,
Pádraig
This bug report was last modified 7 years and 127 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.