2 SD card slots and rootfs on internal SD card - maybe VFAT + fs images?
Carsten Haitzler (The Rasterman)
raster at openmoko.org
Sat Apr 12 10:52:45 CEST 2008
On Sat, 12 Apr 2008 08:46:51 +0100 Andy Green <andy at openmoko.com> babbled:
(move to kernel list)
> |> An added bonus of this approach is, rootfs gets full, you just buy
> |> a bigger SD card, copy the file across, use dd if=/dev/zero with
> |> some offsets to append some zeros to the end. The ext2resize to make
> |> the file bigger. This works really well and does mean out customers
> |> get a little bit of future proofing at the cost of another 10$ card.
> | that was the idea. i suspect the overhead of ext2 images ON vfat will
> not be a
> | performance issue (correct me though if i'm wrong. i just suspect),
> BUT the
> | only real issue here is writes to the fs img files going pear-shaped
> if you
> | power off during writes etc. stability (roh brought this up) may be an
> On DM2 now we use SD card boot for real, what I did was mount the ext2
> rootfs read only. Then we don't need to spare a thought about
> filesystem corruption in that whole area. It's a bit of a special case
> in terms that we control it closely for changes, but on a real system if
> we had a /usr part for example we can consider to mount this normally ro
> and -oremount,rw just during package install.
> | if we do 2 cards then we can always have the external card be a mount
> | on /media/card ad we do now and that is just where all your "data"
> files go
> | (photos, music etc.) by default.
> I think two cards is not needed, you just put your big card in the
> device when you buy a new card, copying over the handful of "system
> files" from the original card on a PC on easy VFAT.
> I suspect wanting a second removable card is just a crutch because we
> did a rubbish job making the one internal card a) big enough and b)
> easily accessible over network at high bandwidth. If it is true we need
> to attack the true issue.
RECAP as its going to kernel now:
| I don't really see the point in having an external slot if our OS is on
| the card there. That just raises the question why you can eject the OS
| so easily if you have to turn the device off anyway (and people will
| try it without turning the device off).
Yes single slot needs to be internal I think, and further, it needs to
be abnormal case that we ever remove or change it.
Carsten has interesting thoughts on what should be on these SD cards
that feed into this a bit. He noticed that VFAT is the only globally
mountable format, but VFAT is too simple for Linux rootfs. So he
proposes to run other filesystems as files on top of a VFAT substrate.
It means that you can copy a file on to an SD card that IS a whole ext2
rootfs, another that is the kernel, and the rest of the space is native
VFAT. If things go wrong or you want to do rootfs upgrade en bloc, you
pop the SD card into your PC and copy the new rootfs on as a file on
normal VFAT mount.
| To me the externally available slot means I can carry more SD cards
| with me to swap between different music/games/videos. I could make a
That's actually a true gain from a second slot, the only real one I
read. But even then we can solve it for many cases of this by the user
getting a BIG single SD card, eg, 8GB, 16GB; transcoded movies might be
400-700MB each, 10-30 movies at once starts to allow enough flexibility
for most cases.
So it is OK for one internal slot I think.
| picture with my digicam, put the SD card in my phone and send the
| picture off. All this sort of stuff.
I don't really buy that since your camera can easily have some
incompatible flash like Sony Memory Stick, XD, etc, then you can
transfer using a cheapo 5-in-1 USB adapter on the host port without
removing the SD. Also we can need a full or mini SD slot then if we
target that format and it is expensive in space. Lastly GTA04 will have
internal camera, reducing the probability the user carries another camera.
> | An added bonus of this approach is, rootfs gets full, you just buy
> | a bigger SD card, copy the file across, use dd if=/dev/zero with
> | some offsets to append some zeros to the end. The ext2resize to make
> | the file bigger. This works really well and does mean out customers
> | get a little bit of future proofing at the cost of another 10$ card.
> Right, even without this the underlying VFAT can also be mounted and the
> unused balance of that is available directly. For large media files or
> whatever the lack of permissions or symlinks is OK. So just sizing /usr
> or "rootfs" "file" suitable for a large set of packages would be OK.
> I think Carsten's approach was that the underlying VFAT mounts as /home
> making the usage natural.
actually i was thinking this:
[on vfat card]
rootfs.img would be rootfs - mounted.
kernel.img is the kernel that's booted
home.img is another ext2/3 image that is mounted on /home (it means symlinks
and everything that a lot of software likes to use even in ~/ - especially in
dot-files for config will work)
Data/ is mounted on /home/Data (encourage users to organise their data files
and / of the card is maybe mounted on /media/card so u have raw access to it if
the reason i am mumbling 2 cards is this:
1. internal card is safe - can't be removed without a system powerdown. we can
rely on it.
2. external card is removable any time - like any removable storage u have with
sd-card etc. readers on laptops/desktops/anywhere else. this is where your
"media" goes - music, photos, movies etc. etc. - stuff you like to transfer
around and plug in/out of multiple devices and that you may want many gb of
storage for. buy a few 8gb micro-sd cards and you can traipse around a lot of
music/videos etc. etc.
3. external card is ok if a user removes it any time during operation - it
won't screw up the core fs's we rely on (/home for user dir and config, and /
for base os).
4. an EASILY accessible external card is good for usability and users. it makes
industrial design less slick though as space for the slot has to be accounted
Carsten Haitzler (The Rasterman) <raster at openmoko.org>
More information about the openmoko-kernel