Am Montag, 19. Dezember 2011, 13:52:40 schrieb Henning Brauer: > gotta compromise for crippled systems. solvable with a little shell > script run from cron and rc.shutdown.
Wait: your solution would be to periodically remount some volume read/write, merge the changes and then drop back to ro ? You aren't serious, are you? > for the scenario i had in mind - servers in some data center - that is > the one solution. Agreed. Many posts ago, BTW, so why do you still bring it up? I specifically differentiated between devices that "store" and devices that "do". Data center servers which have baby sitters in an office nearby don't need automagic thingies. > I don't buy the "countless" at all, we're really only talking embedded > here, and for embedded style use cases you'll have to adopt. that is > the "special" case and not the norm. Embedded systems with configurable settings are a "special case"? Where were you during the last 10 years? > while i was mostly talking about a console and not fsck -y, i do > believe that an automagic fsck -y is pretty damn stupid. Guess what your home router does, and what (if you have one) your cell phone does? Also your car and your TV set? None of these drop you into a console after the 3rd power outage and people would laugh you out the door if you tried to sell such a product. > while we're really good in that and fsck almost always succeeds and > fixes things up i have seen different. And most likely the problems were not caused by fsck but by faulty hardware creating the mess to begin with. No serial console can fix faulty RAM chips, itchy power supplies or loose SATA cables, so it wouldn't help the proud owner of a "do" device one bit. As I have written before: I don't care whether the default install of OBSD comes with "fsck -p" or "fsck -y", but calling people who suggest "fsck -y" in certain situations cheapskates and stupid shows blatant ignorance.
