> Linux(*) defaults to EXT2FS, async(metadata)/async(data). This means
> that fsck cannot be certain of what operation was being performed when
> the system went down, and often has to stop and ask for the user to RUN
> FSCK MANUALLY, so the user can try to guess what was in progress when
> the system went down. Async metadata writes also mean that the structure
> of the filesystem can be highly unstable at times, leading to the loss
> of entire directories... including '/'.

that's exactly truth. i often got RUN FSCK MANUALLY after power outage,
while never with NetBSD.

other problem is that async metadata/data without any forcing of
write sequence can easy render to crosslinked files or other things that
just means problems.

> (among others), so this problem may be disappearing now (after living
> with it for some 12+ years)

ReiserFS is even worse than ext2/ext3. little hardware problem, one bad
write can render whole FS completely unusable. reiserfsck just doesn't
work at all, and reading from broken filesystem gives kernel panic quickly


>
> (**) Hardware failures, or changes in filesystem code in -current could
> produce this problem on NetBSD, but that's the outside scope of
> 'reliability by design when running an official release'.
>
> This difference in filesystem approaches is one reason people have
> criticised your 'speed' comparison. At the least, to compare NetBSD to
> Linux EXT2FS, you need to mount the NetBSD FFS async/async, so both
> systems are running 'fast and loose'. Otherwise, you're comparing
> running to being shot out of a cannon. Travel by cannon may be faster,
> but... Ouch, the landing!


anyway - even comparing NetBSD softdeps with linux async generally makes
NetBSD the winner...

> Laptops are fickle hardware. I've seen the opposite of your story -
> Linux on a laptop which wouldn't run sound, ethernet, or wireless, and
> NetBSD on the same laptop worked from the install, with no fiddling.
>
> Since each laptop is so different, you can't extrapolate much about an
> OS from its behaviour on a single model.

this is discussion about hardware support for some kind of
devices/machines. not about system design and performance.

>
> > I always thought it's better to have _safe_ settings turned on and leave
> > potentially dangerous tweaks to user.
>
> To review:
>
> Linux: Slow IDE, unsafe FS. Each must be tweaked by the sysadmin.
> NetBSD: Fast IDE, safe FS. No tweaking needed.
>
exactly