On Sun, Jan 24, 2010 at 12:14 AM, Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: >> Do I have some cut down version WD EARS series drive? > > Well, despite the Advanced Format sticker you have a drive formatted > with 512-byte logical and physical blocks. > > The LBA count is 2930277168 which is the correct number for a 1.5TB > drive (in accordance with the IDEMA LBA spec). > > So "cut down" isn't the term I'd use. I'd say you have a drive with the > right capacity which doesn't suffer from any alignment and > read-modify-write cycle issues. That's a good thing in my book. Enjoy! Well, I was counting on getting higher reliability from the new ECC fields layout: http://www.anandtech.com/storage/showdoc.aspx?i=3691 "From a numbers perspective, Western Digital estimates that the use of 4K sectors will give them an immediate 7%-11% increase in format efficiency. ECC burst error correction stands to improve by 50%, and the overall error rate capability improves by 2 orders of magnitude. In theory these reliability benefits should immediately apply to all 4K sector drives (making the Advanced Format drives more reliable than regular drives)" So I'm a bit disappointed. The Anandtech article also advised how to identify the advanced format drives on the market, on which I've based my purchasing decision: "So what are the first Advanced Format drives and when are they due? The first drives will be Caviar Green drives using multiple 500GB platters – so the 1TB, 1.5TB, and 2TB Caviar Green. These drives will be shipping any day now, and can be identified through two different methods: 1) They all have 64MB of cache - the first WD Caviar Green drives to come with that much cache - and 2) They all have EARS in the drive model number, e.g. WD10EARS" My drive seems to prove their article wrong :( The alignment issues seem to really be non existent, though: Using parted, I've created a GPT partition table, then a single partition that started at sector 34 (the default with GPT). Created an EXT4 filesystem with -T largefile4 (4 kB blocks), then I ran a random read/write test using iozone with small, 1 kB record size. After that, I've deleted the partition and created another one starting at sector 40 which should leave a nice 5 * 8 * 512B = 5 * 4096B gap before the partition's start. Iozone has shown very similar results, with values differing roughly the same between different iozone runs the same filesystem and between the filesystem starting at sector 34 and at sector 40. My iozone command line used: iozone -a -i 0 -i 2 -I -N -r 1k -n 64k -g 2M -R -b /root/iozone_sdb_34s_start.xls -f /mnt/sdb1/iozone.tmp Is my methodology correct or did I do something wrong? -- Best Regards, Aleksander Adamowski http://olo.org.pl -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
