> > My personal approach to avoiding data loss is (a) avoid buggy things like > > inthell and linux. > > Interesting, being as we have another thread going as of late that seems > to link transparent data loss with AMD AM2-based systems with certain > models of Adaptec and possibly LSI Logic controller cards.
This is the SCSI with >= 4 GiB thread? Sounds like an address map problem. > I like Intel as much as I like AMD That is your right. Inthell has a long history of buggy products, attempting to hide/ignore bugs, poor customer support, outright theft, etc. AMD isn't perfect, but the list of bad things is far far shorter. And there are other companies to consider besides just inthell and AMD. > -- but it's important to remember that it's > becoming more and more difficult to provide "flawless" stability on > things as the complexities increase. Computers are complex devices and always have been. Yes this makes it difficult to get everything right. Yet it is possible to achieve very high levels of reliability, better than "5 9s". > And I have no idea what your beef is with Linux. The quality is crap. Endless problems, including scrambled data. > If the OP is > successfully able to bring his array on-line using Linux, I would think > that says something about the state of things in FreeBSD, would you > agree? Both OSes have their pros and cons. It says linux got something right that FreeBSD got wrong. I never said that BSD gets *everything* right, or that linux gets *everything* wrong. > > (b) FFS with softdeps and the disk write cache turned off, > > This has been fully discussed by developers, particularly Matt Dillon. > I can point you to a thread discussing why doing this is not only silly, > but a bad idea. And if you'd like, I can show you just how bad the > performance is on disks with WC disabled using UFS2 + softupdates. When > I say bad, I'm serious -- we're talking horrid. And yes, I have tried > it -- see PR 127717 for evidence that I *have* tried it. :-) I am WELL aware of how bad write performance is on disks with the write cache turned off. I get only about 10% of what the hardware can do, and with large files that is very noticeable. :-( But data integrity is important. > > (c) full backups. > > I'm curious what your logic is here too -- this one is debatable, so I'd > like to hear your view. Things go wrong, and when they do backups are useful. The obvious problem is that a backup quickly becomes out of date as data changes. RAID stays current, but doesn't help with accidental file deletions, in cases where the entire machine dies (fire. flood, etc.), and so on. A proper RAID (that actually helps reliability rather than hurting it) plus off site backups gets you pretty close. A RAID with an off site mirror plus off site backups would be about as reliable as you can get. But if the rate of data changes is high the communication charges could be prohibitive. It all comes down to how important your data is and how much money is available. > NCQ will not necessarily improve write performance. I doubt it will help if you have the disk's write cache turned on. I'm pretty sure it will help with write cache turned off. > I believe Andrey Elsukov is working on getting NCQ support working when > AHCI is in use (assuming I remember correctly). I look forward to having NCQ available. Write performance without it is really pathetic. _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
