Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.embedded > #526

Re: CF/SD flash filesystem

Show all headers | View raw

On 01/02/2011 20:25, dimaqq wrote:
> Yeah that's what I was afraid of.
>
> Flash will most certainly be sd or microsd.
> I'll try to get some "industrial" flash cards if budget allows.
>
> I'll make sure that partions are well aligned and of course I'm not
> going to use access times and will try to change metadata as little as
> possible. And I'm going to verify the format of db/files on every
> poweron, at least to some extent.
>
> For now my options for file system are:
> * ext4 without journal and with extent size = flash [logical] block
> size
> * exfat with cluster size = flash block size
> * logfs, although I'm not sure I can tweak that yet
> * raw if I really have to
>
> And for the database:
> * sqlite3, although it's disk page size is<=64K, might be too small
> * store data in files, overwrite or replace one file at a time
> * ad hoc cyclic data store (raw)
>
>
> Questions that remain unanswered:
> Did anyone try btrfs on flash cards?
> Logfs on flash cards?
> Can anyone share their flash card failure rate and conditions?
>

I don't know much about logfs or nilfs, but btrfs is a copy-on-write 
filesystem.  This has many advantages for reliability - if something 
goes wrong during writing, you typically have the old version of the 
file intact.  But it also means a lot more writing when you are updating 
a file - all, or at least large parts of the old file must be copied 
while making the change.  As far as I understand it, this makes it a 
poor performer with sqlite (and other databases, and also things like 
virtual machine disk images).  And with sd cards you don't actually get 
the reliability benefits, since the card itself can decide to re-arrange 
things for wear levelling and thus leave the disk in an inconsistent state.

Given the problems and limitations of sd cards, I think your best bet is 
a big battery and a simple file system - ext2 (or ext3/4 with 
journalling disabled - you want to avoid the extra writes) or perhaps 
fat32.  Fat32 has the advantage that it is easier to transfer files to 
non-Linux machines.  You would have to test the performance of sqlite on 
fat32 first, of course.  Reliability is not an issue - by definition, an 
SD card system is unreliable, and if you lose power within a second or 
so after starting a write, things can go badly wrong.

Back to comp.os.linux.embedded | Previous | Next | Find similar | Unroll thread

Thread

Re: CF/SD flash filesystem David Brown <david@westcontrol.removethisbit.com> - 2011-02-02 10:17 +0100

csiph-web