From: Eric Sandeen <sandeen@sandeen.net>
To: "Gamel Anton J." <anton.gamel@physik.uni-freiburg.de>, xfs@oss.sgi.com
Subject: Re: irregular mkfs.xfs results on identical HW
Date: Thu, 25 Sep 2014 16:05:55 -0500 [thread overview]
Message-ID: <542483B3.3070104@sandeen.net> (raw)
In-Reply-To: <54247484.2030808@physik.uni-freiburg.de>
On 9/25/14 3:01 PM, Gamel Anton J. wrote:
> Dear all,
>
> servers with identical disk setup (HW RAID0 H310a):
and identical xfsprogs versions? Are these linux boxes?
> Disk /dev/sda: 598.9 GB, 598879502336 bytes
> /dev/sda1 1 49152 394813439+ 82 Linux swap / Solaris
> /dev/sda2 49153 50176 8225280 83 Linux
> /dev/sda3 6399 72809 533446357+ 44 Unknown
>
> mkfs.xfs creates on 28 of them:
> meta-data=/dev/sda3 isize=256 agcount=16, agsize=8335099 blks
agcount was higher on older mkfs's...
> = sectsz=512 attr=1, projid32bit=0
attr=1? that looks ancient. The only way to override the default (2) is with
a commandline argument, unless your mkfs is so old that it has different defaults.
check your xfsprogs versions on both hosts.
-Eric
> data = bsize=4096 blocks=133361584, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0
> log =internal bsize=4096 blocks=32768, version=1
> = sectsz=512 sunit=0 blks, lazy-count=1
> realtime =none extsz=4096 blocks=0, rtextents=0
>
> but on four out of them:
> meta-data=/dev/sda3 isize=256 agcount=4, agsize=33340398 blks
> = sectsz=512 attr=2, projid32bit=0
> data = bsize=4096 blocks=133361589, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0
> log =internal bsize=4096 blocks=65117, version=2
> = sectsz=512 sunit=0 blks, lazy-count=1
> realtime =none extsz=4096 blocks=0, rtextents=0
>
> I did not find a way to add mkfs.xfs options to get the identical
> filesystem setup on all nodes, e.g.
> # mkfs.xfs -d agcount=16 -b size=4096 /dev/sda3 -f
> meta-data=/dev/sda3 isize=256 agcount=16, agsize=8335100 blks
> = sectsz=512 attr=2, projid32bit=0
> data = bsize=4096 blocks=133361589, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0
> log =internal log bsize=4096 blocks=65117, version=2
> = sectsz=512 sunit=0 blks, lazy-count=1
> realtime =none extsz=4096 blocks=0, rtextents=0
>
> The only way it worked was to dump nodeA:/dev/sda3 to nodeB:/dev/sda3
> Is there an explanation? May be I missed something ... hints?
>
> Cheers and thanks in advance
>
> Anton
>
>
>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-09-25 21:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-25 20:01 irregular mkfs.xfs results on identical HW Gamel Anton J.
2014-09-25 21:05 ` Eric Sandeen [this message]
2014-09-25 21:19 ` Dave Chinner
2014-09-29 16:47 ` Gamel Anton J.
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=542483B3.3070104@sandeen.net \
--to=sandeen@sandeen.net \
--cc=anton.gamel@physik.uni-freiburg.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox