Date: Wed, 15 Oct 2008 14:16:11 -0700 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Dieter <freebsd@sopwith.solgatos.com> Cc: freebsd-questions@FreeBSD.org, freebsd-hardware@FreeBSD.org Subject: Re: RAID 5 - serious problem Message-ID: <20081015211611.GA88511@icarus.home.lan> In-Reply-To: <200810152028.UAA24285@sopwith.solgatos.com> References: <20081015184558.GA84665@icarus.home.lan> <200810152028.UAA24285@sopwith.solgatos.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 15, 2008 at 01:28:43PM +0100, Dieter wrote: > > > 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. It's the "am2 MBs - 4g + SCSI wipes out root partition" thread. > > 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. I'd rather not debate this, as it's off-topic. We can take it up privately if you desire, but keep in mind that my ideal system would be an AMD processor on an Intel chipset board -- but I'll probably be dead by the time that ever happens. Both companies could have much to learn from one another. > > And I have no idea what your beef is with Linux. > > The quality is crap. Endless problems, including scrambled data. I'm not even going to touch this one. > > 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. I don't really consider it an issue of right or wrong; a very different, and unique viewpoint you have! (And I do mean that sincerely) > > > (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. Your 10% claim is about right. Here's some actual tests I just did (filesystem layer is in the way, but you get the idea): atapci0: <Intel ICH5 SATA150 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f irq 18 at device 31.2 on pci0 ata0: <ATA channel 0> on atapci0 ata0: [ITHREAD] ad0: 114473MB <Seagate ST3120026AS 3.05> at ata0-master SATA150 testbox# ./atacontrol cap ad0 | grep write write cache yes yes testbox# dd if=/dev/zero of=/usr/testfile bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 20.199726 secs (53156257 bytes/sec) testbox# ./atacontrol wc ad0 off testbox# ./atacontrol cap ad0 | grep write write cache yes no testbox# dd if=/dev/zero of=/usr/testfile bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 155.745314 secs (6894216 bytes/sec) That's about 13% of the full capability. No administrator in their right mind is going to disable WC unless the disks are behind some form of controller that does caching. (For NCQ stuff, see below.) As for the reading material: http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045495.html http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045542.html > > > (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. Ah sorry, I misinterpreted what you wrote! For some reason I thought you were advocating *not* performing full level-0 backups. :-) > > 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. One thing I haven't tested or experimented with is disabling write caching on a drive that has NCQ. Since FreeBSD lacks NCQ right now, we could test this on Linux to see what the I/O difference is (I'm talking purely from a dd or bonnie++ perspective). I can do said testing if need be (on Linux, with disks that do NCQ). > > 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. Hearing you on FM! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081015211611.GA88511>