From: Tapani Tarvainen <tapani.j.tarvainen@jyu.fi>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: "This is a bug."
Date: Fri, 11 Sep 2015 09:19:47 +0300 [thread overview]
Message-ID: <20150911061947.GA3398@tehanu.it.jyu.fi> (raw)
In-Reply-To: <20150910183358.GF27863@bfoster.bfoster>
On 10 Sep 14:33, Brian Foster (bfoster@redhat.com) wrote:
> > >... was the filesystem created small and then grown to a much
> > > larger size via xfs_growfs?
> >
> > Almost certainly yes, although how small it initially was I'm not
> > sure.
It actually been grown several times over the years - the system is
rather old. Indeed, all its disks have been replaced with bigger ones
without reinstallation, so the filesystem could not have been
initially created as big as it is now.
> That probably explains that then. While growfs is obviously supported,
> it's not usually a great idea to grow from something really small to
> really large like this
That's good to know - but sometimes you just can't plan
ahead far enough.
> I'd expect such a large filesystem with such small allocation groups to
> probably introduce overhead in terms of metadata usage (24k agi's,
> agf's, 2x free space btrees and 1x inode btree per AG), spending more
> time in AG selection algorithms for allocations and whatnot, increased
> fragmentation due to capping the maximum contiguous extent size,
> creating more work for userspace tools such as repair, etc., and
> probably to have other weird or non-obvious side effects that I'm not
> familiar with.
So it's likely to also make it more fragile and harder to repair in
case of a disaster like this.
So, my take from this is that
(1) The bug was real but it was just in the old version of xfs_repair
in Debian Wheezy, and even when the machine is updated to Jessie
(due soon) it's better to install latest (4.20) xfsprogs from sources
rather Jessie's packaged 3.20; and
(2) When a filesystem grows a lot it is better to recreate it
(at least every now and then if the growth is incremental)
rather than keep growing it forever.
If there's anything you'd like to add, and especially if there
is something you'd still like to debug where I could help,
please let me know.
Thank you for your help,
--
Tapani Tarvainen
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-09-11 6:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-10 9:18 "This is a bug." Tapani Tarvainen
2015-09-10 10:31 ` Tapani Tarvainen
2015-09-10 11:53 ` Emmanuel Florac
2015-09-10 12:05 ` Tapani Tarvainen
2015-09-10 11:48 ` Emmanuel Florac
2015-09-10 11:55 ` Tapani Tarvainen
2015-09-10 12:30 ` Tapani Tarvainen
2015-09-10 12:36 ` Brian Foster
2015-09-10 12:54 ` Tapani Tarvainen
2015-09-10 13:01 ` Brian Foster
2015-09-10 13:05 ` Tapani Tarvainen
2015-09-10 14:51 ` Brian Foster
2015-09-10 15:05 ` Brian Foster
2015-09-10 17:52 ` Tapani Tarvainen
2015-09-10 18:01 ` Tapani Tarvainen
2015-09-10 17:31 ` Tapani Tarvainen
2015-09-10 17:55 ` Brian Foster
2015-09-10 18:03 ` Tapani Tarvainen
2015-09-10 18:33 ` Brian Foster
2015-09-11 6:19 ` Tapani Tarvainen [this message]
2015-09-11 0:12 ` 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=20150911061947.GA3398@tehanu.it.jyu.fi \
--to=tapani.j.tarvainen@jyu.fi \
--cc=bfoster@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox