On Fri, Dec 24, 2010 at 06:24:38PM +0300, Michael Tokarev wrote: > 24.12.2010 16:01, Krzysztof Halasa wrote: > > Rogier Wolff <R.E.Wolff@xxxxxxxxxxxx> writes: > > > >> ata6.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 0/32) > >> scsi 5:0:0:0: Direct-Access ATA WDC WD10EARS-00Y 80.0 PQ: 0 ANSI: 5 > >> sd 2:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 > >> GiB) > > > > WD10EARS are "green" drives, 5400 rpm. They aren't designed exactly for > > speed. Never used them, though. > > Oh.. The famous EARS drives. I missed this info in the > start of the thread. > > Now, after this info, the whole thread is quite moot. No it is not. We're seeing a performance issue, about 10 fold beyond what is to be expected of unaligned accesses. > The thing is, for these WD*EARS drivers, it is _vital_ to get > proper alignment of all partitions and operations. They've > 4Kb sectors physically but report 512bytes sectors to the OS. > It is _essential_ to ensure all partitions are aligned to the > 4Kb sectors. Be it LVM, raid-something, etc - each filesystem > must start at a 4kb boundary at least, or else you'll see > _dramatic_ write speed problems. Out of four partitions on the drive, two are aligned, two are not. The two that are not are the boot partition (/boot) which never gets written to. The other one is the swap partition. (the machine has enough ram to function perfectly without swap. We only noticed a missing "mkswap" on the swap partition after it had been running without swap for weeks, while we were diagnosing the performance problems. So, apart from the fact that this was "lucky" to come out this way, it /is/ correctly configured. > So.. check the whole storage stack and ensure proper alignment > everywhere. In particular, check that your partitions are not > aligned to 63 sectors (512b), or starts at N+1 sector - the > most problematic mode for these drives. The important (used ones) ARE correctly aligned. (I surely hope that RAID5 doesn't grab the first 1k and alings everything else to (4n + 1)k ...) > No, this is about TLER. The "desktop" drives like this will try > re-read data in case of error, and if that does not work the > raid code will most likely declare the drive's dead and kick > it off the array. Drives which are supposed to work in RAID > config has configurable timeouts/retries, so that the RAID > code will be able to take care of read errors. That's WDs story. Under Linux the driver will timeout after some thirty seconds, reset the drive and retry a few times (again triggering the long retries sequence, but not letting it finish), and finally report an error. When an error is reported Linux-raid will kick the drive out of the array and work in degraded mode from then on. If you'd use a RAID drive that DOES report error quickly, you'll be on your way maybe 113 seconds quicker, but still with a degraded array. Roger. -- ** R.E.Wolff@xxxxxxxxxxxx ** http://www.BitWizard.nl/ ** +31-15-2600998 ** ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
