linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: xfs <linux-xfs@vger.kernel.org>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Shameless plug for the FS Track at LPC next week!
Date: Wed, 15 Sep 2021 18:39:16 -0700	[thread overview]
Message-ID: <20210916013916.GD34899@magnolia> (raw)

Hi folks!

The Linux Plumbers conference is next week!  The filesystems mini
conference is next Tuesday, 21 September, starting at 14:00 UTC:

https://linuxplumbersconf.org/event/11/sessions/111/#20210921

(it's the light green column second from the right)

As most of you are probably aware, LSFMM has been cancelled for a second
year in a row, which leaves LPC as the only developer focused gathering
this year.  This year's conference is virtual, like last year.  If you'd
like to participate, it's not too late to register ($50 USD):

https://linuxplumbersconf.org/event/11/page/112-attend

---

The first session will be run by Matthew Wilcox, who will say something
about the ongoing folio work, assuming Linus isn't going to pull it for
5.15.  We'll see where things are in a week.

Christian Brauner will run the second session, discussing what idmapped
filesystem mounts are for and the current status of supporting more
filesystems.

---

Next up will be a session run by me about both of the atomic file write
features that have been variously proposed and asked for by various
enterprisey users.  The first proposal refers to direct atomic file
writes to storage hardware.  I /think/ this mostly involves enabling the
relevant plumbing in the block layer and then wiring up iomap/xfs to use
it.  Possibly also a new pwritev2 flag or file mode or something.

(Christoph did this in 2019: https://lwn.net/Articles/789600/ )

The /other/ atomic file write feature, of course, is my longstanding RFC
to add a VFS call that enables atomic swapping of file contents, which
enables a program to reflink a file's contents to an O_TMPFILE file,
write some changes to the tempfile, and then swap /all/ the changed
blocks back to the original file.  This call would be durable even if
the system goes down.  The feature is actually the brainchild of the
online filesystem repair effort, but I figured it wasn't so hard to
extend a tendril to userspace to make it more generally useful.

https://lwn.net/Articles/818977/
https://lore.kernel.org/linux-fsdevel/161723932606.3149451.12366114306150243052.stgit@magnolia/

---

Allison will be running the fourth session about our current progress
towards enabling sysadmins to shrink filesystems, and what pieces we're
going to need to clear space from the end of the filesystem and then
reduce the size.  FWIW Dave has been working on an inode relocation
("reno") tool, and I've been working on a free space defragmenter that
kind of barely works.  Originally this was a XFS-focused discussion, but
it seems that Andreas still remembers the last time someone tried to add
it to ext4.

---

Session #4 discusses the proliferation of cloud storage technologies and
the new failure modes that Ted and I have observed with these devices.
I think Ted had a few things to say about cloud devices, and due to the
repeated requests I think it would be worth polling the audience to find
out if they'd like filesystems to be more resilient (when possible) in
the face of not-totally-reliable storage.  Obviously everyone wants that
as a broad goal, but what should we pitch?  Metadata IO retries?
Restoring lost information from a mirror?  Online repair?

---

The final session will be a presentation about the XFS roadmap for 2022.
I'll start with a recap of the new features from last year's LTS that
have been maturing this year, and which pieces have landed for this
year's LTS kernel.

I /hope/ that this will attract a conversation between (x)fs developers
and real application developers about what features could be coming down
the pipeline and what features would they most be interested in.

---

To all the XFS developers: it has been a very long time since I've seen
all your faces!  I would love to have a developer BOF of some kind to
see you all again, and to introduce Catherine Hoang (our newest
addition) to the group.

If nobody else shows up to the roadmap we could do it there, but I'd
like to have /some/ kind of venue for everyone who don't find the
timeslots convenient (i.e. Dave and Chandan).  This doesn't have to take
a long time -- even a 15 minute meet and greet to help everyone
(re)associate names with faces would go a long way towards feeling
normal(ish) again. ;)

--D

             reply	other threads:[~2021-09-16  1:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16  1:39 Darrick J. Wong [this message]
2021-09-16 12:08 ` [External] : Shameless plug for the FS Track at LPC next week! Chandan Babu R
2021-09-17 22:11   ` Dave Chinner
2021-09-17 23:50     ` Darrick J. Wong
2021-09-18 15:21       ` James Bottomley
2021-09-17  8:30 ` Jan Kara
2021-09-17  8:36   ` Jan Kara
2021-09-17  9:38     ` Jan Kara
2021-09-17 10:23       ` Amir Goldstein
2021-09-17 16:12         ` Darrick J. Wong
2021-09-17 23:15           ` Dave Chinner
2021-09-18  7:44             ` Alternative project ids and quotas semantics (Was: Shameless plug for the FS Track at LPC next week!) Amir Goldstein
2021-09-23  0:38               ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210916013916.GD34899@magnolia \
    --to=djwong@kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).