Hi Jan sorry for the late reply, Thanks for your comments and questions , Replies are in line
On Wed, 17 Jul 2024 at 13:12, Jan Stary <h...@stare.cz> wrote: > > On Jul 10 17:05:55, tom.sm...@wirelessconnect.eu wrote: > > Hi Jan > > thanks for your Reply and feedback, > > please find my replies in line , > > > > On Wed, 10 Jul 2024 at 16:28, Jan Stary <h...@stare.cz> wrote: > > > > > > On Jul 10 14:44:28, tom.sm...@wirelessconnect.eu wrote: > > > > we have been using mfs mounted /var /dev and /tmp for years > > > > > > Why? > > so any writes to disk would be simply written a memory filesystem and > > if there was a power cut > > How often do you get these power cuts? Not Often in Ireland but want to avoid truck rools, > > > there would be no changes happening to the > > disk because it is being just written to memory > > To be clear, you are concerned with changes to the filesystem > (not disk as such), which makes a dirty fs and invokes fsck > at reboot, right? one of the main reasons which I didnt articulate was repeated log writes of chatty daemons, OpenVPN with a very short timeout/ retry interval writing to disk and causing flash / ssd wear > > > > > however the impact of mfs (/var in particular) on upgrades has been > > > > quite painful, > > > > > > How? > > Losing new files in /var if the box is rebooted without first copying > > the /var (in memory) to where the persistent storage is (on shutdown) > > Whht do you mean by "new files"? Those coming to exist > during regular operation (as in /var/run), or "new" if > they get installed under /var on an upgrade? the New files that would be installed in /var on upgrade yes, > > The above (losing the nonpersistent mfs storage) is exactly > what would happen on a power outage; but what does that have > to do with upgrades? If you reboot (cleanly) after an upgrade, > the content of /var gets stored to persitent storage. Oh ok ... I had not seen that behaviour ...and sometimes /var/db the relinked kernel hash would throw the relink failure ... > > > > > #cat /etc/fstab > > > > ff0023511d131fc2.a / ffs rw,softdep,noatime 1 1 > > > > ff0023511d131fc2.b /usr/local ffs rw,wxallowed,nodev,softdep,noatime 1 2 > > > > ff0023511d131fc2.d /var ffs rw,nodev,nosuid,softdep,noatime 1 2 > > > > > > So you _don't_ have /var on mfs ... > > > Also, softdep no loger exists. > > Thanks it was an older option (now a noop (for backward compatibility > > ) just checked the manual there... Ill drop it off the deployment > > script > > > > > > swap /tmp mfs rw,nosuid,noexec,nodev,-s=262144,-P=/persist-fs/tmp 0 0 > > > > swap /var/log mfs > > > > rw,nosuid,noexec,nodev,-s=524288,-P=/persist-fs/var/log 0 0 > > > > swap /var/run mfs > > > > rw,nosuid,noexec,nodev,-s=262144,-P=/persist-fs/var/run 0 0 > > > > swap /dev mfs rw,nosuid,noexec,-P=/persist-fs/dev,-i=2048,-s=32768 0 0 > > > > > > Why do you need /tmp to persist? > > Fair point I was more interested in getting /tmp to be memory mounted > > (dont care about persistence) in that case > > checking manual > > > > > Why do you have a separate /dev? > > when programs write to /dev/blah is there a possibility of the > > filesystem being updated... > > Above you talk about an upgrade, here about an update. > What you mean is just a write to the filesystem? > > I never saw a / filesystem (holding /dev) > been screwed in a way that fsck couldn't get out of > because a file under /dev was being written ... I think I took this advice so that / could be mounted read only (if I Recall correctly ) so I was being cautious ... on this front ... > > > > Why don't you have a separate /home? > > it is a router /firewall / network appliance /not a standard desktop > > / server ... users are admins... etc . > > > > > > > ################################################### > > > > This seems to solve problems with upgrades and package updates, > > basically if the partition was not synced with a copy on shutdown you > > would lose the updated files ... > > Wll, you wouldn't have this problem > if you were not using mfs :-) indeed yes :) > > Filesystem inconsistency after a power outage is normal; > fsck will deal with it. You might lose some files - sometimes you lose the wrong file... and the system requires manual intervention / truck roll... I want to avoid that > with mfs, you lose everything. so I wanted to have a reliable boot and prefer losing logs and tmp files rather than risking corruption... > > Jan > Thanks for your feedback Jan really appreciate it
