From owner-freebsd-questions@FreeBSD.ORG Tue Feb 3 05:08:34 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31C1B106566C for ; Tue, 3 Feb 2009 05:08:34 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from sopwith.solgatos.com (pool-173-50-231-101.ptldor.fios.verizon.net [173.50.231.101]) by mx1.freebsd.org (Postfix) with ESMTP id 064098FC0C for ; Tue, 3 Feb 2009 05:08:32 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: by sopwith.solgatos.com (Postfix, from userid 66) id 67570B64F; Mon, 2 Feb 2009 20:56:53 -0800 (PST) Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id AAA14230; Tue, 3 Feb 2009 00:28:04 GMT Message-Id: <200902030028.AAA14230@sopwith.solgatos.com> To: freebsd-questions@freebsd.org Date: Mon, 02 Feb 2009 16:28:04 +0000 From: Dieter Subject: getting oddball boundary quirk reading Samsung disk X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@sopwith.solgatos.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 05:08:34 -0000 I'm attempting to dig my way out of the Seagate 7200.11 firmware disaster. Need a non-7200.11 place to store my data before messing with the drives. Trying a Samsung. disk: Samsung HD103UJ 1TB SATA controller: nforce4-ultra FreeBSD 7.0 amd64 Brand new disk. Running a few tests before entrusting data to it. I read the entire disk with dd of=/dev/null, it ran fine. I wrote the entire disk with 0x55, it ran fine. I read the entire disk with dd piped to hexdump, I get quirks at 2 oddball spots. Reading 1 sector at a time works fine. Reading 2 sectors gives i/o error. Repeatable. If there was a boundary quirk (like the one at the lba48 boundary on Seagates) I would expect an error the first time I read the disk (before writing 0x55). Read ahead is listed as supported and enabled, so the data should be in the disk's cache when reading with bs=1024. # dd if=/dev/ad6 bs=512 skip=1936787900 count=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.000160 secs (3200423 bytes/sec) 00000000 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU| * 00000200 # dd if=/dev/ad6 bs=512 skip=1936787901 count=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.000155 secs (3303821 bytes/sec) 00000000 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU| * 00000200 # dd if=/dev/ad6 bs=1024 skip=1936787900 count=1 | hexdump -C dd: /dev/ad6: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.000104 secs (0 bytes/sec) # # dd if=/dev/ad6 bs=512 skip=1939213518 count=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.000152 secs (3365962 bytes/sec) 00000000 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU| * 00000200 # dd if=/dev/ad6 bs=512 skip=1939213519 count=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.000260 secs (1970168 bytes/sec) 00000000 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU| * 00000200 # dd if=/dev/ad6 bs=1024 skip=1939213518 count=1 | hexdump -C dd: /dev/ad6: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.000101 secs (0 bytes/sec) # ad6: FAILURE - READ_DMA48 status=51 error=40 LBA=1936787980 ad6: FAILURE - READ_DMA48 status=51 error=40 LBA=1939213518 ad6: FAILURE - READ_DMA48 status=51 error=40 LBA=1939213518 Running the test again isn't generating additional errors to console/dmesg. I ran the same incoming inspection test on Seagates, including a couple of 1 TB (exact same number of sectors as the Samsung), and it ran fine.