On Fri, Jan 21, 2005 at 07:32:29AM +0100, Andi Kleen wrote:
> Sonny Rao <sonny@xxxxxxxxxxx> writes:
> >
> > Interesting, since xfs_fsr already works online, I assume the only
> > remaining kernel function requirement is to allow locking off
> > allocation to a particular AG while the extents and metadata are moved
> > off? Then I assume there's some bookkeeping to get rid of refs to
> > that AG, which I guess might be fairly difficult ?
>
> One issue is that you cannot move inodes. The inode number contains
> the AG number, and you would need to renumber the inode which
> would be fairly intrusive and visible to user space.
Ack, this is bad. I think JFS has a similar issue where inode numbers
are related to their ag numbers (shifted to the MSBs), but IIRC JFS
ags are dynamically allocated, so maybe less of a problem there ?
> One problem used to be that XFS couldn't free any inodes. so you
> couldn't get them out of AGs. But SGI added that recently, so it may
> be more feasible now.
So you're saying one possible solution is to make copies of the inodes
in other AGs and then free them after that? Of course this is
contingent on being able to get exclusive access to all these inodes,
etc.
> However to be interesting it would need online shrink, and that will
> add lots of interesting races, because basically all operations
> would need to check for their AG going away under them. Also changing
> inode numbers in this case would be nasty.
As I don't really know the XFS code, I'm guessing there is no per-AG
lock and that "m_peraglock" is just protecting the list of AGs itself?
What about holding that lock and waiting for all transactions to
complete like in xfs_freeze ? (Apologies if I'm talking out of my ass here)
Sonny
|