# constant MASSIVE data/files losses on HDD! [fall-out thread]



## donallen (Jan 20, 2010)

[font="Fixedsys"][ split off from http://forums.freebsd.org/showthread.php?t=10370 due to sidetracking - Mod ][/font]



			
				Seeker said:
			
		

> Now THAT DOES IT!
> I swear a god, that this thread will have a grand impact on my decision, will I dump FreeBSD, most possibly for eternity! x(
> 
> When NOT properly shutdown (ie: sudden power loss, sys hangs due to bug in code, so I need to turn of power or reset), destruction that happens to DATA on hdd is *out of normal comprehension!*
> ...



I posted a message earlier today describing my problems with FreeBSD 8.0. They were bad enough for me to stop using it, but not as bad as yours. I can understand your upset -- an OS that throws your files on the floor isn't worth much.

My personal suggestion would be to give OpenBSD a try. Theo de Raadt runs that project very conservatively, with very sound release-engineering principles. I've used it for almost a year and it is rock-solid. It is also easy to install and administer, because it's simple. No whizzy graphical installer, no fancy stuff re config files, daemon startup, etc. But the thing Just Works. My only reason for trying FreeBSD (again! I abandoned it once before because I found serious bugs that made it unusable for me. This will be the last time for me -- something about twice burned.) is that OpenBSD, a small project, has not yet come out with a production kernel without the giant lock. While it supports SMP hardware, the giant lock serializes access to the kernel. For some applications, this can reduce parallelism, compromising performance/scalability. I run OpenBSD on all my machines but one, the one where this might be an issue. I tried, and just abandoned, FreeBSD 8.0 on that machine. I've installed Arch Linux in its place. While Linux is not as carefully coordinated as OpenBSD and not as easy to administer, it has good SMP support and it does work.

/Don Allen


----------



## donallen (Jan 20, 2010)

Thinking about this some more, I'm really questioning the QA and release-engineering practices of the FreeBSD project. While it's not a lot of data points, I've had more trouble with FreeBSD in attempts to use 7.1, 7.2 and 8.0 in a desktop *and* server environment than I've ever had in years of using Linux (I first installed it on a Zeos laptop in the mid-1990s) and more recently, almost a year of OpenBSD usage on multiple machines -- desktops and laptops. As I said in another post, I think FreeBSD's USB re-write is buggy, its predecessor was unusable, and I've also encountered a serious bug in the ext2 support that would kill the whole system (that bug is now fixed).

People write bugs -- it's part of the human condition. But the measure of how good the QA and release-engineering practices are is how many of these bugs make it into production. It seems to me that the answer with FreeBSD is "far too many", when compared with Linux or especially OpenBSD.

FreeBSD has a reputation for stability as a server OS. Perhaps in that setting, it *is* stable. That's a much more controlled environment than the desktop environment, both from the standpoint of the range of hardware that must be correctly supported, and what the system will be asked to do. In my experience, in multiple attempts to use this system in the last year or more, it does not deserve such a reputation in the broader desktop world. I think the QA/release engineering people need to take a long look at what they are doing, because if the ambitions are to expand FreeBSD's reach beyond just servers, their current methods aren't working.


----------



## DutchDaemon (Jan 20, 2010)

I'm sorry, Don (and also Seeker, I guess). I haven't experienced any of the problems you ran into in about 16 years (FreeBSD 2.2.5) on hundreds and hundreds of installations (from laptops to high-end servers, from old castaways in the back of a closet to humming shiny stuff in datacenters on a different continent -- 95% of them ran the latest -STABLE, rarely older than 3 months at any given time), and the same goes for about a dozen admins I worked with over the years -- all of them are still running FreeBSD, for work, pleasure and leisure. 

I don't mind you spawning a theory about it, but to me it is just personal anecdotal evidence, nothing more substantial. I do not doubt FreeBSD's development model, QA and release engineering. I've had too many hours of uninterrupted care-free performance to doubt any of it. 

Too bad it didn't work out for you, but all of your negative experiences can be matched a hundred/thousand times over by the experiences of people like myself and a lot of users on this forum. There's always room for improvement (to toss in the old chestnut), and it is always happening with every new release. I'm sticking with FreeBSD and so is everyone I brought into contact with it (poor minions).

Speaking about theories: I do believe there's something like an 'admin - OS' mix that may or may not work. You and FreeBSD simply may not gel, whereas for me it is the perfect match and the perfect tool -- it just fits and it just works everyday, no matter what I throw at it. And if I overhear the Linux admins in the other room at work, I curse _way_ less and go home _way_ more relaxed. So do all of my FreeBSD-using colleagues. That's just _my_ reality. The fact that "FreeBSD is not for everyone" does not imply that "FreeBSD works for no-one". Cut your losses and move on, I'd say.


----------



## phoenix (Jan 20, 2010)

Sounds to me like there are several volunteers in this thread who would like to join the QA/testing team.


----------



## donallen (Jan 21, 2010)

DutchDaemon said:
			
		

> I'm sorry, Don (and also Seeker, I guess). I haven't experienced any of the problems you ran into in about 16 years (FreeBSD 2.2.5) on hundreds and hundreds of installations (from laptops to high-end servers, from old castaways in the back of a closet to humming shiny stuff in datacenters on a different continent -- 95% of them ran the latest -STABLE, rarely older than 3 months at any given time), and the same goes for about a dozen admins I worked with over the years -- all of them are still running FreeBSD, for work, pleasure and leisure.
> 
> I don't mind you spawning a theory about it, but to me it is just personal anecdotal evidence, nothing more substantial. I do not doubt FreeBSD's development model, QA and release engineering. I've had too many hours of uninterrupted care-free performance to doubt any of it.
> 
> ...



Of course you are right that what I am reporting is simply my personal experience with FreeBSD. I can't make any claims based on knowledge of the experience of the whole community -- I don't have that data. But we do have *some* of that data -- scan these forums, and you find a lot of chatter about problems with the new USB code. The old code was broken, yes? That's why it got re-written and never should have been released in the first place in the condition it was in, IMHO. Now we have a replacement, and it also has problems, serious problems that I and others have encountered. I am questioning the testing and release procedures that allow stuff like this to get released. I personally encountered a bug last year in the ext2 code (amd64-only) that would kill the system when writing to ext2 filesystems. How'd that get into production? Writing to ext2 with the amd64 build clearly did not get tested, because it didn't work. 

I simply don't encounter stuff like this with OpenBSD. Is it bug-free? I'm sure it isn't. But you can't find entire subsystems that don't perform their *basic* functions, as has been the case with the FreeBSD USB and ext2 code. That kind of stuff just never makes it to production -- their QA procedures catch such problems (I'm sure the fact that they are fanatical about using their own CURRENT themselves on their development machines is also a major contributor to the system's stability).

I am NOT writing what I have to tear down FreeBSD. Quite the contrary. The system clearly has major strengths; if I didn't think so, I'd just walk away and not bother with all this writing. But it appears to me (and I have a lot of relevant experience -- I just retired after a 45 year career in software development that included a lot of OS work, including Unix on multiprocessor machines, and management of large software projects, as well as individual coding that I do to this day) that the QA/release-engineering components need real attention, because -- my opinion -- they are repeatedly allowing gross bugs of the sort that you don't find in OpenBSD or good Linux distributions to find their way into production releases.

/Don Allen


----------



## richardpl (Jan 21, 2010)

ext2 code is not important for FreeBSD, if you care for it then please be, find or pay someone to maintain it.

And you are just trolling.


----------



## dennylin93 (Jan 21, 2010)

I think richardpl's right. Not many users using FreeBSD care about ext2fs anyway. However, some new improvements were committed recently: [HEADSUP] Google SoC work on ext2fs to be committed.

I haven't been using FreeBSD for a long time (just over 1 year), but it has become my favourite OS, and I haven't had any major problems with it yet. However, it might be because I've been using -RELEASE all the time, since -STABLE and -CURRENT seem a bit too adventurous to me.


----------



## donallen (Jan 21, 2010)

richardpl said:
			
		

> ext2 code is not important for FreeBSD, if you care for it then please be, find or pay someone to maintain it.
> 
> And you are just trolling.



Wrong on both counts. Good post.

FYI, though I don't know why I'm bothering, the ext2 bug was fixed about a year ago. My point, which you missed, was not that ext2 was buggy now. The point was that the bug I encountered last year never should have made it into a production release (7.1), in my opinion, because it was so easy to provoke with routine testing.

If the system is going to support ext2fs, then every effort should be made to insure the quality of the code by doing thorough testing prior to release. Your attempt to excuse buggy code that could scramble someone's ext2 filesystem (in my case, a backup disk) as "unimportant" is simply absurd.

You don't seem to be able to distinguish constructive criticism from trolling. Complex software systems don't improve if everyone sits around smiling and saying things are wonderful when they're not.


----------



## SirDice (Jan 21, 2010)

donallen said:
			
		

> Of course you are right that what I am reporting is simply my personal experience with FreeBSD. I can't make any claims based on knowledge of the experience of the whole community -- I don't have that data. But we do have *some* of that data -- scan these forums, and you find a lot of chatter about problems with the new USB code.


I do have a bit of a problem with this idea. If you are standing in line at a bakery you'll find a lot of people ordering bread. If you are at the butcher's a lot of people will order meat. If you are on a support forum you will find a lot of people posting problems.



> I am NOT writing what I have to tear down FreeBSD. Quite the contrary. The system clearly has major strengths; if I didn't think so, I'd just walk away and not bother with all this writing. But it appears to me (and I have a lot of relevant experience -- I just retired after a 45 year career in software development that included a lot of OS work, including Unix on multiprocessor machines, and management of large software projects, as well as individual coding that I do to this day) that the QA/release-engineering components need real attention, because -- my opinion -- they are repeatedly allowing gross bugs of the sort that you don't find in OpenBSD or good Linux distributions to find their way into production releases.


If you have that experience then you also know that it's simply impossible to test/verify every single combination of hardware currently in existence. You also should know that even though a certain chip/controller is supported vendorA might implement it differently compared to vendorB. Those differences may or may not impact compatibility with other hardware or the driver code. At some point in time you have to stop testing and release the code. Of course it would still contain flaws but most of them would probably never have surfaced during the test phase.


----------



## donallen (Jan 21, 2010)

SirDice said:
			
		

> I do have a bit of a problem with this idea. If you are standing in line at a bakery you'll find a lot of people ordering bread. If you are at the butcher's a lot of people will order meat. If you are on a support forum you will find a lot of people posting problems.
> 
> If you have that experience then you also know that it's simply impossible to test/verify every single combination of hardware currently in existence. You also should know that even though a certain chip/controller is supported vendorA might implement it differently compared to vendorB. Those differences may or may not impact compatibility with other hardware or the driver code. At some point in time you have to stop testing and release the code. Of course it would still contain flaws but most of them would probably never have surfaced during the test phase.



What you are ignoring in your comment about the difficulty of exhaustive testing is that *every* OS project has exactly the same problem. What I've been saying, and I repeat here for the last time, is that, in my experience, FreeBSD has more bugs of the sort that, in my opinion, should have been caught in the QA/release process. I've attempted to use this system three times now (7.1, 7.2, and 8.0), and have had to abandon it each time because of show-stopping bugs in the original and re-written USB code. And then, of course, there was the breakage of my system when I used freebsd-update to fetch the latest "improvements". I have *never* had such an experience in the course of extensive use of OpenBSD and various Linux distributions.

See you, guys. I'm done hitting my head against the wall. Enjoy your USB sticks, cameras, scanners, KVMs, etc.


----------



## DutchDaemon (Jan 21, 2010)

[ closed ]


----------

