Date: Mon, 30 Apr 2012 22:36:38 +0200 From: Polytropon <freebsd@edvax.de> To: Eitan Adler <lists@eitanadler.com> Cc: freebsd-questions@freebsd.org, Robert Bonomi <bonomi@mail.r-bonomi.com> Subject: Re: UFS Crash and directories now missing Message-ID: <20120430223638.794a274e.freebsd@edvax.de> In-Reply-To: <CAF6rxgksNAC2PguE6jzPtBauNZig9VWG--UmTt_fGVB7PytonA@mail.gmail.com> References: <201204301136.q3UBa8fj083478@mail.r-bonomi.com> <CAF6rxgksNAC2PguE6jzPtBauNZig9VWG--UmTt_fGVB7PytonA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Apr 2012 13:23:40 -0400, Eitan Adler wrote: > On 30 April 2012 07:36, Robert Bonomi <bonomi@mail.r-bonomi.com> wrote: > > A competennt, "not stupid", sysadmin would know these things. =A0And not > > 'remove all doubt' (in the words of Abraham Lincoln), by raising such > > nonsense questions. >=20 > A competent sysadmin would ask questions when they don't know the > answer bringing up possibilities they thought about. > A stupid sysadmin would yell at someone asking a question claiming > they should have known the answer. I know I don't add anything substantial by the following statement, but allow me to post it anyway in addition to your statement: There is no problem in mentioning thoughts, possibilities and options. It's also not a problem to admit a lack of knowledge in certain fields (e. g. how UFS, journaling, nullfs and fsck do "interact" with each other). Things start to be problematic when conclusions are made out of untrue assumptions or expectations. "It must be a system error, as I don't see a human error here." The problem is: "don't see" !=3D "doesn't exist", and of course !=3D "can't be proven". Such kinds of conclusion often lead into wrong directions. Of course it's hard to narrow down possibilities. A "test bed" with limited variables is neccessary to have. Also the proper tools and procedures of testing are important. That's the ONLY way to be sure - by eliminating one possibility after the other. What's being found in the end - and even if it's regarded unprobable from the beginning - must be the reason. Robert mentioned important things to consider. If you (unintendedly) destroy evidence for a forensic analysis of what happened (whatever it may be), you'll have a hard time finding out _what_ happened - except you can get it to happen again. In case of security breaches this is something you _don't_ want to risk IN PUBLIC just to be able to observe it. At this point, one could argue politeness vs. importance of arguments. From what I've seen on other lists, Robert's statements are "still polite" and full of things you can take as a start to what to additionally learn. You should concentrate on that essence. If you take the time to "do your homework", you'll be better prepared _if_ such thing should ever happen again. Finding out _what_ has happened is very hard (which I admit), and maybe it's even impossible. You would have needed a more verbose auditing facility to find out what program (user) caused a "mv-like syscall". Command logs can be altered, logged syscalls... yes, it's not impossible, but magnitudes _harder_ to remove trails. By the way, I can understand the frustration when something "impossible" happened and you never can _really_ say what it was, hoping it would not happen again. I've experienced such kinds of trouble myself. (That's why I'm on this list.) --=20 Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120430223638.794a274e.freebsd>