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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
