On Thu, 07 Jun 2018 15:39:07 -0400, Dennis Lee Bieber wrote:

> On Sun, 3 Jun 2018 16:29:33 +0000 (UTC), Martin Gregorie
>  declaimed the following:
>
>
>>Some classes of card give poor performance, though that may well be
>>related to fragmentation. Don't forget that SD cards were designed for
>>large reads and writes (still images, videos...) and not for the type of
>>random access needed for good Linux filing system performance, and this
>>is probably exaggerated by the RPi's relatively small RAM, which reduces
>>its ability to cache data. But, if it doesn't work for you, fair enough.
>>
>  Classes 2/4/6 are based upon I/O on fragmented file systems as
would be
> found on still image cameras (small files with random deletions by the
> user). Class 10 is based upon streaming a single video file on a freshly
> formatted card. Though also take into account that the standard format
> for SD cards is FAT/exFAT -- not a journaling system.
>
>  As a result, a Class 10 card could have atrocious behavior when
working
> with multiple small files. If the file system is read-only, it may not
> be that noticeable, but if the file system is undergoing updates (log
> files, configuration files [current play list position?]) then a card
> that handles, say, 2 allocation units at a time will be doing a lot of
> closing/opening/copying/erasing of data from allocation unit to
> allocation unit -- whereas a card that can handle around 6 allocation
> units at once may not need to do rewrites, but can buffer changes to
> multiple files for later flushing.
>
>  I really should have bookmarked the article about this...
>
I, for one, would appreciate your posting a link to the article if you
can find it again. Relying on Wikipedia and the tattered remnants of my
memory doesn't cut it.


--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05