On Tue, 2004-10-12 at 12:31 -0700, Tom Jennings wrote:
On Tue, 12 Oct 2004, Jules Richardson wrote:
Where's IDE these days relative to SCSI?
Very, very good. Except for really demanding jobs, which mail
and ftp archive is not, SCSI is a waste of money.
mail can be extremely disk-intensive (depending on message volume)
surely?
SCSI
controllers
(RAID or otherwise) were always better than IDE - plus you get the
higher reliability, more flexible bus options etc.
Times change! Drives are far cheaper; >> reliability may still
exist in SCSI, but it's not been borne out in my experience.
yes the drives are cheaper; but I was asking about the performance more
than anything - I pretty much lost touch with IDE 5 years ago apart from
a handful of machines, so I don't know where it's at in terms of
performance under load (in a real scenario, forget marketing hype! :-)
Reliability's a tricky one. Historically I've had both IDE and SCSI
disks go bad in desktop environments (i.e. lots of power cycling and
less of a controlled dust-free environment), but I've only ever seen IDE
disks completely blow up in the servers I've known that happened to have
IDE disks rather than SCSI. Maybe that was just luck of the draw,
though.
If you've got a 100Mbit ether, it's unlikely
it will exceed
the disk or OS speed.
Not so convinced about that - remember that's bits, not bytes; ethernet
isn't *that* fast (relative to other things).
(I think you misread this -- without special preparation,
you'll never get > 25 - 50 Mbits/sec through it; that's 5
megabytes/sec peak.
My point was only that if you rsync to a disk on a different machine
over ethernet (as I thought you were suggesting, but I could well be
wrong!) then you do risk saturating the link at the time of the rsync,
which I'd assume *could* lead to mail message transfer problems.
Even a fair EIDE system on a modern machine will keep
100megabit
ether 100% soaked 100% of the time if you're just copying
data over a wire. But rarely is that how files are moved,
and certainly not over the open internet!
I probably did misunderstand your rsync comment then :-)
Unless you have a tightly-specified problem and
constraints,
it's best to solve problems when the occur.
Some problems, sure - but surely things like disk failure are an
anticipated problem that's guaranteed to occur at some point, and if you
*want* a server with near-perfect uptime then that needs planning for?
Again, it depends on the requirements, and in this case only Jay can
decide those...
cheers
Jules