From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH 1/2 linux-next] Revert "ufs: fix deadlocks introduced by sb mutex merge" Date: Wed, 17 Jun 2015 21:31:16 +0100 Message-ID: <20150617203116.GG17109__10188.4073963904$1434573206$gmane$org@ZenIV.linux.org.uk> References: <1432754131-27425-1-git-send-email-fabf@skynet.be> <20150527145735.e3d1913bc66426038d53be32@linux-foundation.org> <20150604050123.GL7232@ZenIV.linux.org.uk> <1122467636.634568.1433521621076.open-xchange@webmail.nmp.proximus.be> <20150605185018.GX7232@ZenIV.linux.org.uk> <20150605220348.GA14402@ZenIV.linux.org.uk> <20150617085715.GC1614@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20150617085715.GC1614@quack.suse.cz> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Kara Cc: Evgeniy Dushistov , Ian Campbell , Ian Jackson , xen-devel , Fabian Frederick , linux-fsdevel@vger.kernel.org, Andrew Morton , Alexey Khoroshilov , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org On Wed, Jun 17, 2015 at 10:57:15AM +0200, Jan Kara wrote: > > Joy... Folks, is anybody actively maintaining fs/ufs these days? > > Looking into the changelog there wasn't anyone seriously looking into UFS > for at least 5-6 years... Fabian did some cleanups recently but they were > mostly cosmetic. So I don't think it's really maintained. OTOH clearly > there are some users since occasionally someone comes with a bug report. > Welcome to the world where we have ~50 on disk / network filesystems :-| FWIW, I've a partial rewrite of that area (completely untested, etc.) in vfs.git#ufs; it's still in progress, but hopefully it'll be done by tomorrow. Basically, it switches the sucker to locking scheme similar to ext2 (modulo seqlock instead of rwlock for protection of block pointers, having to be more careful due to 64bit assignments not being atomic and being unable to fall back to ->truncate_mutex in case of race on the read side) and starts cleaning the hell out of the truncate (and eventually create side of get_block as well). As far as I can see, the root of the problems with that sucker is the misplaced handling of tail-packing logics. That had ballooned into a lot of convoluted codepaths ;-/ I'm not blaming Evgeniy - it *is* painful to massage into saner shape and the damn thing kept missing cleanups that were done to similar filesystems due to that... One thing I'm somewhat unhappy about in what Evgeniy had done is dealing with UFS vs. UFS2 differences at such a low level. Sure, the way we did endianness handling in there provoked exactly that, but it might have been better to go the other way round; see e.g. fs/minix/itree*.c for opposite approach. All this stuff is currently completely untested; I'll be using generic parts of xfstests for beating it up, but any assistance would be welcome. Note: all testing I'll be realistically able to do will be for FreeBSD UFS variants - I don't have Solaris left on any boxen, to start with...