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 >> 2.6.37.6,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 >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=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 ?. Regards Kamal _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
