| From: |
| Jan Kara <jack@suse.cz> |
| To: |
| linux-fsdevel@vger.kernel.org |
| Subject: |
| [RFC PATCH 00/14] Per-sb tracking of dirty inodes |
| Date: |
| Fri, 1 Aug 2014 00:00:39 +0200 |
| Message-ID: |
| <1406844053-25982-1-git-send-email-jack@suse.cz> |
| Cc: |
| OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>, Wu Fengguang <fengguang.wu@intel.com>, Jan Kara <jack@suse.cz> |
| Archive‑link: | |
Article |
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. 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
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.
After this patch set it is trivial to provide a per-sb callback for writeback
(at level of writeback_inodes()). 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!
Honza
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html