From: David Chinner <dgc@sgi.com>
To: Neil Brown <neilb@suse.de>
Cc: David Chinner <dgc@sgi.com>, Raz <raziebe@gmail.com>,
xfs-oss <xfs@oss.sgi.com>
Subject: Re: raid50 and 9TB volumes
Date: Tue, 17 Jul 2007 10:58:54 +1000 [thread overview]
Message-ID: <20070717005854.GL31489@sgi.com> (raw)
In-Reply-To: <18076.4940.845633.149160@notabene.brown>
On Tue, Jul 17, 2007 at 10:54:36AM +1000, Neil Brown wrote:
> On Tuesday July 17, dgc@sgi.com wrote:
> > On Tue, Jul 17, 2007 at 09:56:25AM +1000, Neil Brown wrote:
> > > On Tuesday July 17, dgc@sgi.com wrote:
> > > > On Mon, Jul 16, 2007 at 04:53:22PM +0300, Raz wrote:
> > > > >
> > > > > Well you are right. /proc/partitions says:
> > > > > ....
> > > > > 8 241 488384001 sdp1
> > > > > 9 1 3404964864 md1
> > > > > 9 2 3418684416 md2
> > > > > 9 3 6823647232 md3
> > > > >
> > > > > while xfs formats md3 as 9 TB.
> ..
> > >
> > > If XFS is given a 6.8TB devices and formats it as 9TB, then I would be
> > > looking at mkfs.xfs(??).
> >
> > mkfs.xfs tries to read the last block of the device that it is given
> > and proceeds only if that read is successful. IOWs, mkfs.xfs has been
> > told the size of the device is 9TB, it's successfully read from offset
> > 9TB, so the device must be at least 9TB.
>
> Odd.
> Given that the drives are 490GB, and there are 8 in a raid5 array,
> the raid5 arrays are really under 3.5GB. And two of them is less than
> 7GB. So there definitely are not 9TB worth of bytes..
>
> mkfs.xfs uses the BLKGETSIZE64 ioctl which returns
> bdev->bi_inode->i_size, where as /proc/partitions uses get_capacity
> which uses disk->capacity, so there is some room for them to return
> different values... Except that on open, it calls
> bd_set_size(bdev, (loff_t)get_capacity(disk)<<9);
> which makes sure the two have the same value.
>
> I cannot see where the size difference comes from.
> What does
> /sbin/blockdev --getsize64
> report for each of the different devices, as compared to what
> /proc/partitions reports?
And add to that the output of `xfs_growfs -n <mntpt>` so we can
see what XFS really thinks the size of the filesystem is.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
next prev parent reply other threads:[~2007-07-17 0:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-16 12:42 raid50 and 9TB volumes Raz
2007-07-16 13:01 ` David Chinner
2007-07-16 13:57 ` Raz
2007-07-16 15:24 ` Eric Sandeen
[not found] ` <5d96567b0707160653m5951fac9v5a56bb4c92174d63@mail.gmail.com>
2007-07-16 22:18 ` David Chinner
2007-07-16 23:56 ` Neil Brown
2007-07-17 0:12 ` David Chinner
2007-07-17 0:54 ` Neil Brown
2007-07-17 0:58 ` David Chinner [this message]
2007-07-23 6:09 ` Raz
2007-07-24 1:01 ` David Chinner
2007-08-07 9:20 ` Raz
2007-09-03 14:24 ` Raz
2007-09-03 18:55 ` Christian Kujau
2007-09-04 2:50 ` Eric Sandeen
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=20070717005854.GL31489@sgi.com \
--to=dgc@sgi.com \
--cc=neilb@suse.de \
--cc=raziebe@gmail.com \
--cc=xfs@oss.sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.