All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Hayley Leblanc <hleblanc@utexas.edu>
Cc: linux-fsdevel@vger.kernel.org, rust-for-linux@vger-kernel.org,
	Vijay Chidambaram <vijayc@utexas.edu>
Subject: Re: Persistent memory file system development in Rust
Date: Wed, 26 Jan 2022 22:35:19 +0000	[thread overview]
Message-ID: <YfHMp+zhEjrMHizL@casper.infradead.org> (raw)
In-Reply-To: <CAFadYX5iw4pCJ2L4s5rtvJCs8mL+tqk=5+tLVjSLOWdDeo7+MQ@mail.gmail.com>

On Tue, Jan 25, 2022 at 04:02:56PM -0600, Hayley Leblanc wrote:
> I'm a PhD student at UT Austin advised by Vijay Chidambaram (cc'ed).
> We are interested in building a file system for persistent memory in
> Rust, as recent research [1] has indicated that Rust's safety features
> could eliminate some classes of crash consistency bugs in PM systems.
> In doing so, we'd like to build a system that has the potential to be
> adopted beyond the research community. I have a few questions (below)
> about the direction of work in this area within the Linux community,
> and would be interested in hearing your thoughts on the general idea
> of this project as well.

Hi Hayley,

Thanks for reaching out to us.

First, my standard advice for anyone thinking of writing a Linux
filesystem: Absolutely do it; you'll learn so much, and it's a great deal
of fun.  Then my standard advice for anyone thinking about releasing a
Linux filesystem: Think very carefully about whether you want to do it.
If you're lucky, it's only about as much work as adopting a puppy.
If you're unlucky, it's like adopting a parrot; far more work and it
may outlive you.

In particular, the demands of academia (generate novel insights, write
as many papers as possible, get your PhD) are at odds with the demands
of a production filesystem (move slowly, don't break anything, DON'T
LOSE USER DATA).  You wouldn't be the first person to try to do both,
but I think you might be the first person to be successful.

There's nothing wrong with having written an academic filesystem
that you learned things from.  I think I've written three filesystems
myself that have never seen a public release -- and I'm totally fine
with that.

> 1. What is the state of PM file system development in the kernel? I
> know that there was some effort to merge NOVA [2] and nvfs [3] in the
> last few years, but neither seems to have panned out.

Correct.  I'm not aware of anything else currently under development.
I'd file both those filesystems under "Things people tried and learned
things from", although maybe there'll be a renewed push to get one
or the other merged.

> 2. What is the state of file system work, if any, on the Rust for
> Linux side of things?

I only have a toe in Rust development, but I'm not aware of
any work being done specifically for filesystems, that said ...

> 3. We're interested in using a framework called Bento [4] as the basis
> for our file system development. Is this project on Linux devs' radar?
> What are the rough chances that this work (or something similar) could
> end up in the kernel at some point?

Bento seems like a good approach (based on a 30 second scan of their
git repo).  It wasn't on my radar before, so thanks for bringing it up.
I think basing your work on Bento is a defensible choice; it might be
wrong, but the only way to find out is to try.

All this is just my opinion, and it's worth exactly what you're paying
for it.  I have no say in what gets merged and what doesn't, and I
decided academia was not for me after getting my BSc.  I hope it all
works out for you, and we end up seeing your paper(s) in FAST.

  reply	other threads:[~2022-01-26 22:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-25 22:02 Persistent memory file system development in Rust Hayley Leblanc
2022-01-26 22:35 ` Matthew Wilcox [this message]
2022-01-26 23:10   ` Matthew Wilcox
2022-01-27 14:09     ` Miguel Ojeda
2022-01-27 16:48       ` Hayley Leblanc
2022-01-27 20:07   ` Theodore Y. Ts'o

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=YfHMp+zhEjrMHizL@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=hleblanc@utexas.edu \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=rust-for-linux@vger-kernel.org \
    --cc=vijayc@utexas.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.