<div dir="ltr"><div>Would periodically erasing SD cards and eMMC storage help to extend their useful life?  Or is this potentially dangerous for chips known to be used which implement these instructions incorrectly?<br><br></div><div></div>A few years ago, XO firmware would erase the SD card prior to running fs-update.  But if I recall correctly this was disabled because it caused certain SD cards to hang.<br><br>It might also be possible to enable the eMMC equivalent of TRIM in XO software builds provided XO eMMC's don't accidentally discard the wrong block.<br><br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 15, 2015 at 12:09 AM, James Cameron <span dir="ltr"><<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Jul 14, 2015 at 11:49:29PM -0400, Tim Moody wrote:<br>
> I think the bottom line is that on this xo1.5 I need to use a usb thumb<br>
> drive instead of this micro sdcard and its holder.<br>
><br>
> > -----Original Message-----<br>
> > From: <a href="mailto:xsce-devel@googlegroups.com">xsce-devel@googlegroups.com</a> [mailto:<a href="mailto:xsce-">xsce-</a><br>
> > <a href="mailto:devel@googlegroups.com">devel@googlegroups.com</a>] On Behalf Of James Cameron<br>
> > Sent: Tuesday, July 14, 2015 8:14 PM<br>
> > To: Tim Moody<br>
> > Cc: <a href="mailto:server-devel@lists.laptop.org">server-devel@lists.laptop.org</a>; <a href="mailto:devel@lists.laptop.org">devel@lists.laptop.org</a>; xsce-<br>
> > <a href="mailto:devel@googlegroups.com">devel@googlegroups.com</a><br>
> > Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5<br>
> ><br>
> > G'day Tim,<br>
> ><br>
> > Thanks, that's interesting.<br>
> ><br>
> > My best guess is you have a bad connector and the 24-hour thermal test you<br>
> > did fixed it.  The problem may return.<br>
> ><br>
> > Another guess is that the card has the production state awareness feature<br>
> > [1], part of e.MMC v5.0, which uses the storage cells differently before<br>
> they<br>
> > are enabled for normal use.  The state can be changed with suitable tools,<br>
> or<br>
> > will clear itself once enough data is written; followed by a power cycle.<br>
> The<br>
> > result is a sudden increase in performance after that power cycle.<br>
> ><br>
> interesting ideas.  I have no way of judging either.<br>
><br>
> My guess is that I tried so many different ways of partitioning it from<br>
> fdisk to parted that it was so messed up that an xo 1.5, a nuc, and a dell<br>
> all found it corrupt, compounded by the fact that systemd has it in use even<br>
> if it is not actually mounted.<br>
<br>
</div></div>Yes, it sounds like you lost track of the provenance.<br>
<br>
At heart though, an SD card is just a set of blocks, so I always make<br>
a copy of it before writing.  The copy usually compresses really well<br>
for permanent storage.<br>
<div><div class="h5"><br>
><br>
> The sdcard holder is also looking pretty suspect as used with the card slot<br>
> on the xo.  I put the micro sd in the holder back into the xo 1.5 and it<br>
> reported two devices with pttype of "dos", but gave unknown file system when<br>
> I tried to mount<br>
><br>
> -bash-4.2# mount<br>
> /dev/mmcblk1p1 on /bootpart type ext4 (rw,relatime,user_xattr,barrier=1)<br>
> /dev/mmcblk1p2 on / type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered)<br>
> devtmpfs on /dev type devtmpfs<br>
> (rw,nosuid,relatime,size=475460k,nr_inodes=118865,mode=755)<br>
> /dev/mmcblk1p2 on /home type ext4<br>
> (rw,relatime,user_xattr,barrier=1,data=ordered)<br>
> /dev/mmcblk1p2 on /versions type ext4<br>
> (rw,relatime,user_xattr,barrier=1,data=ordered)<br>
> /dev/mmcblk1p1 on /security type ext4 (rw,relatime,user_xattr,barrier=1)<br>
> proc on /proc type proc (rw,relatime)<br>
> sysfs on /sys type sysfs (rw,relatime)<br>
> tmpfs on /dev/shm type tmpfs (rw,relatime,size=51200k)<br>
> devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)<br>
> tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)<br>
> tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)<br>
> cgroup on /sys/fs/cgroup/systemd type cgroup<br>
> (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgro<br>
> ups-agent,name=systemd)<br>
> cgroup on /sys/fs/cgroup/cpu type cgroup<br>
> (rw,nosuid,nodev,noexec,relatime,cpu)<br>
> systemd-1 on /proc/sys/fs/binfmt_misc type autofs<br>
> (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)<br>
> hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)<br>
> debugfs on /sys/kernel/debug type debugfs (rw,relatime)<br>
> mqueue on /dev/mqueue type mqueue (rw,relatime)<br>
> vartmp on /var/tmp type tmpfs (rw,relatime,size=51200k)<br>
> /tmp on /tmp type tmpfs (rw,relatime,size=204800k)<br>
> none on /var/lib/stateless/writable type tmpfs<br>
> (rw,relatime,size=4096k,nr_inodes=2048)<br>
> none on /var/cache/man type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)<br>
> none on /var/lib/xkb type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)<br>
> none on /var/cache/httpd/ssl type tmpfs<br>
> (rw,relatime,size=4096k,nr_inodes=2048)<br>
> none on /var/cache/httpd/proxy type tmpfs<br>
> (rw,relatime,size=4096k,nr_inodes=2048)<br>
> none on /var/cache/php-pear type tmpfs<br>
> (rw,relatime,size=4096k,nr_inodes=2048)<br>
> none on /var/lib/dav type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)<br>
> none on /var/lib/dhclient type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)<br>
> none on /etc/adjtime type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)<br>
> none on /var/lib/logrotate.status type tmpfs<br>
> (rw,relatime,size=4096k,nr_inodes=2048)<br>
> none on /var/spool type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)<br>
> /dev/mmcblk1p1 on /etc/ssh type ext4 (rw,relatime,user_xattr,barrier=1)<br>
> /dev/mmcblk1p1 on /var/lib/dbus type ext4 (rw,relatime,user_xattr,barrier=1)<br>
> /dev/mmcblk1p1 on /var/lib/random-seed type ext4<br>
> (rw,relatime,user_xattr,barrier=1)<br>
> /dev/mmcblk1p1 on /etc/NetworkManager/system-connections type ext4<br>
> (rw,relatime,user_xattr,barrier=1)<br>
> /dev/sda2 on /library type ext4<br>
> (rw,noatime,user_xattr,barrier=1,data=ordered)<br>
> /dev/sda1 on /opt type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered)<br>
> (sda is a usb thumbdrive)<br>
><br>
> -bash-4.2# blkid<br>
> /dev/sda1: UUID="20d7ab6c-ec76-4fc3-a702-75c0051b5ce6" TYPE="ext4"<br>
> /dev/sda2: UUID="e1c0ef6a-dc89-4d46-bcef-7b19360d41f7" TYPE="ext4"<br>
> /dev/mmcblk0p1: UUID="de889f2b-fffb-4a45-8358-dce449f2cf7e" TYPE="ext4"<br>
> /dev/mmcblk0p2: UUID="0ad6a5ee-bc3d-4fc6-8b9b-ca9bc456cb74" TYPE="ext4"<br>
> /dev/mmcblk1p1: LABEL="Boot" UUID="ac3c6c0f-8350-47ab-a308-42d49652f030"<br>
> TYPE="ext2"<br>
> /dev/mmcblk1p2: LABEL="OLPCRoot" UUID="61a34c92-0f69-409d-9b61-23a5522d296d"<br>
> TYPE="ext4"<br>
> /dev/mmcblk0: PTTYPE="dos"<br>
> /dev/mmcblk1: PTTYPE="dos"<br>
><br>
> -bash-4.2# mkdir /mnt/sdcard<br>
> -bash-4.2# mount /dev/mmcblk0 /mnt/sdcard<br>
> mount: unknown filesystem type '(null)'<br>
<br>
</div></div>Expected.  You should have been trying /dev/mmcblk0p1 or p2.  Without<br>
p1 or p2 it is the overall device, usually not a partition.<br>
<span class=""><br>
><br>
> But when I put the micro sdcard into my usb adapter and plugged that into<br>
> the xo 1.5 I see<br>
><br>
> -bash-4.2# ll /dev/sde*<br>
> brw-rw---- 1 root disk 8, 64 Jul 15  2015 /dev/sde<br>
> brw-rw---- 1 root disk 8, 65 Jul 15  2015 /dev/sde1<br>
> brw-rw---- 1 root disk 8, 66 Jul 15  2015 /dev/sde2<br>
><br>
> and /dev/sde1 automounted on /media/usb0<br>
<br>
</span>Ok.<br>
<span class=""><br>
><br>
> I tried another holder from nexxtech and got the same result as the sandisk<br>
> one.<br>
><br>
> > Suggestions:<br>
> ><br>
> > - next time you want to erase a card, send it the erase command, which<br>
> >   takes between three and fifteen seconds in my tests [2],<br>
><br>
> you mentioned erase before, but I couldn't find it.  the googling I did only<br>
> mentioned using dd to erase.<br>
><br>
> [root@schoolserver zims]# which erase<br>
> /usr/bin/which: no erase in<br>
> (/usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/u<br>
> sr/bin:/root/bin)<br>
<br>
</span>The link supplied in [2] was for Open Firmware, and I've not studied<br>
how to do the same in Linux.  It would be really annoying to do it by<br>
accident.<br>
<span class=""><br>
> ><br>
> > - test the communications between the system and the card by measuring<br>
> >   the sequential read performance; this is usually the easiest way to<br>
> >   test communications,<br>
><br>
> not sure I had anything to read as I never had a file system.<br>
<br>
</span>The card is an array of blocks, so you can always read them;<br>
<br>
    su<br>
    sync<br>
    echo 1 > /proc/sys/vm/drop_caches<br>
    dd if=/dev/mmcblk0 of=/dev/null bs=1M count=256<br>
