SCSI vs SATA hard disks - Hardware

This is a discussion on SCSI vs SATA hard disks - 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 ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 53

Thread: SCSI vs SATA hard disks

  1. Re: SCSI vs SATA hard disks

    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?

    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?

    --
    Regards,
    Sheridan Hutchinson
    Sheridan@Shezza.org


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

    iEYEARECAAYFAkjY0RcACgkQnBrliHqz8aB8SACgviuVbTzmym 5akGjXDmraVd13
    /qAAoKqwMQUmXqssiUuZ6awAuRUIdggW
    =n5PB
    -----END PGP SIGNATURE-----


  2. Re: SCSI vs SATA hard disks

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

    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




  3. Re: SCSI vs SATA hard disks

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


    For example, "mount none /mnt/temp -t tmpfs -o size=10M"

    > and why this it is a good idea to do it.


    That's tougher. Frees up disk space? No, disk is much cheaper than
    RAM. Speeds up some apps? If you reboot weekly at least you can scrap
    tmpclean or whatever it's called.

    > 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

    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.

    --
    -eben QebWenE01R@vTerYizUonI.nOetP royalty.mine.nu:81
    VIRGO: All Virgos are extremely friendly and intelligent - except
    for you. Expect a big surprise today when you wind up with your
    head impaled upon a stick. -- Weird Al, _Your Horoscope for Today_

  4. Re: SCSI vs SATA hard disks

    On Tuesday 23 September 2008 14:03, someone identifying as *Haines Brown*
    wrote in /comp.os.linux.hardware:/

    > Aragorn 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*
    (registered GNU/Linux user #223157)

  5. Re: SCSI vs SATA hard disks

    On Tuesday 23 September 2008 13:20, someone identifying as *Sheridan
    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*
    (registered GNU/Linux user #223157)

  6. Re: SCSI vs SATA hard disks

    On Tuesday 23 September 2008 18:37, someone identifying as *Hactar* wrote
    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.

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

  7. Re: SCSI vs SATA hard disks

    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

    --
    Regards,
    Sheridan Hutchinson
    sheridan@shezza.org


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

    iEYEARECAAYFAkjZmsIACgkQnBrliHqz8aAskACfSLUuMhbi+r gRp8lqfK+qErQ0
    ROIAnjwMA+J2ZhsIaxL0t4Cw525HGrpa
    =R80j
    -----END PGP SIGNATURE-----


  8. Re: SCSI vs SATA hard disks

    ebenZEROONE@verizon.net (Hactar) writes:

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




  9. Re: SCSI vs SATA hard disks

    On Wednesday 24 September 2008 04:33, someone identifying as *Haines Brown*
    wrote in /comp.os.linux.hardware:/

    > ebenZEROONE@verizon.net (Hactar) writes:
    >
    >> In article <87zllz9iip.fsf@teufel.hartford-hwp.com>,
    >> Haines Brown 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*
    (registered GNU/Linux user #223157)

  10. Re: SCSI vs SATA hard disks

    On Wednesday 24 September 2008 03:41, someone identifying as *Sheridan
    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! ;-)

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

  11. Re: SCSI vs SATA hard disks

    In article <87vdwm9ssc.fsf@teufel.hartford-hwp.com>,
    Haines Brown wrote:
    > ebenZEROONE@verizon.net (Hactar) writes:
    >
    > > In article <87zllz9iip.fsf@teufel.hartford-hwp.com>,
    > > Haines Brown 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 QebWenE01R@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_

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

  13. Re: SCSI vs SATA hard disks

    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 ?

    > SATA drives are specified for 8/24 use, while SCSI are for 24/7.


    What does "8/24" mean ?

  14. Re: SCSI vs SATA hard disks

    On Tue, 23 Sep 2008 23:20:10 -0400, Hactar rearranged some electrons to
    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.

  15. Re: SCSI vs SATA hard disks

    david a écrit :
    >
    > 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.

  16. Re: SCSI vs SATA hard disks

    Hactar a écrit :
    > Pascal Hambourg 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 ?

  17. Re: SCSI vs SATA hard disks

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




  18. Re: SCSI vs SATA hard disks

    In article ,
    Pascal Hambourg wrote:
    > Hactar a écrit :
    > > Pascal Hambourg 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 QebWenE01R@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_

  19. Re: SCSI vs SATA hard disks

    On Wednesday 24 September 2008 11:30, someone identifying as *Pascal
    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*
    (registered GNU/Linux user #223157)

  20. Re: SCSI vs SATA hard disks

    On Wednesday 24 September 2008 17:36, someone identifying as *Haines Brown*
    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.

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

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