<div dir="ltr">Thanks You Arnd, we have many months work ahead of us and this will be a big help!<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 20, 2015 at 4:55 PM, Arnd Bergmann <span dir="ltr"><<a href="mailto:arnd@arndb.de" target="_blank">arnd@arndb.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Saturday 15 August 2015 21:05:48 Adam Holt wrote:<br>
> What filesystem would people recommend for ~128GB SD cards inserted into XO<br>
> laptops or XSCE servers heading far afield, to insert very large<br>
> (evolving?) digital libraries just like Internet-in-a-Box?<br>
><br>
> Multiyear reliability for all this content would be important, but some say<br>
> ext4 (slow journaled filesystems?) have their own problems on SD?<br>
<br>
</span>ext4 is better than most file systems in this regard (much better than ext3,<br>
also better than btrfs).<br>
<span class=""><br>
> Is wear-leveling of modern SD cards (Flash memory) fully taken care of by<br>
> the largest manufacturers/drivers already, or should we seek out particular<br>
> filesystems/drivers?  And unmount / power off carefully etc?<br>
<br>
</span>Some cards handle it better than others. Traditionally, Kingston cards<br>
were completely unusable after writing data on the order of the card size,<br>
while Samsung and Sandisk did much better (I have not checked in a few years<br>
though, so YMMV). Most other manufacturers have multiple sources for the<br>
embedded controllers on the cards, so it's a bit of hit and miss. The<br>
controllers have all evolved a lot in the past few years, the simple<br>
controllers that used to be on 8GB cards can no longer cope with the<br>
increased block sizes on today's cards (32GB and larger).<br>
<span class=""><br>
> In-country copying and eventually in-country remixing of SD cards<br>
> (containing local-language, local-vid cultural jewels) would be Absolutely<br>
> Wonderful -- if we can achieve that by using a filesystem that works<br>
> instantly (exFAT? NTFS?) across all Windows and Mac computers ideally?  For<br>
> all static content anyway, on 1 partition of several?  Accelerating dup'ing<br>
> of SD cards as a bonus?!<br>
><br>
> Many paths possible for sure, but most important: what<br>
> interop/longevity/other issues are we overlooking??<br>
<br>
</span>SDXC cards are mandated to be using exFAT (just like SDHC cards have<br>
to use VFAT, and indeed this is the only difference between the two)<br>
by the SD card standard. If you don't use this, you are strictly speaking<br>
in violation of the standard and the cards might not behave as designed.<br>
In particular, the card is allowed to only do efficient garbage collection<br>
for the access patterns that you get with a single exFAT partition that<br>
spans the entire card and has all its metadata aligned exactly in the<br>
way that the spec defines.<br>
In practice, things tend to work mostly ok with other file systems, but<br>
if you use NTFS or ext3 (rather than ext4), you are usually asking for<br>
trouble.<br>
<br>
The best longevity would be provided by f2fs, which is designed to work<br>
fine on most SD cards. The downside is that it only works on relatively<br>
modern Linux kernels (3.x or higher).<br>
<br>
I would expect that cards today use only dynamic wear leveling, not<br>
static wear leveling as real SSDs do. This means that content on a<br>
read-only partition will decay with the normal life of the card<br>
(several years, but depending on the quality of the card and the<br>
environmental conditions, e.g. not too hot), independent of the<br>
presence of partitions you write to.<br>
<br>
Dynamic wear leveling works best if you have a lot of unused blocks,<br>
so a good strategy for long life would be to leave a whole partition<br>
(e.g. 20% of the size of the writable partition, the more you have,<br>
the longer the card will survive) that never gets written after<br>
manufacturing, or at least gets erased using the fitrim ioctl<br>
command after the initial imaging.<br>
<br>
For a 128 GB card with 115GB of actual space, you could then use something<br>
like:<br>
<br>
* 80GB zisofs/cramfs/squashfs for static data<br>
* 30GB f2fs/ext4 for writable data<br>
* 5GB unused space for wear leveling<br>
<span class="HOEnZb"><font color="#888888"><br>
        Arnd</font></span></blockquote></div></div></div>