<br>
A data rate will be printed by dd.  That will give you a performance<br>
measurement that is never more than the actual performance, and<br>
occasionally less.<br>
<span class=""><br>
> > - try on a different XO-1.5, in case you have a faulty XO-1.5, and<br>
> >   raise doubts if the performance differs,<br>
><br>
> only have the one<br>
> ><br>
> > - try on a modern desktop system; that will isolate the problem to<br>
> >   interoperability with the XO-1.5,<br>
><br>
> even I thought of this.  in fact I saw differences between fedora 22 (my<br>
> NUC) and fedora 20 (my old Dell).  It was fedora 20 on which I did anything<br>
> useful including the zeroing.  I guess the subject line of my email is<br>
> misleading in this regard.<br>
> ><br>
> > - identify the kernel, in case you have a version that doesn't<br>
> >   properly switch to 1.8V; if so, the slot on the XO-1.5 will run it<br>
> >   at 3.3V, warm, and so the card firmware will intentionally slow the<br>
> >   transfers to ensure compliance with thermal specifications,<br>
> ><br>
> > - try reseating the card in the adapter, and the adapter in the<br>
> >   system, because a bad connection can show up as slow data rate, then<br>
> >   re-test the communications,<br>
><br>
> this is a possible factor in that I used a usb adapter for the micro sd more<br>
> successfully than the holder<br>
<br>
</span>Also by using USB adapter you are offloading some of the<br>
communications work to a processor in the adapter.<br>
<br>
The electrics of the adapter might also be a better match.<br>
<span class=""><br>
> ><br>
> > - if available, use uninit_bg when calling mke2fs, so that the<br>
> >   "formatting" doesn't have to write much,<br>
> ><br>
> > - publish the dmesg fragment showing the card being detected.<br>
> ><br>
> > When thinking about problems with SD card, it is best to imagine it as a<br>
> > separate computer, in which you can't change the software.  There's no<br>
> > telling what it will do.  ;-)  They are very complex systems, made to look<br>
> > simple.  Plug and play, dumbing down.<br>
><br>
> and apparently the home of a new class of virus, undetectable due to the<br>
> fact that the os is stored in write-only memory.<br>
<br>
</span>Yes, and also undetectable because it isn't in the data area of the card.<br>
<div class="HOEnZb"><div class="h5"><br>
> ><br>
> > +CC devel@ for general XO-1.5 and SD card interest.<br>
> ><br>
> > References:<br>
> ><br>
> > 1.<br>
> > <a href="https://www.jedec.org/news/pressreleases/jedec-announces-publication-" rel="noreferrer" target="_blank">https://www.jedec.org/news/pressreleases/jedec-announces-publication-</a><br>
> > emmc-standard-update-v50<br>
> ><br>
> > 2.<br>
> > <a href="http://wiki.laptop.org/go/Firmware/Storage#How_to_quickly_erase_everyt" rel="noreferrer" target="_blank">http://wiki.laptop.org/go/Firmware/Storage#How_to_quickly_erase_everyt</a><br>
> > hing<br>
> > (but use <a href="http://wiki.laptop.org/go/Firmware/Storage#devalias_fsdisk" rel="noreferrer" target="_blank">http://wiki.laptop.org/go/Firmware/Storage#devalias_fsdisk</a><br>
> > first)<br>
> ><br>
> > On Tue, Jul 14, 2015 at 06:34:52PM -0400, Tim Moody wrote:<br>
> > > I have been around the block with a 128G micro sdcard allegedly from<br>
> > > Sandisk.  I made various attempts at creating two partitions and<br>
> > > formatting them ext4, some of which progressed at the rate of<br>
> > > 10G/hour.<br>
> > ><br>
> > > I finally used dd to write /dev/zero to the entire device, which took<br>
> > > almost 24 hours.<br>
> > ><br>
> > > After that parted mklabel msdos and mkpart worked fine and mkfs.ext4<br>
> > > also worked fine in a couple of minutes.<br>
> > ><br>
> ><br>
> > --<br>
> > James Cameron<br>
> > <a href="http://quozl.linux.org.au/" rel="noreferrer" target="_blank">http://quozl.linux.org.au/</a><br>
<br>
--<br>
James Cameron<br>
<a href="http://quozl.linux.org.au/" rel="noreferrer" target="_blank">http://quozl.linux.org.au/</a><br>
</div></div></blockquote></div><br></div>