On Sat, Nov 17, 2012 at 12:33:10PM +0800, Jeff Liu wrote: > On 11/17/2012 10:02 AM, Dave Chinner wrote: > > On Fri, Nov 16, 2012 at 02:51:04PM +0800, Jeff Liu wrote: > >> Introduce a new xfs_io command: agstate. > >> > >> This command is used to get/set state for a given allocation group. > > > > xfs_io is not the place for this command. > I was also wonder why we place the agflags command on there since xfs_io is aimed > at examining the regular file I/O paths, but I can not found out a better place > while implementing it. Right. That's exactly why I'm adding the xfs_spaceman command :) > > A couple of weeks ago I started writing an xfs_spaceman module > > and an ioctl interface for exactly this purpose, I just hadn't > > got around to completing it and the kernel patch to test it so I > > hadn't posted it. Once the userspace release is out of the way, > > I'll post the patches to get xfs_spaceman into xfs_progs, and we > > can use that for this AG control from the start. > > > > The reason for this is that the AG state in future is going to > > be a lot more complex than just enabling/disabling allocation, > > and the ioctl interface I prototyped supports a lot of that > > future functionality. > Definitely, so that we can have fine-granted AG controls, that's > why I didn't chose to re-base/post the previous agflags patch but > proposed the agstate command because the naming would sounds more > reasonable. *nod* > > > > The patch is below so you can see what sort of AG control/state > > functionality I think we'll be needing sooner rather than later, > > and the interface I think we should be using... > Ok, I'll waiting for this feature. :) > > BTW, Does it sounds make sense if we implement parent pointer > support at first? > http://www.xfs.org/index.php/Unfinished_work#Parent_Pointers.2FCreate.2BEA > I propose this because it would reduce many efforts for > implementing xfs_shrinkfs command, and reduce the overhead for > iterating overall file systems to find out files which are located > at offline AGs. That does need to be completed, though it's more of an optimisation for the shrink process than absolutely necessary functionality. Similarly for the rmap allocation btree (tracks used space and it's owner) that I'm also working on. Being able to walk the used space in an AG directly and immediately resolve the owner without a directory tree walk or inode scan will make things ever faster.... Hence I think just having shrink dumb and slow as a first step is just fine and speed can wait until we have all the necessary infrastructure in place. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
