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

Status
Not open for further replies.

donallen

Active Member

Reaction score: 37
Messages: 170

[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!

Recent immense destruction that spilled my glass of patience:
Sys: FreeBSD 8-STABLE
At boot time: (it happens each 8th time approx. ), it hangs on ugenX.X line at usbusX, when it detects my Novatel Wireless mobile broadband 3g adapter OR ugenX.X line at usbusX, with some other device.
This hang NEVER happened on 7.X branch, so I suspect this has to do with 8.X's USB code rewrite.

Lastly, I've figured out, that I can avoid this hang, if I use hardware switch on my laptop, in order to physically turn of WLAN, bluetooth and 3G adapter.

So...
THIS caused, a massive loss, in /boot/kernel dir, of MANY *.ko AND *.ko.symbols files.
Also disappeared many /libexec/* files -> RESULT -> I can't run ALMOST any app installed from port!!!

Also disappeared many /bin/* files -> RESULT -> I can't rebuild world and kernel anymore! -> WHICH WAS PANACEA BEFORE!!

Now what?!

Now this situation NEVER happened on WinXP Pro SP3 - NEVER!
I can turn off power, reset, unplug the power cord and in WORST CASE I will ONLY loose data I've been working on ATM on WinXP!
I won't loose critical sys data/files that would render OS unbotable / unusable!

From my point of view, loss of data/files is HERESY!
And especially at this level/rate makes me dump ANY OS, at start immediately!
As any further usage attempts of that OS, forward on, is a complete waste of time, as in it's start/root, is faulty.
So anything you do, create is NULLED! x(

Now I simply wana comprehend this UNLOGIC sickness!
At boot time - data is being read and executed against critical sys files that are NEVER modified(read and execute are exactly perms of disappeared sys files). Nothing is being written to them!
So HOW CAN THEY BE ERRASED AT BOOT TIME FROM HDD!?!
Log files, are being written for examples. SO I would ubderstand if THEY are gone!

SOFT UPDATES - in case of a crash, files could be several seconds (even a minute!) behind updating the physical disk.

To me... the only logical explanation, is the most idiotic as well, for alpha and omega OS - THE FreeBSD. And is:
At boot time: critical sys files are pulled from HDD in memory, in a way that they are erased from HDD, before putting them in a memory, so if power outage happens, they don't exist in memory as well as on HDD anymore.

How else to explain such immense data loose?? :\

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
 
OP
D

donallen

Active Member

Reaction score: 37
Messages: 170

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

Administrator
Staff member
Administrator
Moderator
Developer

Reaction score: 3,277
Messages: 11,452

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

Administrator
Staff member
Administrator
Moderator

Reaction score: 1,294
Messages: 4,099

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

donallen

Active Member

Reaction score: 37
Messages: 170

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.

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.

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

Aspiring Daemon

Reaction score: 69
Messages: 841

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

Aspiring Daemon

Reaction score: 114
Messages: 783

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.
 
OP
D

donallen

Active Member

Reaction score: 37
Messages: 170

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

Administrator
Staff member
Administrator
Moderator

Reaction score: 13,914
Messages: 40,662

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.
 
OP
D

donallen

Active Member

Reaction score: 37
Messages: 170

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

Administrator
Staff member
Administrator
Moderator
Developer

Reaction score: 3,277
Messages: 11,452

[ closed ]

whatnow.jpg
 
Status
Not open for further replies.
Top