On Thu, Feb 2, 2012 at 4:13 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> On Wed, Feb 01, 2012 at 07:44:13PM -0500, Kamal Dasu wrote:
>> Need some help understanding the state of xfs with rt subvolume
>> support on 2.6.37.
>> When using xfs rt subvolume on a harddisk partition with kernel
>> 18.104.22.168,and normal r/w/delete file operations? causes deadlock
>> like hangs .? Failure? symptoms are lockups and mount failure on reboot.
>> On further investigation it was found that one of the changes could be
>> the cause.
>> The same tests seem to pass with xfs in 2.6.31 kernel.
>> xfs: simplify xfs_trans_iget? : aa72a5cf00001d0b952c7c755be404b9118ceb2e
>> Reverting the change and forward porting to the xfs_trans_inode() seems to
>> get rid of the deadlock and mount issues .
>> Below is the change
> Please just upgrade to Linux 2.6.39 or better Linux 3.0 which is the
> long term support release. RT subvolume support has been fixed in 2.6.39
> by the following changes:
> xfs: only lock the rt bitmap inode once per allocation
> xfs: fix xfs_get_extsz_hint for a zero extent size hint
> xfs: add lockdep annotations for the rt inodes
> But in general the RT subvolume code is not regularly tested and only
> fixed when issues arise.
Thanks for quick reply and clarifying this, if upgrading the kernel is
not an option, should I be
considering backporting changes to 2.6.37, should I use the entire
2.6.39 or 3.0
xfs implementation as is of cherry pick the above three changes ?.