rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hayley Leblanc <hleblanc@utexas.edu>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	rust-for-linux <rust-for-linux@vger.kernel.org>,
	Vijay Chidambaram <vijayc@utexas.edu>,
	Samantha Miller <samantha.a.miller123@gmail.com>,
	austin.chase.m@gmail.com
Subject: Re: Persistent memory file system development in Rust
Date: Thu, 27 Jan 2022 10:48:12 -0600	[thread overview]
Message-ID: <CAFadYX6oYC8Ncg7Ma3oO75mF3poKHB5adLBxKkDLLqt+xd64wQ@mail.gmail.com> (raw)
In-Reply-To: <CANiq72=fTTreGHn_-t1tBLKxMeCr4b0ENsHGAgWZL1OZ7sKhMA@mail.gmail.com>

Thanks Matthew and Miguel for your responses, and thank you Matthew
for fixing my email address typo :)

On Thu, Jan 27, 2022 at 3:59 AM Matthew Wilcox <willy@infradead.org> wrote:
> 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.

This makes sense. Our goal is to make an effort throughout the project
to align it with
the community's interests and the trajectory of kernel development,
such that there's a potential
for some broader interest and longer-term support. Of course, that's
easy to say about a
file system that doesn't exist yet, and I'm sure we will neither be
the first nor last academics to
try to get the Linux community excited about our own project :)

It sounds like this will require us to be very serious and very
intentional about balancing the
expectations of academic conferences with the requirements of
production systems in
the kernel. My personal research interests center mostly on crash
consistency and
one of our big goals with this project is to address data
loss/consistency issues that we've
encountered in existing PM file systems, so I hope that focus will
help us target some of
those production requirements.

On Thu, Jan 27, 2022 at 8:10 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
> For your reference: a RamFS port was posted last week. It uses the
> Rust for Linux support plus `cbindgen` to take an incremental
> approach, see:
>
>     https://lore.kernel.org/rust-for-linux/35d69719-2b02-62f2-7e2f-afa367ee684a@gmail.com/

Excellent, thank you! I'll check it out.

> > > 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.
>
> Side note: Bento is not using the Rust for Linux support (as far as I
> know / yet).

I have very limited experience with Bento, but I believe it is not. In
the interest of our goal of
keeping the project in line with the kernel, it sounds like we should
go with the existing Rust
for Linux support for now.

Thanks again for your help!

Thank you,
Hayley

  reply	other threads:[~2022-01-27 16:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAFadYX5iw4pCJ2L4s5rtvJCs8mL+tqk=5+tLVjSLOWdDeo7+MQ@mail.gmail.com>
     [not found] ` <YfHMp+zhEjrMHizL@casper.infradead.org>
2022-01-26 23:10   ` Persistent memory file system development in Rust Matthew Wilcox
2022-01-27 14:09     ` Miguel Ojeda
2022-01-27 16:48       ` Hayley Leblanc [this message]
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=CAFadYX6oYC8Ncg7Ma3oO75mF3poKHB5adLBxKkDLLqt+xd64wQ@mail.gmail.com \
    --to=hleblanc@utexas.edu \
    --cc=austin.chase.m@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=samantha.a.miller123@gmail.com \
    --cc=vijayc@utexas.edu \
    --cc=willy@infradead.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).