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 23:10:31 +0000	[thread overview]
Message-ID: <YfHU5/RrpJlRx5sO@casper.infradead.org> (raw)
In-Reply-To: <YfHMp+zhEjrMHizL@casper.infradead.org>


... This time with the correct email address for the Rust list.

On Wed, Jan 26, 2022 at 10:35:19PM +0000, Matthew Wilcox wrote:
> 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 23:10 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
2022-01-26 23:10   ` Matthew Wilcox [this message]
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=YfHU5/RrpJlRx5sO@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.