Hi everyone,

I propose that we hold our own virtual XFS developer summit.  Physical
proximity is way too risky for the forseeable future, so let's make do
with online discussions and conferencing.  LSFMM 2020 was officially
cancelled a short time ago.

Unlike in-person events, we cannot pin everyone into a single time zone
for an extended meeting, and we can't have a hallway BOF.  On the plus
side, we can finally invite /everyone/ to the table!  Let's use this
email thread to make a list of topics for future discussions.  I can
think of a few topic categories to start:

 1. Development process problems that people would like to address.
 2. Matching patch authors with patch reviewers.
 3. Old features that we ought to retire.
 4. New feature development roadmap.
 5. Anything else that people think is important.

Once we have a list of specific topics matched with people who are
interested in that topic, I think it best to start each of those
conversations in separate threads on linux-xfs where everyone can see
them.  If the participants feel that they'd get more out of an
interactive session, we have plenty of options for doing that:

The first option of course is the IRC channel (#xfs on freenode) from
which it is easy to paste the irc logs into linux-xfs for archiving and
further public comment.

For actual video conferencing, we also have tools such as Jitsi,
BigBlueButton, BlueJeans, and Zoom.  I'm willing to sit in on video
meetings to take notes for linux-xfs and/or post the recordings online.
As a side note for anyone wanting to take advantage of videochats --
I'd prefer to keep this to one hourlong meeting per day.

Please remember this is not an edict passed on from high to shake up
everything; it is merely this maintainer suggesting that we explore
other tactics for building things together.  In the end, everything that
goes into making decisions still must be communicated via linux-xfs, and
patches still have to earn Reviewed-by tags.  We do, however, have
flexibility in how we get there.

Here are some topics that have been mentioned to me at least in passing
over the last few months.  I've included mini-summaries of the pieces
that have been a particular bugaboo for me:

 - Refactoring the Review Process (me, Eric, Dave)

Writing and reviewing code in isolation hasn't always served me well.  I
really enjoyed my experiences developing the reflink code (~2015) being
able to chat with Dave in the evenings about the design of particular
algorithms, or how certain XFS structures really worked, and to learn
the history behind this and that subsystem.

Returning to first principles, I perceive that the purpose of our review
processes is to make sure there aren't any obvious design flaws or
implementation errors in the code we put back to the git repo by
ensuring that at least one other XFS developer actually understands
what's going on.

In other words, I am interested in testing the pair programming
paradigm.  Given that we have zero physical locality, I suspect this
will work better with an interactive medium and between people who are
in nearby time zones.  I also suspect that this might be better used for
more focussed activities such as code walkthroughs and reviews.  Still,
I'm willing to entertain the possibility of using this as a second means
to get a patchset to a Reviewed-by.

I also speculate that this might be a good mentoring opportunity for us
to trade productivity tips and disseminate 'institutional' knowledge
between people.  I for one am happy to help others learn more about the
code base in exchange for learning more about the parts of XFS with
which I'm less familiar.  (I bet Allison knows more about how xattrs
work than I do at this point...)

 - Deferred inode inactivation and nonblocking inode reclaim (me, Amir)

The inactivation series (me) moves the transactional updates that happen
after a file loses its last reference (truncating attr/data forks,
freeing the inode) out of drop_inode and reclaim by moving all that work
to an intermediate workqueue; the reclaim series (Dave) removes inode
flushing from reclaim, which means that xfs stop holding up memory
reclaim on IO.

 - 64bit timestamps (me, Amir)

Redefining the timestamp fields so that we can support timestamps beyond
2038, assuming the Flying Spaghetti Monster doesn't smite us all before
then.

 - Atomic extent swaps (me)

This new series allows you to swap a range (or all of) the mappings
between two inodes forks, with log intents guaranteeing we complete all
of the swap or none of it.  That ability allows userspace to update
files atomically, and it allows online fsck to rebuild xattr/directory
structures and atomically commit the new metadata at the end.

 - Online fsck (me)

General status updates and whatnot.  I've fleshed out the bones of the
entire feature, which now include atomic attr/dir repair.  The remaining
pieces are (1) nlink verification; (2) rebuilding directories using
parent pointers; (3) parent pointers; and (4) dumping disconnected
inodes in lost+found, all of which depend on parent pointers.

 - Deprecating the v4 format (Dave)

Retiring the old v4 format, since all of the new features (reflink,
online fsck, etc) depend on v5.

 - Parent Pointers (Amir)

Inode parent pointers, so we would gain reverse mappings for the
directory structure.

 - Range Locks (Amir)

Locking ranges of a file for IO instead of the whole file.

 - DAX bashing session (Dan)

 - Widening the inode fork extent counters (Chandan)

 - Dirty buffer region bitmap tracking (Chandan)

 - Add your pet item here! :)

Thoughts, suggestions, and flames appreciated!

--D