On Sat, Feb 14, 2015 at 09:35:07AM +1100, Dave Chinner wrote:
> On Fri, Feb 13, 2015 at 11:14:46AM -0200, Carlos Maiolino wrote:
> > Hi folks,
> > I've been seeing a lot of users requesting a shrink feature for XFS, and I
> > believe it's time to have it implemented in XFS.
> I'm not so sure about that.
> > Is there anybody working on a shrink feature? If not, I'm going to
> > start to work on it, if nobody have any objections.
> I currently in design discussions with various other developers
> about a line of development that will make growing and shrinking XFS
> redundant operations. i.e. if we get this right, we'll never need to
> deal with capacity changes of XFS filesystems at the XFS level
> again. both grow and shrink will be instanteneous, and not require
> any modification to the layout of the filesystem at all.
Oh, I had no idea about this discussion :)
> Mind you, that's not the reason for that line of development - it's
> all about integrated snapshots in XFS. We essentially get
> grow/shrink for free with that infrastructure....
I suppose LSF will be the place for that design discussion.
> I'm not quite ready to publish the docco yet - need to get all my
> ducks in a line first - but if it does work out as a feasible line
> of development, then the old "shrink" method is essentially a dead
> However, don't let that stop you working towards shrink, because
> there is infrastructure that it requires that we need for other
> things as well. Take you pick:
> - parent pointers
> - AG state control
> - ranged bulkstat call (e.g. AG range)
> - allocation location control from userspace
> (which may tie in to AG state control)
> - Atomic inode location swaps
> But it's worth reading the entire discussion starting here because
> it start with a summary of the different approaches taken and why
> they were rejected:
Yep, I can work on that stuff, thanks for pointing me up the parent inodes
I'll try to show up with something soon.