Re: "This is a bug."

Tapani Tarvainen
2015-09-11T06:19:57Z

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,