On Thu, Jan 5, 2017 at 1:13 PM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote:
> On Thu, Jan 05, 2017 at 12:58:23PM -0600, Eric Sandeen wrote:
>> On 1/5/17 12:02 PM, Xingbo Wu wrote:
>> > /dev/sdf is a 3TB hard drive.
>> > It has 2930266584 blocks, as reported in `badblocks -wsv /dev/sdf`:
>> > Checking for bad blocks in read-write mode
>> > From block 0 to 2930266583
>>
>> 2930266583 x 1024 == 3000592980992
>>
>> I'd rather see what /proc/partitions and/or blockdev says about it...
>
> From the badblocks manpage,
>
> "-b block_size: Specify the size of blocks in bytes. The default is 1024."
>
> (So far so good.)
>
>> > However mkfs.xfs reports a larger block count:
>> > `sudo mkfs.xfs /dev/sdf`:
>> > meta-data=/dev/sdf isize=512 agcount=4, agsize=183141662 blks
>> > = sectsz=4096 attr=2, projid32bit=1
>> > = crc=1 finobt=1, sparse=0, rmapbt=0
>> > data = bsize=4096 blocks=732566646, imaxpct=5
>> > = sunit=0 swidth=0 blks
>> > naming =version 2 bsize=4096 ascii-ci=0 ftype=1
>> > log =internal log bsize=4096 blocks=357698, version=2
>> > = sectsz=4096 sunit=1 blks, lazy-count=1
>> > realtime =none extsz=4096 blocks=0, rtextents=0
>>
>> 732566646 x 4k blocks == 3000592982016 bytes
>>
>> Ok, that is 1024 bytes bigger. But the weird thing is that
>> mkfs.xfs actually writes the last block, and fails if that fails.
>>
>> So let's start with what /proc/partitions says, as well as
>>
>> # blkdev --getsize --getsize64 /dev/sdf
>>
>> -Eric
>>
>> > It later leads to IO error:
>> > `dmesg`:
>> > [1807875.741674] blk_update_request: I/O error, dev sdf, sector 2930266664
>> > [1807875.741732] blk_update_request: I/O error, dev sdf, sector 2930266664
>
> The kernel complains about "sector 2930266664", which is in 512-byte blocks.
>
> 2930266664 * 512 = 1500296531968, or halfway across your 3TB disk.
>
> Makes sense since the log generally ends up halfway across the disk.
> Not sure if there's any output before 1807875.741674 but this sort of
> looks like a disk error or something?
>
I grepped "sdf" from dmesg:
[ 7.158847] sd 0:0:6:0: [sdf] 5860533168 512-byte logical blocks:
(3.00 TB/2.73 TiB)
[ 7.158851] sd 0:0:6:0: [sdf] 4096-byte physical blocks
[ 7.259937] sd 0:0:6:0: [sdf] Write Protect is off
[ 7.259943] sd 0:0:6:0: [sdf] Mode Sense: 9b 00 10 08
[ 7.282316] sd 0:0:6:0: [sdf] Write cache: enabled, read cache:
enabled, supports DPO and FUA
[ 7.418959] sd 0:0:6:0: [sdf] Attached SCSI disk
[1807850.471959] XFS (sdf): Mounting V5 Filesystem
[1807850.605057] XFS (sdf): Ending clean mount
[1807875.741657] sd 0:0:6:0: [sdf] tag#0 UNKNOWN(0x2003) Result:
hostbyte=0x07 driverbyte=0x00
[1807875.741670] sd 0:0:6:0: [sdf] tag#0 CDB: opcode=0x8a 8a 08 00 00
00 00 ae a8 52 28 00 00 00 08 00 00
[1807875.741674] blk_update_request: I/O error, dev sdf, sector 2930266664
[1807875.741732] blk_update_request: I/O error, dev sdf, sector 2930266664
[1807875.742306] XFS (sdf): metadata I/O error: block 0xaea85228
("xlog_iodone") error 5 numblks 64
[1807875.742369] XFS (sdf): xfs_do_force_shutdown(0x2) called from
line 1200 of file fs/xfs/xfs_log.c. Return address =
0xffffffffa024090c
Earlier I tried to format the disk with ext4. It also had similar
errors. I thought it was the disk's problem. Would that be something
wrong with mkfs' math? I will try ext4 again and let you know if I
found something relevant.
--
Regards,
Wu, Xingbo (吴兴博) <wuxb45@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
