SATA or SCSI drives - Multiple Read/write speeds.

Mark Hahn hahn at physics.mcmaster.ca
Tue Dec 9 11:58:32 EST 2003


> > | My concern is regarding multiple disk read/writes.  With IDE, you can 
> > | wait for what seems like hours while data is being read off of the HD. 
> > 
> > nah.  it's basically just a design mistake to put two active PATA disks 
> > on the same channel.  it's fine if one is usually idle (say, cdrom or 
> > perhaps a disk containing old archives).  most people just avoid putting 
> > two disks on a channel at all, since channels are almost free, and you 
> > get to ignore jumpers.
>
> So it would be a good idea to put data and /tmp on a different channel 
> than swap?

if you're expecting concurrency, then you shouldn't share a limited resource.
a single (master/slave) PATA channel is one such resource.  sharing a spindle
(two partitions on a single disk of any sort) is just as much a mistake.

> > caching.  this can cause data loss or corruption if you crash at exactly the 
> > right time (paranoids take note).
> > 
> I forgot about the "write-behind" problem.  I have been burned with 
> this before.

really?  the window is quite small, since lazy-writing IDEs *do* have a 
timeout for how long they'll delay a write.  or are you thinking of the 
issue of shutting down a machine - when the ATX poweroff happens before
the write is flushed?  (and the OS fails to properly flush the cache...)
the latter is fixed in current Linux.

> memeory while working.  I know on my present workstation I will work 
> with a file that is 2X the memory and I find that the machine stutters 
> (locks for a few seconds) every time there is any disk ascess.  I 

I'll bet you a beer that this is a memory-management problem rather than 
anything wrong with the disk.  Linux has always had a tendency to over-cache,
and get to a point where you clearly notice its scavenging scans.

> one thing I was looking at with SCSI.  From this I take it that SATA 
> can handle some queueing but it just isn't supported yet?

grep LKML for jgarzik and libata.  my real point is that queueing is not 
all that important, since the kernel has always done seek scheduling.

_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf



More information about the Beowulf mailing list