[XSCE] sdcard for /opt and /library on xo 1.5

Samuel Greenfeld samuel at greenfeld.org
Wed Jul 15 00:47:10 EDT 2015 

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?

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.

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.




On Wed, Jul 15, 2015 at 12:09 AM, James Cameron <quozl at laptop.org> wrote:

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

More information about the Devel mailing list