No, it won't help.
1. reading data an SD card (or eMMC, or USB flash drives) does cause
writes internal to the card, and does reduce life,
2. there's no such flag to set in an MBR partition table,
Perhaps you mean a write protect switch on the card? This is a
plastic slide, sensed by a switch in the socket, and provides _advice_
to the system. Some systems don't receive the advice. The system can
ignore that advice. Even if acted upon, it only stops change to the
data, it doesn't stop writes internal to the firmware of the card.
On Sun, Aug 16, 2015 at 05:18:01PM -0700, Sameer Verma wrote:
> James,
> Would it help to mark the content partition(s) as read only?
>
> Sameer
>
> On Aug 16, 2015 5:13 PM, "James Cameron" <[1]qu...@laptop.org> wrote:
>
> Thanks, interesting questions.
>
> No, ext4 is not a slow journaled filesystem, and no, there are no
> obvious problems on SD when using ext4 given your use case. But it
> isn't operating system portable, and as your content is static no need
> for a journal. Other features of ext4 make mounting or filesystem
> check faster.
>
> Yes, wear-leveling is taken care of by the firmware in the card, put
> there by the manufacturers. Wear-levelling also critical during
> reading, since a flash page can't be read repeatedly without
> disturbance eventually requiring it to be written to a freshly erased
> page. This is all handled by the firmware. Happens way more
> frequently than it does on a hard drive.
>
> Duplication time of SD cards won't be affected by your filesystem or
> partition decision.
>
> One partition is sufficient. MBR partition type best, for
> compatibility across the operating systems.
>
> For filesystem, use FAT32, mounted read-only. FAT32 works across most
> Windows and Mac computers, at media sizes up to 2 TB, for file sizes
> up to 4 GB.
>
> Where content cannot live on FAT32 due to file name character set or
> metadata, it can be placed in disk image bundles of ISO-9660,
> squashfs, or ext4 and loop mounted. The content curation process for
> the end user might be easier if bundles can be added and removed as
> needed.
>
> What you might be overlooking; I/O bandwidth of the connection to the
> media, endurance impact of reading data from the card slowing
> performance one year on, backups, content bundle tamper checks, risk
> of filesystem format incompatibilities introduced by new versions of
> operating systems after your product is in the field, risk of cross
> system malware infections, electrostatic discharge damage to the card,
> and how modern cards can change performance behaviour as a result of a
> production state awareness flag stored by card firmware.
>
> On the other hand the alternatives have their own problems.
>
> --
> James Cameron
> [2]http://quozl.linux.org.au/
> _______________________________________________
> Server-devel mailing list
> [3]Server-devel@lists.laptop.org
> [4]http://lists.laptop.org/listinfo/server-devel
>
> References:
>
> [1] mailto:qu...@laptop.org
> [2] http://quozl.linux.org.au/
> [3] mailto:Server-devel@lists.laptop.org
> [4] http://lists.laptop.org/listinfo/server-devel
> _______________________________________________
> Devel mailing list
> de...@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
--
James Cameron
http://quozl.linux.org.au/
_______________________________________________
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
