I mean I need to log data but i didn't thought of the fsck+mount a separate partition in script. I'll have to check it.
Le lun. 24 oct. 2022 à 21:35, Jean-François SIMON <jfsimon1...@gmail.com> a écrit : > Hi, > > Thanks i believe this is very valuable approach, i didn't think of it. > Indeed i can run tests on that way, obviously a r/o system is much > better way. > > I believe i should do testing that way to validate it. > > All right i'll be working on it as time allow, thx for this idea. > > Jean-François > > Le lun. 24 oct. 2022 à 21:03, Janne Johansson <icepic...@gmail.com> a > écrit : > >> Den mån 24 okt. 2022 kl 17:37 skrev Jean-François SIMON < >> jfsimon1...@gmail.com>: >> > I have an inquiry regarding robust filesystem in a sense that it mostly >> > always mount >> > after unclean power off shutdown. >> >> Any fs that is mounted readonly would be safe for nasty shutdowns, so >> one idea would be to try to make many partitions, so that for instance >> /var/log can be a ramdisk (mfs) and the rest are kept separate and >> readonly if possible. Don't think readonly / works, but if it does, >> that would be very helpful for quick boots on next power-up. >> >> Another thing could be to have separate partition for needed writes (a >> DB for instance) which doesn't automount from fstab, but rather put >> the fsck+mount in rc.local, so that you still have a working system >> with network and sshd running even if this one fails or stalls on a >> Y/n-prompt. >> >> > Thanks for any insight into this, i don't recall OpenBSD supports any >> > journaling FS >> > which i believe is how we can mostly provide a quick boot while >> preventing >> > most corruption. I may be partly mistaken. >> >> In my experience, journals are good for saying "there was no writes in >> progress, if quick check of fs says it is fine, it probably was", >> which helps some for quick boots, but in your case I guess the larger >> problem is "what will go to magnetic media if writes are ongoing when >> power is waning". >> >> I don't know what kind of weird errors one can get, but its easy to >> imagine getting half-written sectors or such if power loss is at worst >> possible time, where you would not see that in most normal situations, >> even with kernel crashes. This will need a fsck to find which will >> take time, no matter what. >> >> -- >> May the most significant bit of your life be positive. >> >