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 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.