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 |

_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to