FreeBSD 7.1 crash

I recently migrated all three of my systems from Gentoo Linux to FreeBSD 7.1. I did so in part because of the vaunted reliability of FreeBSD, as well as the performance claims and the maturity of the system. Needless to say, I was more than a bit disappointed to leave my home office for a few minutes and upon returning, discovering that my primary machine (a Thinkpad X61, 2 Gb memory, 100 Gb 7200 rpm disk) had rebooted itself. No core dump, nothing in /var/log/messages that would provide a clue as to what happened. I am running the stock 7.1 kernel.

The one thing I was doing that was different from my activities of the last weeks since the conversion (during which the system has crashed three other times due to a bug in the ext2 filesystem support -- a bit hard to understand, given the maturity of the Linux implementation -- for which I have a patch that is uninstalled, since I'd need to build a kernel), was that I was doing a copy of a large number of files from my primary backup disk to the secondary disk. Both are SATA drives in USB shoeboxes and both filesystems are UFS (no journal, no soft updates). I was also disappointed to find that I had to fsck both of the backup filesystems on rebooting before I could mount them and there were a significant number of errors on the drive to which I was copying. I thought the synchronous updates of the filesystem metadata in UFS were supposed to avoid leaving a filesystem in an inconsistent state? That was certainly not the case here. Perhaps I've misunderstood what I've read about this filesystem.

Anyway, I'm asking for ideas for how to look for evidence as to what might have caused this crash. I've used Linux for *years* and would be hard-pressed to remember even a single complete system crash. If this is par for the course with FreeBSD, then clearly I've made a major mistake in using it, which can be undone. I'd much prefer to continue with this system, but I need to understand what's going on here, because four system crashes in two weeks was not what I bargained for when I made this move.

/Don Allen
 
how about powerfailure..... most of time my bsd box crashes because some minor powerfailures....

no power for few mili seconds and wuala....


As i understand gjournal, if you would have use it, you wouldn't have to fsck disks ;)
 
>I've used Linux for *years* and would be hard-pressed to remember even a single complete system crash.

I've seen some crashes among Linux and BSD systems mostly in context of some hardware failure.

>no journal, no soft updates

Why? Sounds "silly" to me.

http://www.mckusick.com/softdep/

>a bug in the ext2 filesystem support -- a bit hard to understand, given the maturity of the Linux implementation

FreeBSD != Linux and ext2 is of minor importance for FreeBSD.

>Anyway, I'm asking for ideas for how to look for evidence as to what might have caused this crash. I've used Linux for *years*

Okay so where is your dmesg etc. pp.? Every Gentoo forum would flame you to hell without the precious data.
 
ext2?
UFS (not UFS2)?
Is it 1999 or am I just imagining things? I'm guessing the ext2 drivers don't get much attention because nobody uses ext2 anymore.
Other than that, I concur with oliverh: if the system managed to crash and reboot without any log, it's either a hardware (or maybe power) failure or you're not looking hard enough.
 
To killasmurf86: power failure a good theory but I don't think it happened here. The machine is a laptop with a good battery (machine is fairly new), and it's on an APC UPS. As for your comment about gjournal, I think you are right, but you aren't addressing the issue I raised: I *thought* that UFS2 without the journal and without the soft updates was paying a performance penalty for synchronous updates of the metadata to avoid the need for fsck'ing after a crash. I believe journaling is a higher performance way of doing that (because the journal is written sequentially on the drive, and thus faster than writing the actual metadata, which is unlikely to be in sequential locations). And I think soft updates are a performance enhancement that eliminates the need for synchronous writes but retains most of the ability to keep the file system structure correct by carefully ordering the (deferred) writing of the metadata. But perhaps I've misinterpreted what I've read about UFS2.

To oliverh: no gjournal, no softupdates sounds "silly" to you? When you set up a bsd system, by default no gjournal, nosoftupdates is the way sysinstall/fdisk configures the *root* filesystem. As for dmesg, did you read what I wrote about /var/log/messages? There was NOTHING in the system logs regarding the crash.

As for ext2 being of minor importance to FreeBSD, if it's in the system, it needs to be right. If you don't think it's important, don't offer it. In the 7.1 release, it's there, but it's got a serious bug (I did get a patch, as I mentioned, from Jaakko Heinonen soon after reporting the error here, which was very good of him). And without it, how are people supposed to get their ext2/ext3 filesystems converted to UFS when migrating from Linux to FreeBSD (and to irkkaaja: when I said UFS, I was using the term generically, referring to the latest implementation which is UFS2) without working ext2 support?

My theory (and it's just a guess; without any evidence that's all any of us can do) about this crash is that there's a bug in the USB driver. When the system crashed, I had converted one of my USB backup drives from ext2 to UFS*2* and was copying it to another one, on which I'd just done a newfs. There are quite a few open USB driver bugs and I may have tripped over one of them.

/Don Allen
 
USB bug is very much possible.
I remember i had problems to copy lots of data from/to usb HDD/flash (over 4-8GB at time, not to mention 45GB), it just crashed on me.

btw, if i remember correctly 7.1 had new USB stack.....
i wonder what's new good/bad things about it
 
Back
Top