On Fri, Nov 08, 2019 at 04:13:58PM +0000, g4sra via Dng wrote:
> On 08/11/2019 15:36, Joril via Dng wrote:
> > On 08/11/19 16:21, g4sra via Dng wrote:
> >> FYI: ext4 filesystem journaling (and swap) *should* be disabled by default on SD\SDHC media.
> >
> > To reduce wear?
> There is good documentation 'out there' about how SD\SDHC Flash and Journaling works.
> The journal repeatedly written to a confined section of the filesystem.
>
> Not all SD's are equal, either in the quality of the memory cells or in the quality of the wear-leveling algorithm.
> NOTE: these in-built wear-leveling algorithms can be incompatible with flash filesystems.
> Personal experience has demonstrated once it is 'burned' the whole SD becomes read-only.

I've had an eMMC card that survived 4 years of a constant I/O-bound load
with more writes than reads, before starting to fail. On the other hand,
you can kill a SD card within a day.

> It should be the Users choice to enable journaling and risk SD destruction in preference to shutting down properly.
> I recommend filesystem check at boot should be enabled with journaling off and disabled with journaling on.
>
> PS: Being Raspberry Pi specific, I do not know why Raspbian does not use F2FS, but that does not exclude Devuan from using it.

Or btrfs. Both of these have a massive performance win over ext4 or XFS.
But btrfs is... well, btrfs: it has both features you can't live without
and WTF-level caveats, while f2fs is a regular filesystem without surprises.

Basically:
* ext4 and XFS are old-style filesystems with a journal attached. Both
metadata (inodes, extent lists) and the journal get rewritten in place
all the time.

* f2fs is a journal someone forgot to attach a filesystem to. It does all
writes in a whole-disk append-only log that matches the needs of
low-quality flash perfectly (and also works well on shingled HDDs).
The downside is that from time to time it has to take an erase block that
has a mix of live and deleted/obsoleted data, and rewrite the live pieces
at the head of the journal.

* btrfs likewise does everything CoW: every update instead of being done
in-place goes to an unused part of the disk, then pieces of metadata trees
that point to those new writes get also written to an unused part of the
disk, free space being garbage collected later. It avoids repeated
rewrites of f2fs, but those metadata tree updates tend to get really
nasty.

Btrfs can also win big with compression: new ARMs and lowest-end netbooks
have quite adequate CPUs but abysmally slow storage.

But in the general, f2fs is a safer choice to unleash onto an unsuspecting
user.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄⠀⠀⠀⠀ etc), let the drink age at least 3-6 months.