SCSI vs SATA hard disks
Haines Brown
seem to suggest SCSI is dying out. If that the case, does my sticking
with SCSI any longer make sense?
Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
that I will henceforth have to accept drive unreliability? I'm more
interested in reliability than top speed (or, obviously, even cost).
If I were to attach a SATA drive to my desktop machine, I'd be inclined
to do a cross install of linux to the new SATA drive from my running
SCSI drive. Any reason such a procedure would be problematic because of
the interface difference?
--
Haines Brown, KB1GRM
Hactar
Haines Brown <bro...@teufel.hartford-hwp.com> wroteready worko), there
>
> Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
> that I will henceforth have to accept drive unreliability?
_All_ drives are unreliable to some degree. The ultimate in
computer-readable reliability is probably Tyvek punched tape.
> If I were to attach a SATA drive to my desktop machine, I'd be inclined
> to do a cross install of linux to the new SATA drive from my running
> SCSI drive. Any reason such a procedure would be problematic because of
> the interface difference?
Never had a SATA drive, but as long as your kernel has support _at boot
time_ for SATA and your controller (and fileystem but that already
work), there shouldn't be a problem. Make sure you copy the boot
blocks as well as the filesystem.
--
-eben QebWe...@vTerYizUonI.nOetP royalty.mine.nu:81
What do you do with dead chemists?
Barium. -- Harold_of_the_Rocks on Fark
Haines Brown
> In article <87hc89b...@teufel.hartford-hwp.com>,
> Haines Brown <bro...@teufel.hartford-hwp.com> wroteready worko), there
>>
>> Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
>> that I will henceforth have to accept drive unreliability?
>
> _All_ drives are unreliable to some degree. The ultimate in
> computer-readable reliability is probably Tyvek punched tape.
Yes, but my subjective impression is that there is a very wide
difference in reliability. Of the dozen SCSI drives I've used over the
years, only one failed on me; reading on line discussions and reviews,
it seems that SATA drives fail regularly.
I guess my question comes down to, why should one bother these days with
the added expense of SCSI hard disks?
>> If I were to attach a SATA drive to my desktop machine, I'd be inclined
>> to do a cross install of linux to the new SATA drive from my running
>> SCSI drive. Any reason such a procedure would be problematic because of
>> the interface difference?
>
> Never had a SATA drive, but as long as your kernel has support _at boot
> time_ for SATA and your controller (and fileystem but that already
> work), there shouldn't be a problem. Make sure you copy the boot
> blocks as well as the filesystem.
A chroot cross install is complicated, but I've gotten used to it, and
it ensures the kind of control I want and an installation that does not
interrupt using my current drive for work I assume that the kernels now
out all support SATA, and boot blocks are no problem as long as one sets
the file system up properly.
--
Haines Brown, KB1GRM
noi ance
> For many years I've been devoted to SCSI hard disks, but market trends
> seem to suggest SCSI is dying out. If that the case, does my sticking
> with SCSI any longer make sense?
>
IMO, for the cost of a 74GB SCSI drive, you could probably buy a 300GB
SATA, or a 300GB SCSI 2-300GB SATA for a RAID configuration. BTW, get
newer 5,400rpm SATA for quieter cooler operation.
> Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
> that I will henceforth have to accept drive unreliability? I'm more
> interested in reliability than top speed (or, obviously, even cost).
>
All drives are unreliable to some extent thats why they came up with
RAID. Make sure your SATA device supports RAID 1 or RAID 5.
> If I were to attach a SATA drive to my desktop machine, I'd be inclined
> to do a cross install of linux to the new SATA drive from my running
> SCSI drive. Any reason such a procedure would be problematic because of
> the interface difference?
Not sure how that's going to work.
If your PC recognizes both the SCSI and SATA; and can boot either that's
step one. Then if you're running LVM you can get a migraine by adding
the SATA drives as a new LVG and transfer data. Don't know about making
the SATA VG the boot over the SCSI VG.
If you're not running the LVM then the format, partition the SATAs, dd
the SCSI stuff to the SATA drives, modify the fstab and grub to point to
the SATA drives, change bios to boot the SATA drives first.
Hactar
Haines Brown <bro...@teufel.hartford-hwp.com> wrote:
> ebenZ...@verizon.net (Hactar) writes:
>
> > In article <87hc89b...@teufel.hartford-hwp.com>,
> > Haines Brown <bro...@teufel.hartford-hwp.com> wroteready worko), there
> >>
> >> Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
> >> that I will henceforth have to accept drive unreliability?
> >
> > _All_ drives are unreliable to some degree. The ultimate in
> > computer-readable reliability is probably Tyvek punched tape.
>
> Yes, but my subjective impression is that there is a very wide
> difference in reliability. Of the dozen SCSI drives I've used over the
> years, only one failed on me; reading on line discussions and reviews,
> it seems that SATA drives fail regularly.
>
> I guess my question comes down to, why should one bother these days with
> the added expense of SCSI hard disks?
It is my impression (which may be false and/or out of date) that the
instances of drive hardware that are matched with SCSI controllers are the
more reliable (longer-lasting) ones.
> >> If I were to attach a SATA drive to my desktop machine, I'd be inclined
> >> to do a cross install of linux to the new SATA drive from my running
> >> SCSI drive. Any reason such a procedure would be problematic because of
> >> the interface difference?
> >
> > Never had a SATA drive, but as long as your kernel has support _at boot
> > time_ for SATA and your controller (and fileystem but that already
> > work), there shouldn't be a problem. Make sure you copy the boot
> > blocks as well as the filesystem.
>
> A chroot cross install is complicated, but I've gotten used to it, and
> it ensures the kind of control I want and an installation that does not
> interrupt using my current drive for work I assume that the kernels now
> out all support SATA, and boot blocks are no problem as long as one sets
> the file system up properly.
I was thinking of taking your existing installation and copying it over
(that's what I've always done except PATA -> PATA), but whatever floats
your boat.
--
-eben QebWe...@vTerYizUonI.nOetP royalty.mine.nu:81
Hi! I'm a .sig virus! Copy me to your .sig!
Sheridan Hutchinson
> If I were to attach a SATA drive to my desktop machine, I'd be inclined
> to do a cross install of linux to the new SATA drive from my running
> SCSI drive. Any reason such a procedure would be problematic because of
> the interface difference?
If by cross-install you mean 'disk clone', then this very workable.
I heard on the grape-vine that some folks are preparing some machines in
VirtualBoxes and then later copying them across to the production
machines when they're happy with the core configuration.
If you're using an LVM you might have complications but it's worth a go
to see what happens.
Before you clone install a stock kernel, the ones in Debian at least are
stacked with multiple drivers to get your system up an running,
presumably other distros are the same or very similar in this regard.
G4l is one opensource option for disk cloning, or you could use gparted,
or you could use Acronis TrueImage (a closed source commercial option,
by it is reliable). All of these solutions can resize the new
partition(s) on to the new disk as you'd like them.
--
Regards,
Sheridan Hutchinson
Sher...@Shezza.org
Rikishi42
> For many years I've been devoted to SCSI hard disks, but market trends
> seem to suggest SCSI is dying out. If that the case, does my sticking
> with SCSI any longer make sense?
It hardly never did, sorry. SCSI is only the interface. There have been
drives that were sold with eighter SCSI or IDE interfaces, but were
otherwise identical.
> Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
> that I will henceforth have to accept drive unreliability? I'm more
> interested in reliability than top speed (or, obviously, even cost).
The notion that SCSI drives are inherently more reliable has been a very
irritating myth for well over 20 years now. Most observations of SCSI
reliability fail to include a more complete picture of the situation.
These are just examples I can come up with now:
1. Drive speed: SCSI's are usually slower drives. Less mechanical stress,
less heat stress. Older, more reliable technology.
Solution: buy a slow IDE/SATA.
2. Drive capacity: SCSI's are usually smaller. The bigger the disk, the
closer to the cutting edge, therefore the less reliable.
Solution: buy smaller disks.
3. Drive usage: SCSI's are mostly used in servers. Think constant operation.
Compare with the frequent on/off switching of personal desktops or laptops.
Guess where disks suffer most.
Solution: keep the machine running, including giving it a UPS.
To me, there is a _potential_ reason that SCSI's used to be more reliable.
HD production could have quality control. You could argue that a batch of
drives that turns out to be of higher quality, would be set aside to get
SCSI electronics. The clients buying SCSI are prepared to pay more, so those
drives could be sold with more profit. But where I would have believe such a
scenario even 10 years ago, I don't trust manufactors to put that much
effort in such checks/selections anymore.
> If I were to attach a SATA drive to my desktop machine, I'd be inclined
> to do a cross install of linux to the new SATA drive from my running
> SCSI drive. Any reason such a procedure would be problematic because of
> the interface difference?
No, why? If by installing, you mean setting up the OS from scratch. Which
includes selecting drivers. The detection process will select SATA rather
then SCSI modules. The source disk is not important, as long as it's
complete. Depends on your distro and how's it's installed, really. You
should provide a bit more details on your configuration.
--
Elevators smell different to midgets
Aragorn
wrote in /comp.os.linux.hardware:/
> For many years I've been devoted to SCSI hard disks, but market trends
> seem to suggest SCSI is dying out. If that the case, does my sticking
> with SCSI any longer make sense?
I'm not so sure that's a market trend. It just so happens to be that SCSI
is no longer considered useful in the home and office desktop market, but
servers are most definitely still using SCSI.
However, the SCSI that's being used and marketed today is no longer of the
parallel variant. Just as parallel ATA had to make way for serial ATA,
SCSI has by now already started making way for serial attached SCSI (SAS)
and iSCSI for storage area networks.
The big advantage of SAS is that SAS controllers can be used both with SAS
disks *and* SATA disks, intermixed - note: you cannot connect an SAS disk
to an SATA controller, though! - and the current bus speed for each
individual disk is 3.0 Gbit/sec, or 384 MB/sec. The new SAS standard will
be twice that fast.
> Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
> that I will henceforth have to accept drive unreliability? I'm more
> interested in reliability than top speed (or, obviously, even cost).
I'm not too familiar with brandnames and types, but I believe the Barracuda
is an enterprise-grade disk. Western Digital also have a number of
enterprise-class SATA disks out, and these are all intended for 24/7 usage.
Of course, SCSI and SAS have better error checking and correcting, which
SATA does not have - at least, not to my knowledge - and so if absolute
reliability is your priority, then SAS would be the best choice. SAS disks
also tend to perform slightly better than SATA because of TCQ versus NCQ.
But of course, the difference in price per unit of storage capacity between
SAS and SATA is huge, and ultimately it's your call. I myself actually
have a machine here with a SAS RAID 5, comprised of 4 SAS disks.
> If I were to attach a SATA drive to my desktop machine, I'd be inclined
> to do a cross install of linux to the new SATA drive from my running
> SCSI drive. Any reason such a procedure would be problematic because of
> the interface difference?
No, but you must of course keep in mind that the kernel on the target disk
has support for that disk's controller. So if you're using a custom-built
kernel and you've left out SATA support, you'll have to make sure that you
recompile the kernel and include SATA support before you copy the lot
over. ;-)
--
*Aragorn*
(registered GNU/Linux user #223157)
Matthew Wild
> On 2008-09-21, Haines Brown <bro...@teufel.hartford-hwp.com> wrote:
>
>> For many years I've been devoted to SCSI hard disks, but market trends
>> seem to suggest SCSI is dying out. If that the case, does my sticking
>> with SCSI any longer make sense?
>
> It hardly never did, sorry. SCSI is only the interface. There have been
> drives that were sold with eighter SCSI or IDE interfaces, but were
> otherwise identical.
>
>
>> Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
>> that I will henceforth have to accept drive unreliability? I'm more
>> interested in reliability than top speed (or, obviously, even cost).
>
> The notion that SCSI drives are inherently more reliable has been a very
> irritating myth for well over 20 years now. Most observations of SCSI
> reliability fail to include a more complete picture of the situation.
>
> These are just examples I can come up with now:
>
> 1. Drive speed: SCSI's are usually slower drives. Less mechanical stress,
> less heat stress. Older, more reliable technology.
> Solution: buy a slow IDE/SATA.
>
with over the last 10-12 years have been 10K or 15K. All the SATA/IDE
disks are 7.2K, or 5.4K for laptops.
> 2. Drive capacity: SCSI's are usually smaller. The bigger the disk, the
> closer to the cutting edge, therefore the less reliable.
> Solution: buy smaller disks.
>
> 3. Drive usage: SCSI's are mostly used in servers. Think constant operation.
> Compare with the frequent on/off switching of personal desktops or laptops.
> Guess where disks suffer most.
> Solution: keep the machine running, including giving it a UPS.
>
>
> To me, there is a _potential_ reason that SCSI's used to be more reliable.
> HD production could have quality control. You could argue that a batch of
> drives that turns out to be of higher quality, would be set aside to get
> SCSI electronics. The clients buying SCSI are prepared to pay more, so those
> drives could be sold with more profit. But where I would have believe such a
> scenario even 10 years ago, I don't trust manufactors to put that much
> effort in such checks/selections anymore.
>
I think they did more qualification of SCSI disks, because they are most
likely to be sold into an enterprise environment which wants better
guarantees. I'd agree that there aren't any real differences between
SCSI and SATA drives now, GB for GB.
Matthew
Pascal Hambourg
Aragorn a écrit :
>
> The big advantage of SAS is that SAS controllers can be used both with SAS
> disks *and* SATA disks, intermixed - note: you cannot connect an SAS disk
> to an SATA controller, though! - and the current bus speed for each
> individual disk is 3.0 Gbit/sec, or 384 MB/sec.
I don't know about SAS, but the SATA bus speed with 3 Gbit/s (i.e.
3*10^9, not 3*2^30) signalling rate is 300 MB/s, not 384. Each 8-bit
data byte is transmitted as a 10-bit pattern on the wire.
Douglas O'Neal
Particularly in light of some of the comments that have already been made,
you might find
http://www.usenix.org/publications/login/2006-06/openpdfs/chan.pdf
interesting reading. The author is a technical director at NetApp so the
bias might be more apparent than in other posts, but the comparisons between
drive types looks solid.
Doug
Chris Cox
> For many years I've been devoted to SCSI hard disks, but market trends
> seem to suggest SCSI is dying out. If that the case, does my sticking
> with SCSI any longer make sense?
SCSI has been replaced by SAS. So.... going forward, no, SCSI is
definitely a bad choice. However, SCSI drives and HBAs will be around
for some time. But the future belongs to SAS. Most all SAS
implementations now can also tunnel SATA, so you can usually
do both, but there can be a difference if using a hotswap
backplane.
Future right now = SAS and SATA
>
> Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
> that I will henceforth have to accept drive unreliability? I'm more
> interested in reliability than top speed (or, obviously, even cost).
Drive reliability is an issue regardless of type. However, consumer
based SATA drives do not have to pass as rigorous set of test as
SAS (and SCSI) drives do. The exception is the enterprise level
SATAs which are usually target for high end storage... also alot
of the Raptors are VERY similar to their SAS/SCSI cousins. But Seagate
is a very mixed bag right now with some of their drives produced
by the same fab as the Maxtor (very cheap) drives. So some Seagates,
especially on the OEM side will fail within a year (sad but true
from my own experience). I don't think it's wise to say which
vendor is "good" or "bad"... they are all one big roller coaster
of reliability. Right now, my WD drives are holding up well and
my enterprise side Hitachi's. Drives I hate include Maxtor and
Seagate.... buy YMMV.
>
> If I were to attach a SATA drive to my desktop machine, I'd be inclined
> to do a cross install of linux to the new SATA drive from my running
> SCSI drive. Any reason such a procedure would be problematic because of
> the interface difference?
Probably not. There are a few (very few) SATA controllers that cause
problems for Linux. Sometimes it's a BIOS issue where some will let
you change things to work with Linux and others won't. But it's only
on a small set of machines. I'd say I've seen the most problems with
HP's consumer line. The are pretty Linux unfriendly.... even their
business workstation/laptop line isn't particularly Linux friendly.
HP does a good job on the server side though.
If you have a working SATA, there shouldn't be a problem making
the copy... but because of drive ordering issues, you may have to
make some post copy adjustments to grub (in particular) and possibly
your initrd so that ordering is either changed, or things are adjust
to switch the drive ordering using a combination of grub and/or the
bios to match things up correctly (not quite sure that "cross install"
means in your context).
It's all pretty repairable, but certainly not an easy process
for a newbie to tackle. Too may variables to reliably document
with some kind of "silver bullet" formula.
Aragorn
wrote in /comp.os.linux.hardware:/
Well, I had read that it was 384 MB/sec for SAS and 300 MB/sec for SATA -
given that SCSI data and commands are both transmitted in 32 bit units from
U320 up - but either way, even 300 MB/sec by far exceeds the real
throughput capacity of a single hard disk, and with both SAS and SATA, the
available bus speed applies to each individual storage device, as opposed
to for the total of devices connected to the controller as in the case with
parallel SCSI or ATA. ;-)
Haines Brown
more specific, although this is a simplified description.
1. Do a cfdisk on the newly attached hard disk (SATA or SAS). For
example, # cfdisk /dev/sdc, to create my partitions.
2. Initialize these partitions: # mk2fs /dev/sdc.
3. I make my first partition at least 500 Mb so that I can do a base
installation in it using cdebootstrap. I mount this installation
partition on /mnt/debinst and run something like:
# /usr/bin/cdebootstrap -v --arch i386 lenny /mnt/debinst
http://http.us.debian.org/debian
4. To configure base system, I chroot to the installation partition:
# chroot /mnt/debinst /bin/bash
Create a primitive fstab on the target disk so that I can mount broken
out partitions for moving directories out of the install directory.
5. Chroot to do a dpkg-reconfigure, etc.
--
Haines Brown, KB1GRM
Haines Brown
expensive, and so probably will end up with SATA.
I run my machine 24/7, and normally only reboot every few months to do
something with hardware. That should reduce the stress on the drive and
help it survive for a while.
--
Haines Brown, KB1GRM
Rikishi42
> I run my machine 24/7, and normally only reboot every few months to do
> something with hardware. That should reduce the stress on the drive and
> help it survive for a while.
Don't forget to backup. No matter how reliable the drives, no matter what
level of raid, backups are usefull.
Aragorn
wrote in /comp.os.linux.hardware:/
> [...] I make my first partition at least 500 Mb so that I can do a base
> installation in it using cdebootstrap. [...]
If you're concerned with having your system securely and properly set up,
then I would recommend that you split off as much from the (target) root
filesystem as possible at the root directory level and use custom mount
options for those filesystems.
Ideally, you should keep your root filesystem small - only about 250 MB max
- and static. Make sure */usr* is on a different filesystem and that it is
mounted read-only during normal system operation, and with /nodev,noatime/.
Likewise for */opt.*
Make the contents of */tmp* reside on /tmpfs/ instead of on a physical disk
and mount it with /noexec,nosuid,nodev./ Use a separate filesystem for
*/home* - it needn't be big on a server, although you may want to make it
larger if you intend using the machine as a workstation instead. Mount it
with /nodev,noatime./ */var* should also be separate and should be mounted
with /nodev,noatime./ */boot* can also be mounted read-only during normal
system operation - some even prefer not having it mounted at all - and
with /nodev,noatime/ as mount options.
Lastly, if you intend to use */srv* as a central storage for shared user
data or e.g. for the contents of a webserver running on that machine, make
it a separate filesystem as well, with /nodev,nosuid,noatime/ as mount
options.
You can determine the proper sizes for each of those filesystems using your
old hard disk as a template - give them about 10% slack just in case.
Keeping them all separate assures a more secure set up and will protect
your individual filesystems from filesystem corruption caused by some bug,
and from filesystem fragmentation on static filesystems such as the root
filesystem, */usr* and */opt.*
Finally this... If you need more than 15 partitions on the same disk (or
RAID array) and/or you would like to have resizeable filesystems, you
should look into logical volume management.
Your mileage may vary, but that's how I would do it. Actually, I *do* lay
out my systems like that. ;-)
Pascal Hambourg
>
> but either way, even 300 MB/sec by far exceeds the real
> throughput capacity of a single hard disk, and with both SAS and SATA, the
> available bus speed applies to each individual storage device,
Well, to my dispair I read that SATA III allows multiple devices on a
single bus. Doh.
> as opposed
> to for the total of devices connected to the controller as in the case with
> parallel SCSI or ATA. ;-)
s/controller/channel or bus/
david
electrons to say:
> Aragorn a écrit :
>>
>> but either way, even 300 MB/sec by far exceeds the real throughput
>> capacity of a single hard disk, and with both SAS and SATA, the
>> available bus speed applies to each individual storage device,
>
> Well, to my dispair I read that SATA III allows multiple devices on a
> single bus. Doh.
There is no such thing as SATA III. There is SATA 6GB, and rev 3.0 of
the specification.
http://www.serialata.org/6gbnamingguidelines.asp
Where did you read that the next revision of the SATA spec will allow
multiple devices per bus? because that is not per the SATA specification,
which is a point to point connection.
See the official SATA web site:
http://www.sata-io.org/satatechnology.asp
Pascal Hambourg
> On Tue, 23 Sep 2008 11:00:59 +0200, Pascal Hambourg rearranged some
> electrons to say:
>>
>>single bus. Doh.
>
> There is no such thing as SATA III. There is SATA 6GB, and rev 3.0 of
> the specification.
Right, SATA III is a misnomer.
> Where did you read that the next revision of the SATA spec will allow
> multiple devices per bus? because that is not per the SATA specification,
> which is a point to point connection.
In the Wikipedia french article about Serial ATA.
<http://fr.wikipedia.org/wiki/Serial_ATA#Version_III_du_Serial_ATA>
I'll be glad if it is wrong. The english article only mentions port
expanders as a means to connect multiple devices to a single controller
port. This preserves the point to point nature of the SATA bus, but may
cause bus contention when multiple devices are simulaneously active.
Sheridan Hutchinson
> Finally this... If you need more than 15 partitions on the same disk
> (or RAID array) and/or you would like to have resizeable filesystems,
> you should look into logical volume management.
I'm always looking to learn something new, so I wonder if you could
share with me your experience of the benefits from having multiple
partitions, as opposed to having a single partition housing all the
mount points?
Then reason I ask is that I have a desktop and laptop with encrypted
LVM's that house / and a swap in separate logical volume, but within the
same logical group. The only other linux partitions is /boot which of
course needs to remain unencrypted.
I backup regularly using full disks clones for easy restoration, so I'm
never worried about losing data.
So just in theory, lets pretend I didn't have an encrypted LVM, what
would be the benefits be?
Haines Brown
> On Monday 22 September 2008 22:41, someone identifying as *Haines Brown*
> wrote in /comp.os.linux.hardware:/
>
>> [...] I make my first partition at least 500 Mb so that I can do a base
>> installation in it using cdebootstrap. [...]
>
> If you're concerned with having your system securely and properly set up,
> then I would recommend that you split off as much from the (target) root
> filesystem as possible at the root directory level and use custom mount
> options for those filesystems.
No, I actually have 12 partitions at present that are broken out (3 of
which are custom). The root was made large so that it can serve as a
temporary installation partition, from which directories will be moved
out once the base system is in place there. However, it makes more sense
to use the swap partition for this purpose because these days it is
plenty big. I run a workstation rather than a server.
You bring up some interesting points about partitioning policy. Although
OT, I wonder how to implement /tmp as a tmpfs rather than ext3
on the physical disk and why this it is a good idea to do it.
An issue that has always troubled me is the optimal sequence of
partitions. For example, /swap is supposed to be located in relation to
the physical disks on the hard disk, but I never knew how to do
that. Howver, I'm not sure it makes any difference any more.
--
Haines Brown, KB1GRM
Aragorn
wrote in /comp.os.linux.hardware:/
> Aragorn <ara...@chatfactory.invalid> writes:
>
>> On Monday 22 September 2008 22:41, someone identifying as *Haines Brown*
>> wrote in /comp.os.linux.hardware:/
>>
>>> [...] I make my first partition at least 500 Mb so that I can do a base
>>> installation in it using cdebootstrap. [...]
>>
>> If you're concerned with having your system securely and properly set up,
>> then I would recommend that you split off as much from the (target) root
>> filesystem as possible at the root directory level and use custom mount
>> options for those filesystems.
>
> No, I actually have 12 partitions at present that are broken out (3 of
> which are custom). The root was made large so that it can serve as a
> temporary installation partition, from which directories will be moved
> out once the base system is in place there. However, it makes more sense
> to use the swap partition for this purpose because these days it is
> plenty big. I run a workstation rather than a server.
Or alternatively, you can create a second root partition, which you leave
unmounted once the system is set up properly. That way, you have a rescue
root filesystem for in the event something goes wrong with your main root
filesystem.
> You bring up some interesting points about partitioning policy. Although
> OT, I wonder how to implement /tmp as a tmpfs rather than ext3
> on the physical disk and why this it is a good idea to do it.
Doing it is rather easy. Simply mount /tmpfs/ to it. Boot up in single
user mode, make sure */tmp* is empty and then and edit your */etc/fstab* to
include a line like this:
none /tmp tmpfs auto,nouser,nodev,noexec,nosuid,noatime 0 0
If so desired, you can also easily control the maximum allowed size of
*/tmp* in this manner by adding the /size=/ mount option - see the /man/
pages for details - so as to limit the available space for */tmp* without
having to set up quota or resize on-disk filesystems. The default maximum
size if no parameter is given will be half your available RAM.
The reason as to why one should make */tmp* a /tmpfs* is that according to
the FHS 2.3, nothing in */tmp* should be expected to survive a reboot.
It's normally only needed for sockets and such, and those things don't take
up much diskspace.
> An issue that has always troubled me is the optimal sequence of
> partitions. For example, /swap is supposed to be located in relation to
> the physical disks on the hard disk, but I never knew how to do
> that. Howver, I'm not sure it makes any difference any more.
Normally, manuals and installers will encourage you to create a swap
partition right behind the root filesystem - so as to make sure that you
don't forget creating one - but on systems with a lot of RAM, the location
on disk of the swap partition is not really relevant anymore.
It used to be relevant on older systems with less RAM because the closer the
swap partition is to the start of the hard disk, the faster it will be, due
to the fact that the outermost cylinders have more sectors on them than the
innermost ones, and thus more sectors can be read in one go without having
to switch heads or move the position of the heads over the platters.
I normally create */boot* as the first partition, followed by the root
filesystem itself. And as a third, I will then create either */usr* or the
swap partition. It has always proven to be a good set-up. :-)
Aragorn
Hutchinson* wrote in /comp.os.linux.hardware:/
> Aragorn wrote:
>
>> Finally this... If you need more than 15 partitions on the same disk
>> (or RAID array) and/or you would like to have resizeable filesystems,
>> you should look into logical volume management.
>
> I'm always looking to learn something new, so I wonder if you could
> share with me your experience of the benefits from having multiple
> partitions, as opposed to having a single partition housing all the
> mount points?
Well, as I mentioned in my previous post, there are many benefits...:
(1) You can keep your static trees static. No fragmentation caused by
mixing variable files with static files.
(2) You reduce the risk of total filesystem corruption. If something
does go wrong and you end up with filesystem corruption in a given
partition, then this need not necessarily be the case for the other
filesystems on your computer.
(3) In the event of reinstallation of the operating system, you can keep
your data separate, and the filesystems holding them - e.g. */home* -
need not be reformatted.
(4) Security. You can have your static filesystems mounted read-only
during normal system operation, and so not even a rogue root process
would be able to write to your system directories, because they'd
have to be remounted in read/write mode by the root user first. In
addition, this also plays nicely with (2) higher up, i.e. a filesystem
mounted read-only cannot get corrupted by - say - an unclean shutdown
due to an unexpected power failure.
(5) Related to (4), you can increase security by using separate mount
options for each filesystem, and you can even use different filesystem
types for individual needs, if you you choose to. For instance, on a
server that offers streaming audio or video, you will most likely use
an /xfs/ or /jfs/ filesystem for the data that is to be streamed. By
using different partitions, you can then also specify specific block
sizes while formatting the filesystems, depending on what you'll be
using them for.
The downside is that the above incorporates an additional level of
complexity that may seem daunting to the newbie - read: the Windows
habituate - because this kind of stuff is simply unheard of in Windows.
Therefore, desktop-oriented GNU/Linux distributions typically default to
using just a root filesystem and a swap partition, eventually with a
separate */home.* The advantage of this simplified approach is also that
the newbie need not concern himself/herself with partition sizes.
On the other hand, one can use a distributed filesystem hierarchy in which
partition sizes are variable, by creating a fixed partition for */boot*,
the root filesystem and the swap partition, and then creating an extra
partition in which individual filesystems are created in resizable logical
volumes.
The caveat in the last above suggestion however is that you cannot put
*/boot* on a logical volume unless you're using LILO as your boot loader,
installed in the MBR, due to the fact that the GRUB bootloader needs a
filesystem driver in order to load the kernel and is unfamiliar with
logical volumes. For LILO, this is not true because LILO uses a hardcoded
logical block address to reach the on-disk location of the kernel.
Additionally, having the root filesystem live on a logical volume, you'll
have to boot with an /initrd/ with LVM support built-in, but of course most
GNU/Linux distributions come with highly modular stock kernels that require
an /initrd/ anyway. It does however serve to be noticed for in the event
that you roll your own kernels. ;-)
> Then reason I ask is that I have a desktop and laptop with encrypted
> LVM's that house / and a swap in separate logical volume, but within the
> same logical group. The only other linux partitions is /boot which of
> course needs to remain unencrypted.
With regard to volume groups, I recommend using one and the same volume
group for all your logical volumes on the same hard disk, unless you have a
good reason as to why you would need more volume groups.
I myself have such a reason on my other machine, namely that I use different
volume groups to group together the filesystems belonging to the same
virtual machine, as that physical computer is going to run four virtual
machines with Xen, and each of those virtual machines will have highly
distributed filesystem hierarchies. With such a set-up, it's easier to
remove all filesystems belonging to a single virtual machine by simply
removing the volume group. ;-)
> I backup regularly using full disks clones for easy restoration, so I'm
> never worried about losing data.
Backups are a necessity, but that still doesn't mean that you can't do more
to protect your data and your system integrity. ;-)
> So just in theory, lets pretend I didn't have an encrypted LVM, what
> would be the benefits be?
I believe I've covered that higher up in this reply already. ;-)
Aragorn
in /comp.os.linux.hardware:/
> [...] What I wonder is: are disk cylinder numbers arranged like
>
> 1 - 511
> ---------+---------
> 512 -1023
> 1024-1535
> ---------+---------
> 1536-2048
>
> or like
>
> 1 - 511
> ---------+---------
> 1023- 512
> 1024-1535
> ---------+---------
> 2048-1536
>
> or like
>
>
> 1 2045
> --------+---------
> 2 2046
> 3 2047
> --------+---------
> 4 2048
>
> or does it vary by disk line? Heck, when the pool of bad block
> replacements is used, you're almost guaranteed an extra seek.
True, and then you're not even keeping into account that the disk geometry
as reported to the kernel is not the actual geometry at all, because with
modern-day large hard disks it is always being translated. And then
there's the low-level format, and such.
Modern hard disks are to be seen as abstractions, just like when you have a
RAID array that is seen by the kernel as being a single disk. The
optimizing is all already done in hardware.
Sheridan Hutchinson
<snip>
> I believe I've covered that higher up in this reply already. ;-)
And indeed you did! Thank you for such a well-considered reply, I shall
print it and consider the ramifications of making some changes to my
machines :)
--
Regards,
Sheridan Hutchinson
sher...@shezza.org
Haines Brown
> In article <87zllz9...@teufel.hartford-hwp.com>,
> Haines Brown <bro...@teufel.hartford-hwp.com> wrote:
>> An issue that has always troubled me is the optimal sequence of
>> partitions. For example, /swap is supposed to be located in relation to
>> the physical disks on the hard disk, but I never knew how to do
>> that. Howver, I'm not sure it makes any difference any more.
>
> Why wouldn't it make any difference? What I wonder is: are disk
> cylinder numbers arranged like
Yes, but how does one know what the physical platter limits are so that
one can put a partion near the edge?
Also, these days, I assume one does not normally use swap space, and so
what effect would its location normally have? What partitions need to be
near the platter edges?
--
Haines Brown, KB1GRM
Aragorn
wrote in /comp.os.linux.hardware:/
> ebenZ...@verizon.net (Hactar) writes:
>
>> In article <87zllz9...@teufel.hartford-hwp.com>,
>> Haines Brown <bro...@teufel.hartford-hwp.com> wrote:
>
>>> An issue that has always troubled me is the optimal sequence of
>>> partitions. For example, /swap is supposed to be located in relation to
>>> the physical disks on the hard disk, but I never knew how to do
>>> that. Howver, I'm not sure it makes any difference any more.
>>
>> Why wouldn't it make any difference? What I wonder is: are disk
>> cylinder numbers arranged like
>
> Yes, but how does one know what the physical platter limits are so that
> one can put a partion near the edge?
With a tool like /cfdisk/ you can create a partition that's aligned with the
end of the available diskspace, and thus close to the center of the platter
surface.
There are typically a few more cylinders beyond that, but those are not
coated with a magnetically susceptible alloy and are used to allow the disk
heads to land. (Hitachi/IBM disks are an exception to this rule as they
park the diskheads on a ramp outside the platter circumference.)
> Also, these days, I assume one does not normally use swap space, and so
> what effect would its location normally have? What partitions need to be
> near the platter edges?
The ones that require the least I/O.
Aragorn
Hutchinson* wrote in /comp.os.linux.hardware:/
> Aragorn wrote:
>
>> I believe I've covered that higher up in this reply already. ;-)
>
> And indeed you did! Thank you for such a well-considered reply, I shall
> print it and consider the ramifications of making some changes to my
> machines :)
Glad I could help! ;-)
Hactar
Haines Brown <bro...@teufel.hartford-hwp.com> wrote:
> ebenZ...@verizon.net (Hactar) writes:
>
> > In article <87zllz9...@teufel.hartford-hwp.com>,
> > Haines Brown <bro...@teufel.hartford-hwp.com> wrote:
>
> >> An issue that has always troubled me is the optimal sequence of
> >> partitions. For example, /swap is supposed to be located in relation to
> >> the physical disks on the hard disk, but I never knew how to do
> >> that. Howver, I'm not sure it makes any difference any more.
> >
> > Why wouldn't it make any difference? What I wonder is: are disk
> > cylinder numbers arranged like
>
> Yes, but how does one know what the physical platter limits are so that
> one can put a partion near the edge?
>
> Also, these days, I assume one does not normally use swap space,
I do (is that bad?), and there has been some discussion on whether
running without it is a good idea. (Conclusion: No, but not fatal.)
> and so what effect would its location normally have? What partitions
> need to be near the platter edges?
As you said, how do you tell what the platter edges' numbers _are_
without getting the source to the drive's firmware?
One part of my brain says swap should be near an edge to make for faster
transfers; another part says it should be toward the middle to increase
the chance that the head will pass over it when servicing other
requests. Same goes for /usr or other things for which output rate is
important.
--
-eben QebWe...@vTerYizUonI.nOetP royalty.mine.nu:81
PISCES: Try to avoid any Virgos or Leos with the Ebola
virus. You are the Lord of the Dance, no matter what those
idiots at work say. -- Weird Al, _Your Horoscope for Today_
Walter Mautner
> For many years I've been devoted to SCSI hard disks, but market trends
> seem to suggest SCSI is dying out. If that the case, does my sticking
> with SCSI any longer make sense?
>
SCSI is for the server market, while SATA drives mostly are consumer grade.
SATA drives are specified for 8/24 use, while SCSI are for 24/7.
You can of course get SATA server grade drives as well, since most new
storage cabinets have moved to SATA.
The drives then are not much cheaper than SCSI drives.
> Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
> that I will henceforth have to accept drive unreliability? I'm more
> interested in reliability than top speed (or, obviously, even cost).
>
> If I were to attach a SATA drive to my desktop machine, I'd be inclined
> to do a cross install of linux to the new SATA drive from my running
> SCSI drive. Any reason such a procedure would be problematic because of
> the interface difference?
>
Both use the scsi interface layer, but you need the chipset drivers or
drivers for your scsi/sata controller in place (kernel or initrd if you
want to boot from the attached drives).
--
vista policy violation: Microsoft optical mouse found penguin patterns
on mousepad. Partition scan in progress to remove offending
incompatible products. Reactivate MS software.
Linux 2.6.24. [LinuxCounter#295241,ICQ#4918962]
Pascal Hambourg
>
> SCSI is for the server market, while SATA drives mostly are consumer grade.
What about the non-server non-consumer market, for example professionnal
workstations ?
> SATA drives are specified for 8/24 use, while SCSI are for 24/7.
What does "8/24" mean ?
david
say:
>
>
> One part of my brain says swap should be near an edge to make for faster
> transfers; another part says it should be toward the middle to increase
> the chance that the head will pass over it when servicing other
> requests. Same goes for /usr or other things for which output rate is
> important.
I doubt one would be able to tell the difference. Don't sweat it.
The cylinder numbers have little to do with physical implementation on
modern hard drives anyway.
Pascal Hambourg
>
> The cylinder numbers have little to do with physical implementation on
> modern hard drives anyway.
However the logical address (LBA or CHS) is a rather reliable
information about how far a physical sector is from the edge of the
platters, except if the sector was reallocated because it was defective.
Hactar
Pascal Hambourg <pasca...@plouf.fr.eu.org> wrote:
> david a écrit :
How do you know those aren't remapped too? After all, the "C" in "CHS" means
"cylinder".
--
-eben QebWe...@vTerYizUonI.nOetP royalty.mine.nu:81
LIBRA: A big promotion is just around the corner for someone
much more talented than you. Laughter is the very best medicine,
remember that when your appendix bursts next week. -- Weird Al
Pascal Hambourg
> Pascal Hambourg <pasca...@plouf.fr.eu.org> wrote:
>
>>However the logical address (LBA or CHS) is a rather reliable
>>information about how far a physical sector is from the edge of the
>>platters, except if the sector was reallocated because it was defective.
>
> How do you know those aren't remapped too?
What do you mean by "those" ?
> After all, the "C" in "CHS" means "cylinder".
So what ?
Haines Brown
platters, I just wanted to make sure I understood.
First, I gather that these days disk geometry is translated for the
kernel in order to achieve optimization. Does this optimization mean
that the relative placement of partitions on hard disk platters is
of no longer any importance?
Second, because of this translation, I gather one can't really know the
physical placement of cylinders on the platter. So why is there a
recommendation to locate certain partitions needing fast I/O at toward
the center of the platter, when the physical location has no relation to
the start of freespace when setting up partitions?
Third, you say:
> With a tool like /cfdisk/ you can create a partition that's aligned
> with the end of the available diskspace, and thus close to the center
> of the platter surface.
I'm unclear why the end of available diskspace would near the center of
the platter surface (I probably once knew, but have forgotten).
Fourth, if partitions requiring fast I/O should be located at the start
of the platter where cylinders have fewer sectors, does it follow they
should be located at the beginning of available disk freespace as shown
by cfdisk?
Finally, just which partitions depend on fast I/O? I understand that
with the big RAM these days, swap is not likely to be one of them. Is
the I/O issue the only factor to take into consideration when deciding
upon the sequence of partitions when using cfdisk (other than which
need to be primary and logical partitions)?
--
Haines Brown, KB1GRM
Hactar
Pascal Hambourg <pasca...@plouf.fr.eu.org> wrote:
> Hactar a �crit :
> > Pascal Hambourg <pasca...@plouf.fr.eu.org> wrote:
> >
> >>However the logical address (LBA or CHS) is a rather reliable
> >>information about how far a physical sector is from the edge of the
> >>platters, except if the sector was reallocated because it was defective.
> >
> > How do you know those aren't remapped too?
>
> What do you mean by "those" ?
LBA and CHS.
> > After all, the "C" in "CHS" means "cylinder".
>
> So what ?
So whatever flaws basing decisions on cylinder number has, basing it
instead on CHS has the exact same flaws, since it's the same data.
--
-eben QebWe...@vTerYizUonI.nOetP http://royalty.mine.nu:81
GEMINI: Your birthday party will be ruined once again by your explosive
flatulence. Your love life will run into trouble when your fiancee hurls
a javelin through your chest. -- Weird Al, _Your Horoscope for Today_
Aragorn
Hambourg* wrote in /comp.os.linux.hardware:/
> Walter Mautner a écrit :
>>
>> SCSI is for the server market, while SATA drives mostly are consumer
>> grade.
>
> What about the non-server non-consumer market, for example professionnal
> workstations ?
Professional workstations typically have SAS, SCSI or servergrade SATA
disks.
>> SATA drives are specified for 8/24 use, while SCSI are for 24/7.
>
> What does "8/24" mean ?
8 hours of usage per day, of which 20% under full load. SCSI is typically
rated for 24 hours a day, 7 days a week usage, of which 80% under full
load.
Do however bear in mind that if you keep your systems running 24/7, you'd be
better off with motherboards and memory modules that support ECC, because
commodity PCs don't have that and if you keep those up for too long, their
memory may get corrupted due to cosmic radiation and other EM fields,
resulting in instability.
Aragorn
wrote in /comp.os.linux.hardware:/
> On the question of partition placement in relation to the physical
> platters, I just wanted to make sure I understood.
>
> First, I gather that these days disk geometry is translated for the
> kernel in order to achieve optimization.
No, it is rather translated so that the BIOS can properly use the disk. It
has to do with the maximum number of cylinders and heads that a BIOS can
work with, and so a translation is made to make it appear as if the disk
has more heads and fewer cylinders.
> Does this optimization mean that the relative placement of partitions on
> hard disk platters is of no longer any importance?
Well, I'd say that the importance is to be taken with a huge spoon of salt
these days, given the CHS translations and the remapping of bad sectors by
the drive unit itself, but in overall, the closer a partition is to the
beginning of available diskspace as expressed in logical blocks, the closer
it will still be to the beginning of the hard disk.
But either way, most hard disks already have a huge data cache, and the
Linux kernel also caches and buffers a lot of data in RAM.
> Second, because of this translation, I gather one can't really know the
> physical placement of cylinders on the platter.
Not with accuracy, no.
> So why is there a recommendation to locate certain partitions needing fast
> I/O at toward the center of the platter, when the physical location has no
> relation to the start of freespace when setting up partitions?
Well, as above. There is now far less accuracy in pinpointing where exactly
a partition begins and ends, but in overall partitions closer to the
beginning of a hard disk will have the highest throughput due to the outer
cylinders having more sectors per track.
> Third, you say:
>
>> With a tool like /cfdisk/ you can create a partition that's aligned
>> with the end of the available diskspace, and thus close to the center
>> of the platter surface.
>
> I'm unclear why the end of available diskspace would near the center of
> the platter surface (I probably once knew, but have forgotten).
Okay, I think you misread me here. :-) When I say "the center of the
platter surface", I mean that the platters form a circle when seen in two
dimensions, with the spindle at their center. And with most disks that I
know of, the beginning of the storage capacity on the disk is located at
the outermost cylinders, and the end of the storage capacity is at the
innermost cylinders - leaving a few cylinders open that are even closer to
the spindle for the landing of the disk heads.
> Fourth, if partitions requiring fast I/O should be located at the start
> of the platter where cylinders have fewer sectors, does it follow they
> should be located at the beginning of available disk freespace as shown
> by cfdisk?
Yes.
> Finally, just which partitions depend on fast I/O?
Well, that depends on the usage of the system. If you're running a database
server, then the partition holding the database will probably (slightly)
benefit from being closer to the beginning of the available diskspace.
But then again, this should be taken with a serious spoonful of salt because
of disk caching, and the fact that the actual type of filesystem you use
for a particular partition might have a far more significant impact on
performance than the physical location on the disk in terms of CHS
coordinates.
> I understand that with the big RAM these days, swap is not likely to be
> one of them. Is the I/O issue the only factor to take into consideration
> when deciding upon the sequence of partitions when using cfdisk (other
> than which need to be primary and logical partitions)?
What other factor would there be, beside I/O? ;-)
And by the way, whether partitions used by GNU/Linux are primary or logical
is totally irrelevant. The primary/extended/logical thing is a DOS legacy
which may still have some relevance when setting up Windows, but it has no
value whatsoever with regard to GNU/Linux, other than with regard to what
the device special file designating a certain disk partition will be
called. GNU/Linux does not require any primary or active partitions.
I myself typically do create my first three partitions as primary, but this
is only so as to have a more consistent numbering scheme, i.e. numbers 1 to
3 for the primaries, 4 for the extended container, and 5 and upward for all
logical partitions in the extended container.
Haines Brown
Thanks for the clear explanations. I'm much more on top of the situation
now.
--
Haines Brown, KB1GRM
David Lesher
>I'm not so sure that's a market trend. It just so happens to be that SCSI
>is no longer considered useful in the home and office desktop market, but
>servers are most definitely still using SCSI.
>However, the SCSI that's being used and marketed today is no longer of the
>parallel variant. Just as parallel ATA had to make way for serial ATA,
>SCSI has by now already started making way for serial attached SCSI (SAS)
>and iSCSI for storage area networks.
I'm sorry, but you'll have go a long way to convince me the parentage of
SAS is anything but:
MarketDroid 1): Damn, everyone is buying SATA drives; the price is
falling and we are screwed. How do we come up with a way to charge a
premium without really doing a lot of work?
MD2: I've got it! We'll rebadge SATA into something with SCSI in the
name, so it sounds beefier... hmmm that's it.. Serial Attached SCSI.
We save the investment in ""SCSI"" and build up the hype around it.
MD1: But SATA really has some pluses.. Are we going to ignore them?
MD2: We'll use Gate's ploy -- extend and embrace! We'll tweek some
SATA specs here and there, adding some things we can talk up. But
we'll save a bundle on connectors alone.
.....
In the past, SCSI server drives brought you two things: performance and
reliability. [Think of those 9 GB Barracudas..].
Now the issues are: Does SAS really do that much over SATA, for your
case? And: Does paying SAS prices really give you more reliable drives,
or just different electronics?
--
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
Aragorn
wrote in /comp.os.linux.hardware:/
> Aragorn <ara...@chatfactory.invalid> writes:
>
>> I'm not so sure that's a market trend. It just so happens to be that
>> SCSI is no longer considered useful in the home and office desktop
>> market, but servers are most definitely still using SCSI.
>>
>> However, the SCSI that's being used and marketed today is no longer of
>> the parallel variant. Just as parallel ATA had to make way for serial
>> ATA, SCSI has by now already started making way for serial attached SCSI
>> (SAS) and iSCSI for storage area networks.
>
> I'm sorry, but you'll have go a long way to convince me the parentage of
> SAS is anything but:
>
> MarketDroid 1): Damn, everyone is buying SATA drives; the price is
> falling and we are screwed. How do we come up with a way to charge a
> premium without really doing a lot of work?
>
> MD2: I've got it! We'll rebadge SATA into something with SCSI in the
> name, so it sounds beefier... hmmm that's it.. Serial Attached SCSI.
> We save the investment in ""SCSI"" and build up the hype around it.
>
> MD1: But SATA really has some pluses.. Are we going to ignore them?
>
> MD2: We'll use Gate's ploy -- extend and embrace! We'll tweek some
> SATA specs here and there, adding some things we can talk up. But
> we'll save a bundle on connectors alone.
As with everything, technology is mainly developed to get marketed rather
than for progress, but SAS is far more than what you describe above.
The serialization of SCSI does offer some benefits with regard to large
enterprises and data centers, and it all falls within the spirit of
extending the possibilities of SCSI, e.g. there is also iSCSI now, which is
a SCSI tunnel over ethernet.
> In the past, SCSI server drives brought you two things: performance and
> reliability. [Think of those 9 GB Barracudas..].
It still does. The drives themselves - or at least, the ones I know - are
basically the same as the U320 drives, but their maximum throughput is
higher, whereas you could end up with a bottleneck on parallel SCSI chains.
> Now the issues are: Does SAS really do that much over SATA, for your
> case? And: Does paying SAS prices really give you more reliable drives,
> or just different electronics?
SAS drives *are* SCSI drives, so they do have all the goodies that SCSI
comes with - e.g. ECC, logging, tagged command queueing - whereas SATA is
actually nothing other than a serialized ATA drive in which an attempt was
made to make ATA/IDE more SCSI-like.
Enterprise-grade SATA drives are probably just or nearly as reliable as
SAS/SCSI, but they lack the features that made SCSI stand out. SATA still
is ATA, don't forget that. ;-) Also, not all SATA drives - not even in the
enterprise-grade range - are fit to be used in RAID arrays, while SAS
drives all are RAID-rated.
On the other hand, if you care more about cost-effectiveness than features,
then SATA offers (far) more storage per Dollar/Euro than SCSI. But then
again, this was already the case for PATA - aka IDE, although SATA is IDE
as well - versus parallel SCSI.
So the bottom line is that if you're thinking about marketing scams, the
scam would rather rest with SATA than with SAS, because SATA was intended
to mimic SCSI over an IDE bus, but still has to rely on the SATA-specific
NCQ (native command queueing) over the SCSI-specific TCQ (tagged command
queueing), because TCQ on SATA sucks. Also, the difference in retail price
between a SAS disk and an U320 SCSI disk is mainly negligible.
Brandon McCombs
>> Haines Brown <bro...@teufel.hartford-hwp.com> wroteready worko), there
>>> Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
>>> that I will henceforth have to accept drive unreliability?
>> computer-readable reliability is probably Tyvek punched tape.
>
> Yes, but my subjective impression is that there is a very wide
> difference in reliability. Of the dozen SCSI drives I've used over the
> years, only one failed on me; reading on line discussions and reviews,
> it seems that SATA drives fail regularly.
I've been using SATA for the last few years and haven't had any issues
with them. I would recommend them because they provide high data
transfer rates and high RPMs with low cost. Not to mention their
connectors are so small that you can have 6 plugged into a very small
area on the motherboard and it's still easy to manage. The cables
themselves are also smaller than the older PATA cables which I also love.
I bought 2 320GB SATA2 drives 2 years ago on Newegg. I put them in a
mirror and have had no issues. My PC is on 24x7 too. About a year ago I
got 2 80GB SATA2 drives and put them into a strip array (on the same
controller as the other 2 320GB drives. Again, no issues to date.
criten
> In article <87d4ixb...@teufel.hartford-hwp.com>,
> Haines Brown <bro...@teufel.hartford-hwp.com> wrote:
>> ebenZ...@verizon.net (Hactar) writes:
>>
>>> In article <87hc89b...@teufel.hartford-hwp.com>,
>>> Haines Brown <bro...@teufel.hartford-hwp.com> wroteready worko), there
>>>> Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
>>>> that I will henceforth have to accept drive unreliability?
>>> _All_ drives are unreliable to some degree. The ultimate in
>>> computer-readable reliability is probably Tyvek punched tape.
>> Yes, but my subjective impression is that there is a very wide
>> difference in reliability. Of the dozen SCSI drives I've used over the
>> years, only one failed on me; reading on line discussions and reviews,
>> it seems that SATA drives fail regularly.
>>
>> the added expense of SCSI hard disks?
>
> It is my impression (which may be false and/or out of date) that the
> instances of drive hardware that are matched with SCSI controllers are the
> more reliable (longer-lasting) ones.
This is a common misconception. The interface is irrelevant, the 'mean
time failure rate' is most certainly relevant. Essentially you pay more
for a disk with a longer mean time failure rate, meaning its less likely
to fail. And yes, SCSI is dying.
Barry Keeney
> Hactar wrote:
>> In article <87d4ixb...@teufel.hartford-hwp.com>,
>> Haines Brown <bro...@teufel.hartford-hwp.com> wrote:
>>> ebenZ...@verizon.net (Hactar) writes:
>>>
>>>> In article <87hc89b...@teufel.hartford-hwp.com>,
>>>> Haines Brown <bro...@teufel.hartford-hwp.com> wroteready worko), there
>>>>> Would a move to a SATA 3.0 Gb/s drive such as the Seagate Barracuda mean
>>>>> that I will henceforth have to accept drive unreliability?
>>>> _All_ drives are unreliable to some degree. The ultimate in
>>>> computer-readable reliability is probably Tyvek punched tape.
>>> Yes, but my subjective impression is that there is a very wide
>>> difference in reliability. Of the dozen SCSI drives I've used over the
>>> years, only one failed on me; reading on line discussions and reviews,
>>> it seems that SATA drives fail regularly.
>>>
>>> I guess my question comes down to, why should one bother these days with
>>> the added expense of SCSI hard disks?
>>
>> It is my impression (which may be false and/or out of date) that the
>> instances of drive hardware that are matched with SCSI controllers are the
>> more reliable (longer-lasting) ones.
> This is a common misconception. The interface is irrelevant,
Well it makes a difference, just hard to say if the interface
improves the life of the drive.
> the 'mean
> time failure rate' is most certainly relevant. Essentially you pay more
> for a disk with a longer mean time failure rate, meaning its less likely
> to fail.
HAHAHAHHA!! Thanks, I needed a good laugh.....
Sorry, Not putting you down, Just the numbers they toss out.
I used to work for a company what wrote software for figuring
out the MTBF (Mean Time Between Failures) and spent a lot of
time working with reliability engineers. MTBF is a bit of a
guess at best.
Okay, Lets compare two seagate drives:
Barracuda 7200.10 SATA 3.0Gb/s 500-GB Hard Drive (ST3500630AS)
MTBF 700,000 hours (79 years!)
Barracuda ES.2 SAS 3.0-Gb/s 500-GB Hard Drive (ST3500620SS)
MTBF 1,200,000 hours (136 years!)
From the numbers about you might think the SAS drive is going to
last twice as long. I don't think either of these drives are going
to last 50+ years unused in storage let alone in a running system!
You might see 5-7 years of 24/7 running, at best, before they're
going to start to drop like flies.
To get MTBF you multiply the failure rate of the parts together.
So the more parts you use is likely to lower the MTBF. You can tweak
the numbers by using fewer or higher quality parts. If you can
half the number of parts the MTBF will get better, so 50 average parts
worse MTBF, 25 average parts better MTBF. But 50 high quality parts
could have a better MTBF then 25 average parts. You can use a few
super lower failure rate parts and lots of low quality parts and
get a better MTBF (on paper) then using all average parts and it
will fail more often then the MTBF would make you think. Then there
other factors like operating temperature, humidity, and environment
(dirty office/clean computer room/inside a flight computer in a
jet/etc).
At best you can figure from the MTBF that either they're using
better or fewer parts. But with something thats at least 10 times off
(7 vs. 70 years) you can't judge by MTBF.
MTBF looks great to marketing/sales people but not much real world
value for users.
--
Barry Keeney
Chaos Consulting
email barryk<at>chaoscon.com
"Rap is Square Dancing gone terribly, terribly Wrong...."
Whoever
It's a pity you did not learn what MTBF actually refers to.
>
> Okay, Lets compare two seagate drives:
>
> Barracuda 7200.10 SATA 3.0Gb/s 500-GB Hard Drive (ST3500630AS)
>
> MTBF 700,000 hours (79 years!)
>
>
> Barracuda ES.2 SAS 3.0-Gb/s 500-GB Hard Drive (ST3500620SS)
>
> MTBF 1,200,000 hours (136 years!)
>
> From the numbers about you might think the SAS drive is going to
> last twice as long. I don't think either of these drives are going
> to last 50+ years unused in storage let alone in a running system!
> You might see 5-7 years of 24/7 running, at best, before they're
> going to start to drop like flies.
>
That's not what MTBF is intended to measure. You are claiming that MTBF
should equal lifetime and it does not.
Essentially, MTBF measures the likelihood of a random failure, NOT an
end-of-life failure. Arguably, MTBF is only useful to people who run large
datacenters with many disks -- they can use MTBF to estimate the failure
rate of their drives.
Barry Keeney
It's the "average time between failures of a system" that's what
it means.
I wasn't saying *HOW* it should be used in the big picture.
>>
>> Okay, Lets compare two seagate drives:
>>
>> Barracuda 7200.10 SATA 3.0Gb/s 500-GB Hard Drive (ST3500630AS)
>>
>> MTBF 700,000 hours (79 years!)
>>
>>
>> Barracuda ES.2 SAS 3.0-Gb/s 500-GB Hard Drive (ST3500620SS)
>>
>> MTBF 1,200,000 hours (136 years!)
>>
>> From the numbers about you might think the SAS drive is going to
>> last twice as long. I don't think either of these drives are going
>> to last 50+ years unused in storage let alone in a running system!
>> You might see 5-7 years of 24/7 running, at best, before they're
>> going to start to drop like flies.
>>
> That's not what MTBF is intended to measure. You are claiming that MTBF
> should equal lifetime and it does not.
No, That's not my claim, I know it's not. When you only see the MTBF
number it's easy to jump to the idea about how long something might last.
I'm claiming the value of the "MTBF" is just about useless. There are
much better ways for life cycle analysis/modelling. MTBF is great to
toss out but has no real value by itself out of any context.
Without knowing how the value for MTBF was calculated you can't know
it's usefulness. Was it from a steady failure model like the Mil standards
or something else? Whats the data behind the MTBF? How did they
get this number? Did they do any real run testing or just run the
numbers (ideal temp/operating conditions) that gets the best MTBF number?
"Hmmm if we run the drive at a temp of -5C, the calculations say the MTBF
is 1,200,000 hours. That's within the listed operating range."
I'm not claiming Seagate or any other drive company is lying, cheating or
trying to mislead people, they are just putting out the info they have
that puts their products in the best light, idea enviroment/best possible
results. You might find a paper on how they do their testing but it'll take
some digging to figure out how they got their MTBF or MTTF numbers for
a drive.
> Essentially, MTBF measures the likelihood of a random failure, NOT an
> end-of-life failure. Arguably, MTBF is only useful to people who run large
> datacenters with many disks -- they can use MTBF to estimate the failure
> rate of their drives.
No, MTBF is the *AVERAGE* time between failures. That's why I hate
seeing it used in marketing and specs sheets. It's not the real average, not
even close (for hard drives anyway). It's not real data from years of
running the drives, they don't have the time to run the drives for years
before sending them to market to get the real numbers. It's just, at best,
educated guessing using known data about the parts.
If you take a 1000 new drives and run them until each fail the average
you get won't be anything like 1,200,000 hours, even if you toss out
numbers first 100 failures and only use the 900 longest lasting drives
data.
MTBF can be useful during the early design of new devices/electronics.
If I get a value of MTBF of 1000 hours and I need atleast 2000 hours I
need to rework the design or use other methods to figure out why it's
low and fix the design.
MTBF isn't useful by itself. The Annual Failure Rate(AFR) might be more
useful, depending how they figured that out but no details on this either.
(AFR for the ST3500630AS is 0.34%, ST3500620SS is 0.73% )
How do I decide on a drive vendor?
I use warranties and how the company deals with warranty
repairs/replacement for drives as a guild. Not going to be
the only thing I look at but it has been useful to me.
A Short warranty - 3 years or less
Paying to upgrade the warranty to 4 or 5 years.
Limits for warranty replacement (only one warranty replacement, etc)
Having to pay shipping costs
These are possible problems and the drive might not be as good as
others or it's going costs more over the long run.
Is the warranty for their drives in their external cases the
same as internal drives?
If the maker can't build a case/drive combo that they will stand
behind as long as an internal drive, maybe I should look elsewhere.
Whoever
Again, you show that you don't really understand MTBF. Most drives will
fail because they reach end-of-life (they wear out). This is irrelevent to
MTBF.
Instead, if you took 1,200 drives, on average, you would expect one to
fail every 1000 hours, assuming that you: 1. Ignore early failures and 2.
swap out the drives before they wear out (without counting these
swapped-out drives as failures).
For the average user, the lifetime of the drive is more important. I'm not
aware of drive manufacturers providing this information to consumers,
however, like you, I believe it can be inferred from the warranties
provided with the drives.
Barry Keeney
Something "wearing out" is a failure! Just because you don't repair
the failed part/system doesn't mean is doesn't count as a failure! It
should be call MTTF (Mean Time To Fail) if it's not going to be repaired.
> Instead, if you took 1,200 drives, on average, you would expect one to
> fail every 1000 hours, assuming that you: 1. Ignore early failures and 2.
> swap out the drives before they wear out (without counting these
> swapped-out drives as failures).
No thats 1000 hrs MTBF/MTTF, with only one failure that's the only real
data you have. The other 1199 drives haven't failed so you can't
expand their "not failing" for MTBF. Failure rate yes, 1 per 1000 hours.
(the problem with a small failure sample size)
Okay, let's use "your" numbers. 1 per 1000hrs and drives don't "wear out"
just fail.
So one drive fails after 1000hrs, next at 2000hrs, third at 3000hrs, etc.
At that rate after 10 years you'd have a total of *only* ~88 of the orignal
1200 fail (8766hrs/year). With less the 10% of the drives failing, you have
a total of 3,916,000hrs of operation of the 88 drives with a MTBF of 44,500hrs
or 5.08 years.(But are 1100+ drives really going to be running after
10 years?)
Now run the numbers up to 100 failures. Thats a total of 5,050,000hrs
or MTBF of 50,500hrs or 5.76years. (after running the test for 11.40 years!)
Before you jump on this, remember the other 1100 drives are still
running.... AND I'm using *Your* numbers.
At this rate the MTBF is still below what the real data, your
numbers are generating. If we started out with only a 100 drives
it would be the real MTBF for this sample. (50,500hrs/5.76years)
It's going to take 136+ years before all 1200 drives should
fail. (at 1 per 1000hrs or 8.766 per year.)
Keep running the numbers and MTBF might grows up to numbers like
1,200,000 hours. Depending on sample size and a flat failure rate.
That's the problem of a flat failure rates and the models that use
them. Doesn't deal with the higher numbers of failures at the beginning
(infant mortality) and near the end of life. (aka "Bath tub" curve
failure rates)
Now if the drive maker has a 5 year warranty and wants atleast 90%
to make it to 5 years you'd want the MTBF/MTTF to be around 40,000hrs
or 4.56yrs. (excluding early life failures and raising failure rates
with age)
So MTBF's of 1,200,000 are worthless without info used to get the number.
> For the average user, the lifetime of the drive is more important. I'm not
> aware of drive manufacturers providing this information to consumers,
Well if you're a big computer maker like Dell/HP/etc you're going
to want detailed specs on parts before you decide to use them and/or
a warranty that works for the price point you're looking for.
They don't want their name to be hurt because they used a cheap
drive thats fails too often.
> however, like you, I believe it can be inferred from the warranties
> provided with the drives.
You've got to figure they've done the math and know how much the
warranties are going to cost per unit and they still expect a profit
over the product life/warranty life.
--
Barry Keeney
Chaos Consulting
email bar...@chaoscon.com
Whoever
Ah, I see the reason for your poor understanding of MTBF, you have poor
reading comprehension skills also. What is it about "2.
swap out the drives before they wear out (without counting these
swapped-out drives as failures)." that you don't understand? In my
scenario, not one of the "other 1100 drives" would be running, because
they would have been swapped out.
>
> At this rate the MTBF is still below what the real data, your
> numbers are generating. If we started out with only a 100 drives
> it would be the real MTBF for this sample. (50,500hrs/5.76years)
>
> It's going to take 136+ years before all 1200 drives should
> fail. (at 1 per 1000hrs or 8.766 per year.)
Again, look up the definition of MTBF. It assumes that you replace or
repair failed units, so there is no time at which "all 1200 drives ...
fail". Instead, they have all been swapped out (because of age, not
necessarily failure), probably many times and at the end of the
experiment, you still have 1200 drives.
One more comment, you might want to study some statistics. In the
experiment you propose, there is an ever reducing number of drives in the
experiment (as they fail), yet the rate at which drives fail is unchanged.
This seems rather unlike -- instead, as the number of drives in the
experiement is reduced, the number of drives that fail per month would
also be reduced.
I will agree with you on one thing though -- I do suspect that MTBF rates
are artifically high.
Robert Nichols
Whoever <nob...@devnull.none> wrote:
:
:For the average user, the lifetime of the drive is more important. I'm not
:however, like you, I believe it can be inferred from the warranties
:provided with the drives.
Out of curiosity, I did some calculations based on the SMART data
for Power_On_Hours on a couple of my PATA drives:
Drive A (ST380013A):
ID# ATTRIBUTE_NAME VALUE WORST THRESH TYPE UPDATED RAW_VALUE
9 Power_On_Hours 058 058 000 Old_age Always 36796
Looks like 36796 hours might be 42% (100 - 58) of expected life.
(36796 / .42) = 87610 hours, or 10.00 years
Drive B (ST3500630A):
ID# ATTRIBUTE_NAME VALUE WORST THRESH TYPE UPDATED RAW_VALUE
9 Power_On_Hours 092 092 000 Old_age Always 7078
(7078 / .08) = 88475 hours, or 10.10 years
Surprisingly consistent, and strictly "FWIW", which might be not much
since I'm making an assumption about the unknown conversion from raw
to normalized values.
--
Bob Nichols AT comcast.net I am "RNichols42"
Barry Keeney
No it just shows you don't know much about failure analysis.
You don't wait until the product is out with customers to figure
out how long it's going to last. You test BEFORE going to market.
To figure out failure rates you can test or use known data.
If you're testing you need to run *UNTIL* failure. You can't
get failure data/rates if you're replacing your test sample before
they fail. "We didn't have any fail, they'll last forever!" :^)
If you're not using some sort of stress testing (higher temps/etc)
then you can just run them until failure. You pick a sample size
run them until you have enough failures to figure out failure rates
and MTBF.
Your scenario might be how some companies run there data centers,
but I haven't seen this. I've seen replacing everything every 3-5 years
with newer tech and replacing failed parts as needed as more the norm.
Once you buy the product, you can test how you like, but it
doesn't sound like testing but more like running in an production
environment were you want to prevent failures.
>> At this rate the MTBF is still below what the real data, your
>> numbers are generating. If we started out with only a 100 drives
>> it would be the real MTBF for this sample. (50,500hrs/5.76years)
>>
>> It's going to take 136+ years before all 1200 drives should
>> fail. (at 1 per 1000hrs or 8.766 per year.)
> Again, look up the definition of MTBF. It assumes that you replace or
> repair failed units, so there is no time at which "all 1200 drives ...
> fail". Instead, they have all been swapped out (because of age, not
> necessarily failure), probably many times and at the end of the
> experiment, you still have 1200 drives.
Not in "run to failure testing", you don't replace the failures.
You continue to run the remaining units until either the time for the
test is over or you reach the number of failures required, depending
on the test parameters. If you replace a failed part, that parts start
time is different and you'll need to keep track of this. If you're running
a 1000 hour test this replacement will still need to run the 1000 hours,
not whatever hours remain. Otherwise it wouldn't have been stress the
same as the orignal units in the sample.
> One more comment, you might want to study some statistics. In the
> experiment you propose, there is an ever reducing number of drives in the
> experiment (as they fail), yet the rate at which drives fail is unchanged.
> This seems rather unlike -- instead, as the number of drives in the
> experiement is reduced, the number of drives that fail per month would
> also be reduced.
Since we haven't run the real world test we can only model it using
known info. 1200 drives, fixed failure rate of 1 per 1000hrs.
With fixed failure rate models, failure rate is constant, number of
units doesn't matter. You've got 10, one fails per hour, after 5 hours
you'll have 5, Not what you'd see in the real world true. So you do get
the results I used. Again, a problem with fixed failure rate models.
(Hmm I keep saying this but you don't seem to notice it....)
In Real testing this *shouldn't* be the case. You'll expect to get a
spike of failures near the start, lower in the middle and raising when
nearing end of life. I *think* we can agree on this?
> I will agree with you on one thing though -- I do suspect that MTBF rates
> are artifically high.
Well there is that.....
--
Barry Keeney
Chaos Consulting
email barryk<@>chaoscon.com