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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
