SCSI vs SATA hard disks - Hardware

This is a discussion on SCSI vs SATA hard disks - 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? Would a move to a SATA 3.0 ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 53

Thread: SCSI vs SATA hard disks

  1. SCSI vs SATA hard disks

    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?

    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




  2. Re: SCSI vs SATA hard disks

    In article <87hc89bmfm.fsf@teufel.hartford-hwp.com>,
    Haines Brown 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 QebWenE01R@vTerYizUonI.nOetP royalty.mine.nu:81

    What do you do with dead chemists?
    Barium. -- Harold_of_the_Rocks on Fark

  3. Re: SCSI vs SATA hard disks

    ebenZEROONE@verizon.net (Hactar) writes:

    > In article <87hc89bmfm.fsf@teufel.hartford-hwp.com>,
    > Haines Brown 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




  4. Re: SCSI vs SATA hard disks

    In article <87d4ixbd77.fsf@teufel.hartford-hwp.com>,
    Haines Brown wrote:
    > ebenZEROONE@verizon.net (Hactar) writes:
    >
    > > In article <87hc89bmfm.fsf@teufel.hartford-hwp.com>,
    > > Haines Brown 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 QebWenE01R@vTerYizUonI.nOetP royalty.mine.nu:81

    Hi! I'm a .sig virus! Copy me to your .sig!


  5. Re: SCSI vs SATA hard disks

    On Sun, 21 Sep 2008 10:31:09 -0400, Haines Brown typed this message:

    > 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.

  6. Re: SCSI vs SATA hard disks

    On 2008-09-21, Haines Brown 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.

    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

  7. Re: SCSI vs SATA hard disks

    Haines Brown wrote:
    > 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
    Sheridan@Shezza.org




    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.9 (GNU/Linux)

    iEYEARECAAYFAkjWzAoACgkQnBrliHqz8aC+zACeOiStSkDE3J FwbtI6iO+Uo5zx
    7UEAnjruvPd33xKEkauRG/dj/JA0DoYe
    =2dWt
    -----END PGP SIGNATURE-----


  8. Re: SCSI vs SATA hard disks

    On Sunday 21 September 2008 16:31, someone identifying as *Haines Brown*
    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)

  9. Re: SCSI vs SATA hard disks

    Rikishi42 wrote:
    > On 2008-09-21, Haines Brown 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.
    >

    I'd take issue with this one. All the SCSI disks we've got or worked
    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

  10. Re: SCSI vs SATA hard disks

    Hello,

    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.

  11. Re: SCSI vs SATA hard disks

    On 09/21/2008 10:31 AM, Haines Brown 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?
    >
    > 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?
    >


    Particularly in light of some of the comments that have already been made,
    you might find
    http://www.usenix.org/publications/l...npdfs/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

  12. Re: SCSI vs SATA hard disks

    Haines Brown 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?


    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.


  13. Re: SCSI vs SATA hard disks

    On Monday 22 September 2008 12:23, someone identifying as *Pascal Hambourg*
    wrote in /comp.os.linux.hardware:/

    > 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.


    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. ;-)

    --
    *Aragorn*
    (registered GNU/Linux user #223157)

  14. Re: SCSI vs SATA hard disks

    Since you are puzzled by what I meant by cross-installation, let me be
    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




  15. Re: SCSI vs SATA hard disks

    Your remarks on SCSI much appreciated. I find the SAS choices rather
    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




  16. Re: SCSI vs SATA hard disks

    On 2008-09-22, Haines Brown wrote:

    > 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.


    --
    Elevators smell different to midgets

  17. Re: SCSI vs SATA hard disks

    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.

    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. ;-)

    --
    *Aragorn*
    (registered GNU/Linux user #223157)

  18. Re: SCSI vs SATA hard disks

    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.

    > 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/

  19. Re: SCSI vs SATA hard disks

    On Tue, 23 Sep 2008 11:00:59 +0200, Pascal Hambourg rearranged some
    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


    >> 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/



  20. Re: SCSI vs SATA hard disks

    david a écrit :
    > On Tue, 23 Sep 2008 11:00:59 +0200, Pascal Hambourg rearranged some
    > electrons to say:
    >>
    >>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.


    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.


    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.

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast