Linux XFS filesystem development
 help / color / mirror / Atom feed
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

  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