xfs
[Top] [All Lists]

Re: defrag xfs

To: Sonny Rao <sonny@xxxxxxxxxxx>
Subject: Re: defrag xfs
From: Andi Kleen <ak@xxxxxx>
Date: Fri, 21 Jan 2005 07:32:29 +0100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20050121054830.GA29637@kevlar.burdell.org> (Sonny Rao's message of "Fri, 21 Jan 2005 00:48:30 -0500")
References: <F62740B0EFCFC74AA6DCF52CD746242D010337FA@iu-mssg-mbx05.exchange.iu.edu> <41F07494.1060501@xfs.org> <20050121043237.GA28699@kevlar.burdell.org> <1106286413.8580.66.camel@kennedy> <20050121054830.GA29637@kevlar.burdell.org>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux)
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.

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.

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.

-Andi


<Prev in Thread] Current Thread [Next in Thread>