From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Phillips Subject: Re: [RFC PATCH 00/14] Per-sb tracking of dirty inodes Date: Thu, 31 Jul 2014 22:32:29 -0700 Message-ID: <798d233b-463a-4e09-bb98-ce3df757cd3e@phunq.net> References: <1406844053-25982-1-git-send-email-jack@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: , OGAWA Hirofumi , Wu Fengguang To: Jan Kara Return-path: Received: from mail.phunq.net ([184.71.0.62]:57939 "EHLO starbase.phunq.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751487AbaHAFcb convert rfc822-to-8bit (ORCPT ); Fri, 1 Aug 2014 01:32:31 -0400 In-Reply-To: <1406844053-25982-1-git-send-email-jack@suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thursday, July 31, 2014 3:00:39 PM PDT, Jan Kara wrote: > Hello, > > here is my attempt to implement per superblock tracking of dirty inodes. > I have two motivations for this: > 1) I've tried to get rid of overwriting of inode's dirty time stamp during > writeback and filtering of dirty inodes by superblock makes this > significantly harder. For similar reasons also improving scalability > of inode dirty tracking is more complicated than it has to be. > 2) Filesystems like Tux3 (but to some extent also XFS) would like to > influence order in which inodes are written back. Currently this isn't > possible... ...without major hackery... > Tracking dirty inodes per superblock makes it easy to later > implement filesystem callback for writing back inodes and also possibly > allow filesystems to implement their own dirty tracking if they desire. > > The patches pass xfstests run and also some sync livelock avoidance tests Which answers the question I posted before finding your RFC. > I have with 4 filesystems on 2 disks so they should be reasonably sound. > Before I go and base more work on this I'd like to hear some feedback about > whether people find this sane and workable. To us (Tux3 team) that means, apply the patches and roll up a trial API. I don't immediately see anything insane, but then I haven't spent the required time on it yet either. > After this patch set it is trivial to provide a per-sb callback > for writeback (at level of writeback_inodes()). Right. > It is also fairly easy to allow filesystem to completely override dirty > tracking (only needs some restructuring of mark_inode_dirty()). I can > write these as a proof-of-concept patches for Tux3 guys once the general > approach in this patch set is acked. Or if there are some in-tree users > (XFS?, btrfs?) I can include them in the patch set. > > Any comments welcome! You're a gentleman and a scholar. Please stay tuned for detailed feedback. Regards, Daniel