:: Re: [DNG] Insane defaults on Raspbe…
Forside
Slet denne besked
Besvar denne besked
Skribent: Steve Litt
Dato:  
Til: dng
Emne: Re: [DNG] Insane defaults on Raspberry Pi images - How to fix corruption/dataloss
On Tue, 12 Nov 2019 10:31:27 +0100
Edward Bartolo via Dng <dng@???> wrote:

> Hi all,
>
> The Raspberry Pi is very frequency used with an SD Card which is
> highly intolerant of frequent writes as these are limited. My first SD
> Card became read only after about six weeks with Devuan running. Using
> Raspbian, this issue did not repeat itself.
>
> Needless to state, although it seems, it is actually needed for some
> people, the Raspberry Pi is not a full blown server, although it can
> be used by the hobbyist adolescent who wants to experiment and learn.


Regarding eliminating the journal, you bring up a good point. But so
did some other people arguing the opposite. I suggest an installation
that gives the following choices:

* Don't use a journal
* Use a journal but keep it on an always-connected spinning rust drive
* Use a journal on the SSD or SD card

My suggestion is that the installer be clear about the tradeoffs when
SSD or SD card are involved, and also ask you whether you want to
fstrim manually or by cron. From what I understand, putting fstrim in
/etc/fstab is always a bad idea. Also, the installer could remind the
user to delete or archive to spinning rust files not needed, to
preserve free space on the SSD or SD card.

I'm thinking of using an Rpi as a poor man's laptop, because I've had
too many laptops go bad from spilled drinks and other keyboard
destroying mistakes. So I'd have an attached 2.5 inch USB spinning
rust. So I could bind mount (I love bind mounts) part of my spinning
rust to /var very early in the boot.

But then I might use another Rpi as an experimental thing, and perhaps
shut off journaling to save the memory card. Or perhaps install a big
honking memory card, log rotate ruthlessly, and fstrim every day.

Anyway, Edward's got a point, those with the opposite viewpoint have a
point, so maybe the right thing is to empower the (perhaps not too
knowledgeable) user to do the most advantageous thing on install.

SteveT

Steve Litt
November 2019 featured book: Manager's Guide to Technical
Troubleshooting Second edition
http://www.troubleshooters.com/mgr