From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Xingbo Wu <wuxb45@gmail.com>, linux-xfs@vger.kernel.org
Subject: Re: [BUG] xfs.mkfs recognizes wrong disk size
Date: Thu, 5 Jan 2017 11:13:16 -0800 [thread overview]
Message-ID: <20170105191316.GD17846@birch.djwong.org> (raw)
In-Reply-To: <de4f0e6b-bd01-5bf5-42f6-ca2562c564cb@sandeen.net>
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?
--D
> > [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
> > [1807875.742381] XFS (sdf): Log I/O Error Detected. Shutting down filesystem
> > [1807875.742416] XFS (sdf): xfs_log_force: error -5 returned.
> > [1807875.742426] XFS (sdf): Please umount the filesystem and rectify
> > the problem(s)
> > [1807881.868117] XFS (sdf): xfs_log_force: error -5 returned.
> > [1807910.701836] XFS (sdf): xfs_log_force: error -5 returned.
> > [1807910.701841] XFS (sdf): Unmounting Filesystem
> > [1807910.701854] XFS (sdf): xfs_log_force: error -5 returned.
> > [1807910.701866] XFS (sdf): xfs_log_force: error -5 returned.
> >
> >
> >
> > The hard drive information:
> > Model Family: Seagate Barracuda 7200.14 (AF)
> > Device Model: ST3000DM001-9YN166
> > Serial Number: W1F03GXY
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-01-05 19:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-05 18:02 [BUG] xfs.mkfs recognizes wrong disk size Xingbo Wu
2017-01-05 18:58 ` Eric Sandeen
2017-01-05 19:04 ` Xingbo Wu
2017-01-05 19:13 ` Darrick J. Wong [this message]
2017-01-05 19:19 ` Eric Sandeen
2017-01-05 20:02 ` Xingbo Wu
2017-01-05 19:58 ` Xingbo Wu
2017-01-05 20:01 ` Eric Sandeen
2017-01-05 20:21 ` Darrick J. Wong
2017-01-05 20:41 ` Xingbo Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170105191316.GD17846@birch.djwong.org \
--to=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
--cc=wuxb45@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox