tag 30174 notabug close 30174 stop On 19/01/18 10:19, [email protected] 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
