Forgot your password?
typodupeerror
Data Storage Hardware Linux

Linux Not Quite Ready For New 4K-Sector Drives 258

Posted by CmdrTaco
from the when-more-is-less dept.
Theovon writes "We've seen a few stories recently about the new Western Digital Green drives. According to WD, their new 4096-byte sector drives are problematic for Windows XP users but not Linux or most other OSes. Linux users should not be complacent about this, because not all the Linux tools like fdisk have caught up. The result is a reduction in write throughput by a factor of 3.3 across the board (a 230% overhead) when 4096-byte clusters are misaligned to 4096-byte physical sectors by one or more 512-byte logical sectors. The author does some benchmarks to demonstrate this. Also, from the comments on the article, it appears that even parted is not ready, since by default it aligns to 'cylinder' boundaries, which are not physical cylinder boundaries and are multiples of 63."
This discussion has been archived. No new comments can be posted.

Linux Not Quite Ready For New 4K-Sector Drives

Comments Filter:
  • by Anonymous Coward

    damnit, obviously since this is not technically the 'first post', my web browser must be misaligned by a post

    • the first time i have ever actually gotten 'first post'... it is when i try to make a joke about not having gotten first post. ya see my first post was supposed to come up like second or third.. it would have been HILARIOUS . .. but oh no in soviet russia, the fates mock you!!!!
  • by tchuladdiass (174342) on Sunday February 14, 2010 @01:37PM (#31135416) Homepage

    The simple solution is to set you Sectors per Track to 32. This would make sure that everything is properly aligned (except the first partition, usually /boot, which is mis-aligned by one cylinder).

    • Re: (Score:3, Insightful)

      by Brian Gordon (987471)

      Sectors, blocks, clusters, cylinders... I hope that as we move to solid state drives, devs have the sense to exorcise these anachronisms from the kernel. We haven't been able to get rid of terminals in the 20 years since they've even existed.. this document [linux.org] is heart wrenching. Try reading it; it'll make you cry to see how deeply the now-irrelevant concept of a terminal runs in Linux.

      • by walshy007 (906710) on Sunday February 14, 2010 @02:14PM (#31135686)

        the now-irrelevant concept of a terminal

        Speak for yourself sir, I for one like my rs-232 terminals to be handy for when ethernet is down and you can't ssh (and can't be assed hooking up keyboard and monitor). Seriously, anyone adept at the command line uses it far more than the gui to get things done, terminals will never disappear.

        • by Anonymous Coward on Sunday February 14, 2010 @08:14PM (#31138700)

          I don't think he was dissing command line interfaces.

          I think his complaint was that even newfangled RS-232 terminals had to jump through hoops to remain compatible with computers that were hooked up to typewriters and line printers. The protocols and underlying software have idiosyncrasies built into them that just don't make sense any more. Instead of throwing away the cruft to make something better, everybody's hacking onto the same old outdated shit. It's limiting progress, in a way.

      • Re: (Score:2, Offtopic)

        by jedidiah (1196)

        Terminals are only irrelevant if you have a strictly Windows and DOS notion of computing.

        The document you cited touches on this a little bit.

      • by rubycodez (864176) on Sunday February 14, 2010 @02:19PM (#31135726)

        terminals are a very necessary and relevant part of Linux. That's how most server administration is done. That's how sending commands to many network appliances is done. That's how setting up high end computers is done (e.g. set up a midrange Integrity or Superdome and you'll start with terminal on the serial port, whether cu in linux or hyperterminal in windowws or a real terminal). Also how certain tasks are performed in GUI environments. It doesn't matter that the terminal is now mostly virtual, the cursor control and font attribute features make convenient applications possible. Even on the weekend here I am chatting via IRC to some tech friends with irssi in terminal under screen, and reading server status emails with mutt. the terminal, it's 21st century tool.

        • by Anonymous Coward on Sunday February 14, 2010 @02:45PM (#31135860)

          terminals have nothing to do with the command line!
          i think the op is complaining about the fact that things like
          baud, stopbits and whatnot are deeply embedded in the
          linux kernel. these concepts are not necessary to
          have a command line. c.f. plan 9.

      • by kimvette (919543) on Sunday February 14, 2010 @04:23PM (#31136610) Homepage Journal

        The terminal is not irrelevant. If your Cisco router is ever compromised (it happens) or if IOS becomes corrupt (or if you have an IOS install with a nasty bug where the password does not save correctly, or when an IOS upgrade goes badly) or someone fudges the configuration up, the only way you can recover it is often through the serial port. Serial ports are also very handy for integrating video surveillance with point-of-sales systems that are not IP-aware (or worse, antiquated DVR appliances which can't do POS integration over IP), for some smart switches, *NIX boxes that have been rooted (I've rescued a Solaris box through a serial connection in an enterprise environment where reinstall was not possible due to poor timing - week of finals - and backups were sabotaged by a disgruntled gradute student and logins through IP and at the console were blocked), and so forth. However, I'd rather see RS-485 or RS-422 take RS232's place, since RS-485 and RS-422 can work over much longer distances and you can hang multiple serial devices off of a single bus.

        RS-232 might be absent from a lot of consumer motherboards, but it is far from dead and certainly not irrelevant, even now in 2010.

        • by kimvette (919543) on Sunday February 14, 2010 @04:31PM (#31136700) Homepage Journal

          Oh, in addition, now that Windows Server (Core) has a real GUI-less mode and Powershell and UNIX environment shells on Windows finally have usable interfaces, shell prompts are becoming even more relevant even in large Window shops. So, even Microsoft has acknowledged that the UNIX-y way of doing things is key for automation and uptime in an enterprise environment. Now, most PCs won't boot with output to the serial port, but some enterprise server boards do have such options.

          A GUI is great for basic tasks, but for repetitive tasks a command shell and scripting environment are key for efficiency, and reliable automation. VBS/Windows Scripting Host was an "acceptable" workaround for a while but in the past many Windows administrative tools required the box to not be headless, the workstation unlocked and the windows open for the GUI to be accessible for scripting - and even then it was iffy because not all GUI elements are accessible (especially third-party tools with custom controls).

      • Re: (Score:2, Funny)

        by orkysoft (93727)

        I recommend you visit Microsoft [microsoft.com] and have a look at their "Windows" operating system. The concept of a terminal doesn't run nearly as deep in it as it does in Linux. The same goes for the concept of security. Overall, it is kind of a poorly reinvented UNIX, but I think you might just like it. There are quite a few applications available for it nowadays, and it is gaining more and more marketshare and public recognition.

        • Re: (Score:3, Funny)

          by cerberusss (660701)

          I recommend you visit Microsoft [microsoft.com] and have a look at their "Windows" operating system. [...] Overall, it is kind of a poorly reinvented UNIX, but I think you might just like it.

          I've seen some people use it, then they told me you had to pay for it. I was flabbergasted -- why would anyone pay for an operating system?

    • by Z00L00K (682162) on Sunday February 14, 2010 @03:03PM (#31135984) Homepage

      Essentially we are back to the old problems of the ST412 interface where we had to figure out the best interleave for the drives as well when we were formatting them. Most drives then did have a fairly conservative interleave, but a reformat of them could improve the throughput considerably. A reformat could be done so that the whole track could be read in 2 rotations instead of 3, and what that does to performance is fairly easy to understand. C800:5 was a commonly used BIOS address where the low level format routine did reside.

      But from what I understand this problem is an offset problem when the head steps from track to track, and that's also an issue to be considered. And today it's not common knowledge/practice to low level format hard drives.

      And why stick at 4k sectors? Depending on the system you may want to use a different sector size. If you run Oracle on some systems the block size is 8k, and in that case you may want to have 8k disk blocks too since it would be good for performance.

      Anyway - sooner or later we will have flash drives instead, and then this isn't a problem.

      • by amorsen (7485) <benny+slashdot@amorsen.dk> on Sunday February 14, 2010 @03:34PM (#31136186)

        Anyway - sooner or later we will have flash drives instead, and then this isn't a problem.

        Actually this problem is potentially much worse on SSD's. Erase blocks are huge, and read-modify-write really sucks on flash.

        • by blincoln (592401) on Sunday February 14, 2010 @03:49PM (#31136294) Homepage Journal

          Actually this problem is potentially much worse on SSD's. Erase blocks are huge, and read-modify-write really sucks on flash.

          Couldn't this be addressed (at least in part) by a battery-backed write cache like better RAID controllers use? Set it up like SAN snapshots (so it just stores the diff between what's in the actual flash storage and what's been changed so far), and then write the changed blocks when it's most advantageous (e.g. when there's an entire block's worth of data, so it would all have to be erased by the flash storage anyway).
          Maybe combine that with something like a disk defrag, except instead of storing frequently-sequentially-read data in physical sequence, store frequently-written data (regardless of if it's sequentially-read or not) in physical sequence.

          • by bertok (226922) on Sunday February 14, 2010 @05:11PM (#31137048)

            Actually this problem is potentially much worse on SSD's. Erase blocks are huge, and read-modify-write really sucks on flash.

            Couldn't this be addressed (at least in part) by a battery-backed write cache like better RAID controllers use? Set it up like SAN snapshots (so it just stores the diff between what's in the actual flash storage and what's been changed so far), and then write the changed blocks when it's most advantageous (e.g. when there's an entire block's worth of data, so it would all have to be erased by the flash storage anyway).
            Maybe combine that with something like a disk defrag, except instead of storing frequently-sequentially-read data in physical sequence, store frequently-written data (regardless of if it's sequentially-read or not) in physical sequence.

            That's exactly what most SSD controllers do!

            Some now come with 32 to 64MB of cache, and some of the new Sandforce controller based SSDs also come with a little ultracapacitor that acts like a mini UPS. The cache is used as scratch space for reordering writes and defragging blocks.

            There was a firmware patch recently for the OCZ Vertex series of SSDs that enabled background defrag. If you let the drive site there for a few minutes, it would start getting faster until it returned to 'as new' speeds

  • Good thread on this. (Score:4, Informative)

    by Anonymous Coward on Sunday February 14, 2010 @01:38PM (#31135426)
    • One of the comments in that thread suggests switching to GPT if you aren't using Windows.
      I haven't used Windows at home since ~2001.

      Can you just wipe/reinstall using GPT? I thought the BIOS was involved with the type of partition table and that I had to be using the msdos partition type because of the BIOS. Can a geek with deeper knowledge of partitions and and all things boot drop some knowledge?

      • Re: (Score:2, Informative)

        by Anonymous Coward

        The BIOS has no understanding of partition tables. It merely reads the first sector of the harddrive to 0x7C00 and then jumps to that location. The DOS partition table is used by convention for interoperability between operating systems. If you wanted to use a different partitioning scheme, there is no technical reason your operating system couldn't.

      • Re: (Score:3, Interesting)

        by Anonymous Coward

        GPT wraps itself in a MBR partition map. At the very least the GPT is supposed to include an MBR map that claims the whole disk as used by GPT to avoid issues with old disk tools and the like. And if you've got a partition scheme that's compatible with the MBR scheme they can both contain the same information, assuming your disk tool supports this, so that MBR-only environments can still find your partitions.

        It's also possible to format with GPT and then use an MBR-only tool (fdisk) to go back and manipulat

      • by marcansoft (727665) <hector@@@marcansoft...com> on Sunday February 14, 2010 @02:08PM (#31135644) Homepage

        Unless your BIOS is trying to be too smart and peeking into your partitions instead of launching the MBR (sadly, some do), it won't matter. It's the MBR's job to boot your system after the BIOS hands off control to it, and on most Linux systems the bootloader is installed straight into the MBR.

      • Re: (Score:3, Informative)

        by Z34107 (925136)

        Even if you are using Windows, Vista and up support GPT. It's handy for servers where you expect to have partitions larger than 2 TB.

        But I guess if one were using a modern version of Windows, you wouldn't have the 4K alignment problems to begin with.

  • by bogaboga (793279) on Sunday February 14, 2010 @01:43PM (#31135460)

    I am no kernel hacker but I can almost guarantee that some kernel hacker will provide a solution to this "short coming" fairly soon.

    That's the beauty of Open Source.

    I am aware though that "fairly soon" means many things to many people; which means that there could be a substantial delay before we get a working solution to this issue.

    I am optimistic nevertheless.

    Request to Western Digital: Provide all the information needed to develop a solution.

    • by nomadic (141991)
      That's the beauty of Open Source.

      And that couldn't possibly happen with closed source?
      • by bogaboga (793279)

        I guess you only read but did not understand! Key words in my piece are: "Fairly soon."

        • by Blakey Rat (99501)

          Well, since Windows Vista and Windows 7 already support this, I'd say "fairly soon" is demonstrably false. Unless you're happy with "fairly soon" being "after everybody else has been doing it for several years."

      • by hedwards (940851)
        Trust me, it's right after adding GPT support to Windows XP home on their agenda. Shouldn't take more than, I don't know forever to add.
  • So don't do that... (Score:2, Informative)

    by russotto (537200)

    Author claims a massive performance drop if things aren't aligned right. Ubuntu already does it with parted and fdisk can do it manually. So, no big problem; fdisk ought to be fixed to have sane defaults with a 4096 byte block size, sure. That can't be all that difficult.

    The author also seems to think that only a 30% increase in times for misaligned writes should be expected. I'm not sure why. In a naive implementation I'd expect a 100% increase in time (each block now needs to be written twice). Linu

    • Re: (Score:3, Insightful)

      by marcansoft (727665)

      fdisk doesn't need to be fixed, it needs to be deprecated. DOS partition tables are a ridiculously bad artifact of the past. We won't be using them for much longer anyway; they're limited to 2TB for 512-byte-sector drives (or 4K drives with 512-byte emulation).

  • by macemoneta (154740) on Sunday February 14, 2010 @01:54PM (#31135536) Homepage

    I know that Fedora seems to have addressed this with parted 2.1.1 [fedoraproject.org] and util-linux-ng 2.1 [fedoraproject.org]. Both are scheduled for Fedora 13, but can be pulled into Fedora 12 by those getting the hardware early.

  • Oh slashdot.. (Score:5, Insightful)

    by JeffSh (71237) <jeffslashdot.m0m0@org> on Sunday February 14, 2010 @02:00PM (#31135576)

    Dear Slashdot,

    I've been around for a while. Enough to understand, nay, love the fact that you are linux supporters and all that. But I remain an ardent supporter of truth and speaking in ways which are concise and leads the reader in the direction of truth. Nothing in this news story is inaccurate, but to make it a point to say that Windows XP is incompatible with no mention of Vista and 7 being perfectly compatible should be an embarrassment of journalistic integrity.

    Windows XP may not work with the new WD Green drives, but Vista and on have been perfectly comfortable with 4096 byte sectors. A lay reader may read this story and not "Read between the lines" as I have learned to do here. Their take away may be that Microsoft operating systems are broken in some way (which they are in a lot of ways), but not this one!

    • by SuperBanana (662181) on Sunday February 14, 2010 @02:12PM (#31135668)

      should be an embarrassment of journalistic integrity.

      Slashvertisements, basic English grammar and spelling problems, completely wrong summaries and titles...

      ...and you a)think that Slashdot is "journalism" and b)it's had integrity to lose in the first place?

      I like Slashdot, but gimme a break...it's a user-driven blog which directs readers to existing stories (now often lagging behind the major news wires) with good categorization and semi-sophisticated commenting system, utilized by a larger commenter population. Not much more, and definitely not journalism.

      • by JeffSh (71237)

        Yeah, I don't disagree, maybe I'm even well aware of that, but if I had admitted that in my original post I'd have no room to indict the continued problems. I think they should aspire to be better even if Slashdot is everything you say it is.

      • by Blakey Rat (99501) on Sunday February 14, 2010 @03:21PM (#31136092)

        I'm with you, but on the other hand that doesn't mean they should just not give a shit about the quality of their end-product. We know from experience that they can edit and correct stories as corrections arise in the comments, but how often does that happen in practice? (Hardly ever.) Somewhere between a third and half of the stories posted here are either outright lies, or extremely misleading-- I may be exaggerating, but not by much-- and almost never are they corrected.

        Look, any site that posts this article: http://tech.slashdot.org/article.pl?sid=09/02/16/2259257 [slashdot.org] without a single correct simply Does. Not. Give. A. Shit.

        I don't think anybody's expecting the New York Times when they visit here, but some minimum level of competence would be nice. I don't fault anybody for complaining.

    • by rubycodez (864176)

      nonsense, I guessed (correctly it turns out) from the description that Xp and older versions of windows would have problem. But those of us who keep older computer around for windows, with no interest in going beyond Xp, aren't fretting.

      You have an imagined stereotype that isn't true. Here's my stereotyping, Less than 0.1% of readers of slashdot would be "lay readers" in matters of computers so you needn't worry.

    • Re: (Score:2, Flamebait)

      by hduff (570443)

      Dear Slashdot,

      Nothing in this news story is inaccurate, but to make it a point to say that Windows XP is incompatible with no mention of Vista and 7 being perfectly compatible should be an embarrassment of journalistic integrity.

      You are correct. It is a non-issue because nobody uses WindowsXP anymore and there are no legacy systems running it. Nor will there ever be a need to use a new drive in a WindowsXP stsem since there are no WindowsXP systems in use. You are correct.

    • Re: (Score:3, Insightful)

      by Vellmont (569020)


      but to make it a point to say that Windows XP is incompatible with no mention of Vista and 7 being perfectly compatible should be an embarrassment of journalistic integrity.
      .
      .
      Their take away may be that Microsoft operating systems are broken in some way (which they are in a lot of ways), but not this one!

      It only takes about 3 brain cells to realize that Windows XP != All Microsoft Operating Systems. Even the average person has more than 3 brain cells.

      For those people with less than 3 brain cells, S

    • by migla (1099771)

      When the summary explicitly mentions only XP, then obviously all others after that are fine.

      Sure, if this was "Gramps weekly Gramps-thing" papyrus gazette, that for some reason had a story about these new drives, then yes, a clarification that Vista and so forth work ok (and an explanation about what the heck a hard drive is in the first place) would be in order.

  • by Sits (117492) on Sunday February 14, 2010 @02:25PM (#31135762) Homepage Journal

    There is an excellent thread talking about how recent (2.6.31+) linux kernels try to report the underlying hard drive architecture [gmane.org] (found via the OSNews comments [osnews.com]). Alas, it looks like some of these drives are not reporting this data correctly and thus automatic adjustment (at partitioning time) is not taking place. It looks like in the future rather than trying to do detection by reported capability fdisk (and hopefully gparted) will default to sectors of 1MiB if the topology can't be found by default [gmane.org] (unless your media is small).

    Additionally, I gather that recent Fedoras will try to adjust things like LVM to match larger sectors too [storagemojo.com]. Hopefully whatever is laying out LVM will also be fixed too.

    Coincidentally, it looks like Oracle have a very committed dev trying to make this stuff work by default...

  • by bmajik (96670) <matt@mattevans.org> on Sunday February 14, 2010 @03:09PM (#31136018) Homepage Journal

    I just got one of the 1TB 64mb WD drives that is known to be 4kb sector based.

    Here is how it shows up in dmesg:
    [ 3.420488] sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)

    and here's what hdparm -I says:
    ATA device, with non-removable media
    Model Number: WDC WD10EARS-00Y5B1
    Serial Number: WD-WCAV55227529
    Firmware Revision: 80.00A80
    Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
    Standards:
    Supported: 8 7 6 5
    Likely used: 8
    Configuration:
    Logical max current
    cylinders 16383 16383
    heads 16 16
    sectors/track 63 63
    --
    CHS current addressable sectors: 16514064
    LBA user addressable sectors: 268435455
    LBA48 user addressable sectors: 1953525168
    Logical/Physical Sector size: 512 bytes
    device size with M = 1024*1024: 953869 MBytes
    device size with M = 1000*1000: 1000204 MBytes (1000 GB)
    cache/buffer size = unknown
    Capabilities:
    LBA, IORDY(can be disabled)
    Queue depth: 32
    Standby timer values: spec'd by Standard, with device specific minimum
    R/W multiple sector transfer: Max = 16 Current = 1
    Recommended acoustic management value: 128, current value: 254
    DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
    Cycle time: min=120ns recommended=120ns
    PIO: pio0 pio1 pio2 pio3 pio4
    Cycle time: no flow control=120ns IORDY flow control=120ns
    Commands/features:
    Enabled Supported:
    * SMART feature set
    Security Mode feature set
    * Power Management feature set
    * Write cache
    * Look-ahead
    * Host Protected Area feature set
    * WRITE_BUFFER command
    * READ_B

  • DragonFly's solution (Score:5, Interesting)

    by m.dillon (147925) on Sunday February 14, 2010 @03:25PM (#31136120) Homepage

    We're adjusting our disklabel64 utility and kernel support to set the partition base offset such that it is physically aligned instead of slice-aligned, and we are using 32K alignment. That should fix the problem without having to mess around with fdisk.

    The DragonFly 64-bit disklabel structure uses 64-bit byte offsets instead of sector addressing to specify everything. It ensures things are at least sector aligned but we wanted to make disk images more portable across devices with potentially different sector sizes. The HAMMER fs uses byte-granular addressing for the same reason, 16K aligned.

    -Matt

    • by bertok (226922)

      We're adjusting our disklabel64 utility and kernel support to set the partition base offset such that it is physically aligned instead of slice-aligned, and we are using 32K alignment. That should fix the problem without having to mess around with fdisk.

      The DragonFly 64-bit disklabel structure uses 64-bit byte offsets instead of sector addressing to specify everything. It ensures things are at least sector aligned but we wanted to make disk images more portable across devices with potentially different sector sizes. The HAMMER fs uses byte-granular addressing for the same reason, 16K aligned.

      -Matt

      You should use 64K alignment at a minimum, almost all RAID and SAN volumes are 64K aligned with IO sizes of 64K minimum.

      You'll lose up to 50% performance on random IOs on any server class hardware.

      As a comparison, Windows now aligns to the nearest 1MB.

  • by Vellmont (569020) on Sunday February 14, 2010 @03:35PM (#31136190)

    The article represents one data point, for one particular way to install a drive, on one (un-named) version of Gentoo, on one particular model of a WD drive that had a bugzilla entry entered by the author all of 2 days ago. So this is supposed to be an indictment of all of Linux?

    The author even mentions that Ubuntu has an option on parted that accomplishes the task properly. I'd be much more interested in an article that talks about how the default installer handles this task rather than concentrating on one particular expert tool that does so. It's still good to know that fdisk on his un-named Gentoo distribution does the wrong thing.. but this hardly means we should fire up the klaxon and declare "Linux not fully prepared for 4096 sector hard drives!". It's certainly interesting, but I'll withhold judgment until we actually know more about the implications of this across the entire spectrum of Linux distributions and the various 4096 sector HDs.

    • by Radtoo (1646729) on Sunday February 14, 2010 @05:18PM (#31137118)
      I agree with the headlines being grossly misleading. Linux does support 4k block sizes just fine. But this is not a distro-specific issue, so you are wrong, too.
      This is simply a matter of fdisk from that version of util-linux-ng (which is clearly named in the article) trusting the hardware vendor to specify correct block sizes. The vendor did not. Thus fdisk does not end up with 4k block sizes, as happens for many programs. And only(?) parted apparently contains a workaround that detects the correct block size.

      Its not that you can't use parted on Gentoo, though, it is just that in the world of user choices that is Gentoo, not everyone will be using that program or that particular option.
      • by Vellmont (569020)


        But this is not a distro-specific issue, so you are wrong, too.

        I never made any claims about this being a distro-specific issue, or not being a distro-specific issue. The only point I'm trying to get across is the article is extraordinarily narrow in what it's actually tested.

    • by Theovon (109752) on Sunday February 14, 2010 @08:35PM (#31138896)

      I wrote the linked article.

      I completely agree that the article is narrowly focused. VERY narrow. My objective was to demonstrate a problem and point out that Linux has not FULLY adapted. I didn't say Linux devs were idiots or that it would never be ready. I was trying to express the idea that Linux [distros in general but perhaps not all] is not QUITE ready for these drives, because not all the tools have fully adapted. Some tools make no mention of any problems in their man pages. Some (like parted's defaults) are even misleading if you mistakenly think that "track aligned" is a good thing.

      And I was trying to do that in the very limited number of words I had available for a title.

      Also, WD claimed that Linux is unaffected. Some distros probably are, but this could lead people to believe that the statement is universally true, which it isn't. Thus, my over-all objective is to educate people to the fact that if they don't know what they're doing, they can get this wrong. There are lots of mistakes I've made where I wished that someone had mentioned some critical fact on a how-to (like, don't use dmraid/fakeraid for RAID1 because reads aren't load-balanced; use mdraid instead). I've filed plenty of bug reports on such issues.

      • Re: (Score:3, Insightful)

        by Vellmont (569020)

        I can't over-emphasize the importance of titles in communication, especially with complex technical subject where there's a lot of evidence presented to support a conclusion. Your title colors the rest of the article and creates expectations about what you're trying to say. When people read articles (especially on the web) they scan through them trying to find the important parts. That's been demonstrated through eye-tracking studies multiple times.

        Your title was very broad, but the evidence to support i

  • Don't partition the drive in XP - format the entire thing and don't split it apart. Get a secondary physical drive.

If God is perfect, why did He create discontinuous functions?

Working...