When I said card controller, I meant the card controller on/in the actual SD card. Not the piece of HW attached to your computer.
My conclusion at the time I was trying to understand the same behavior was that the in-card controller must be doing file transactions of some kind. Not behaving quite like basic block device. I recall even trying to actively corrupt the card's content, no success. Still, all worked fine when installing Linux on said cards. Hope it helps you avoiding wasting whole day or three on this, like I did. Tomas On Mar 7, 2018 9:23 AM, [email protected] wrote: > I do not believe that SD cards respond to pure raw block writes from dd. > Not unless the stream looks like files. > > I run into the same discovery some time ago. If I remember correctly, dd > didn't overwrite the content even with random data. It could behave > different for different firmware, but I tried a few with the same result. > > Tomas > > On Mar 7, 2018 9:13 AM, "wes" <[email protected]> wrote: > > that's only if you want to generate a certain size. otherwise it just keeps > going until it runs out of blocks to fill. > > -wes > > On Tue, Mar 6, 2018 at 5:08 PM, Tim Garton <[email protected]> wrote: > > > Don't you need a "count=#" option to dd as well? Not at a computer right > > now otherwise I'd be able to check if that's the case... > > > > On Mar 6, 2018 5:02 PM, "Richard England" <[email protected]> > wrote: > > > > > On 03/06/2018 04:20 PM, Tomas Kuchta wrote: > > > > > >> Try to delete the original files first. Then create empty file using > > >> /dev/zero and copy it to the card. I bet that it will be there on the > > card > > >> and some of your original data will disappear as result. > > >> > > >> My guess is that the card controller is deduplicating your /dev/zero > > >> blocks > > >> trying to protect the card from writes. > > >> > > >> Tomas > > >> > > >> On Mar 6, 2018 7:09 PM, "Russell Senior" <[email protected]> > > >> wrote: > > >> > > >> On Tue, Mar 6, 2018 at 3:04 AM, Russell Senior > > >>> <[email protected]> wrote: > > >>> > > >>>> On Tue, Mar 6, 2018 at 3:01 AM, Jim Karlock <[email protected]> > > >>>> wrote: > > >>>> > > >>>>> My initial attempt to google this was unsuccessful (most people > point > > >>>>>> out the write protect tab, not my problem). > > >>>>>> > > >>>>> > > >>>>> Bad switch on the write protect tab? (The tab operates a tiny > > switch.) > > >>>>> > > >>>> Nope. > > >>>> > > >>>> I can turn the switch to lock and it mounts the device read only > very > > >>>> clearly. The behavior I observe is that it happily writes /dev/zero > > >>>> over the block device, but then when I read again, the old data is > > >>>> still present. > > >>>> > > >>> For example, if I flip the tab to write protect tab to "Lock", I get > > >>> this: > > >>> > > >>> # dd if=/dev/zero of=/dev/sdc status=progress bs=1M > > >>> dd: failed to open '/dev/sdc': Read-only file system > > >>> _______________________________________________ > > >>> PLUG mailing list > > >>> [email protected] > > >>> http://lists.pdxlinux.org/mailman/listinfo/plug > > >>> > > >>> _______________________________________________ > > >> PLUG mailing list > > >> [email protected] > > >> http://lists.pdxlinux.org/mailman/listinfo/plug > > >> > > > > > > |Perhaps using dd if=/dev/urandom |of=/dev/sdc status=progress bs=1M > > > ...just a thought. > > > > > > _______________________________________________ > > > PLUG mailing list > > > [email protected] > > > http://lists.pdxlinux.org/mailman/listinfo/plug > > > > > _______________________________________________ > > PLUG mailing list > > [email protected] > > http://lists.pdxlinux.org/mailman/listinfo/plug > > > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > > > _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
