linux-kernel - Re: [RFC 00/16] NOVA: a new file system for persistent memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAELBmZAs6iAMx_0wxTnC7qrbMiQDDVG3dUtAhjeOKJ6ig2k6tQ@mail.gmail.com>
Date:   Mon, 9 Oct 2017 17:32:07 +0200
From:   Miklos Szeredi <miklos@...redi.hu>
To:     Steven Swanson <swanson@....ucsd.edu>
Cc:     linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>, linux-nvdimm@...ts.01.org,
        Steven Swanson <steven.swanson@...il.com>,
        dan.j.williams@...el.com, Steven Whitehouse <swhiteho@...hat.com>
Subject: Re: [RFC 00/16] NOVA: a new file system for persistent memory

On Thu, Aug 3, 2017 at 9:48 AM, Steven Swanson <swanson@....ucsd.edu> wrote:
> This is an RFC patch series that impements NOVA (NOn-Volatile memory
> Accelerated file system), a new file system built for PMEM.

Hi,

Thanks for posting.

I read the paper and the design looks nice.  Then I  looked at the
patches, but could not find a place to start, nor something I could
actually try out.  So let me suggest some ways to make this more
reviewer/tester friendly:

1) try starting with something very simple yet working and supporting
the final layout
   - no optimizations (one big lock, no per-cpu data, rcu, numa, etc support)
   - no support for optional features (checksumming, NFS export, etc)
   - missing mandatory features (e.g. just readdir and getattr support)
   - try and get it down to <5k lines, preferably 2-3k

2) pointer to sources and instructions for trying it out without
special hardware

3) build on this minimal working version by
   - adding mandatory features
   - then adding optimizations

4) each patch should leave the tree in a compiling and working state
but should be small and easily reviewed

5) leave optional features and unimportant optimizations for a later
submission; try to make the patchset as small as you meaningfully can
(i.e. it should be fully working and demonstrate the capabilities and
performance, but nothing more).

Thanks,
Miklos