From: Eric Sandeen <sandeen@sandeen.net>
To: Matthias Schniedermeyer <ms@citd.de>
Cc: xfs@oss.sgi.com
Subject: Re: mkfs.xfs doesn't detect size of storage correctly
Date: Tue, 29 Jan 2008 14:14:50 -0600 [thread overview]
Message-ID: <479F893A.1030402@sandeen.net> (raw)
In-Reply-To: <20080129171658.GB21228@citd.de>
Matthias Schniedermeyer wrote:
> I just found a workaround. :-)
> As can be seen above the agcount is 3.
>
> For a reason that lays years in the past, when there were issues with
> the agcount (actually agsize), that to the best of my knowledge are
> fixed years ago (but still cause a weird feeling whenever i see that
> word) i just tried '-d agcount=4'
>
> #> mkfs.xfs -l size=1024b -d agcount=4 /dev/loop6 -f
> meta-data=/dev/loop6 isize=256 agcount=4, agsize=45785912 blks
> = sectsz=512 attr=2
> data = bsize=4096 blocks=183143645, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096
> log =internal log bsize=4096 blocks=32768, version=2
> = sectsz=512 sunit=0 blks, lazy-count=0
> realtime =none extsz=4096 blocks=0, rtextents=0
>
> As can be seen the "blocks"-number is much higher.
>
> #> df -k /mnt
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/loop6 732570484 4256 732566228 1% /mnt
>
> matches(tm) with the loop-size.
>
Ohh.. um... Barry? problems :)
[root@magnesium tmp]# mkfs.xfs -dfile,name=xfsfile,size=750156369920
meta-data=xfsfile isize=256 agcount=3, agsize=45785911
blks
= sectsz=512 attr=2
data = bsize=4096 blocks=137357733, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=32768, version=2
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0
[root@magnesium tmp]# bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
137357733*4096
562617274368
ouch... that's, um, not the right size :)
-Eric
next prev parent reply other threads:[~2008-01-29 20:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 9:32 mkfs.xfs doesn't detect size of storage correctly Matthias Schniedermeyer
2008-01-29 10:15 ` nscott
2008-01-29 12:20 ` Matthias Schniedermeyer
2008-01-29 15:19 ` Eric Sandeen
2008-01-29 15:33 ` Matthias Schniedermeyer
2008-01-29 15:42 ` Eric Sandeen
2008-01-29 16:58 ` Matthias Schniedermeyer
2008-01-29 17:16 ` Matthias Schniedermeyer
2008-01-29 20:14 ` Eric Sandeen [this message]
[not found] ` <20080129203731.GA29094@puku.stupidest.org>
2008-01-29 21:21 ` Eric Sandeen
2008-01-30 23:26 ` Matthias Schniedermeyer
2008-01-31 3:17 ` Eric Sandeen
2008-02-05 14:53 ` Eric Sandeen
2008-02-05 15:33 ` Matthias Schniedermeyer
2008-02-05 21:12 ` Mark Goodwin
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=479F893A.1030402@sandeen.net \
--to=sandeen@sandeen.net \
--cc=ms@citd.de \
--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.