On Thu, 24 Sep 2020, Mikulas Patocka wrote:
> On Tue, 22 Sep 2020, Matthew Wilcox wrote:
>
> > > There is a small window when renamed inode is neither in source nor in
> > > target directory. Fsck will reclaim such inode and add it to lost+found -
> > > just like on EXT2.
> >
> > ... ouch.
On Tue, 22 Sep 2020, Matthew Wilcox wrote:
> > > The NVFS indirect block tree has a fan-out of 16,
> >
> > No. The top level in the inode contains 16 blocks (11 direct and 5
> > indirect). And each indirect block can have 512 pointers (4096/8). You can
> > format the device with larger
On Wed, 23 Sep 2020, Dave Chinner wrote:
> > > dir-test /mnt/test/linux-2.6 63000 1048576
> > > nvfs 6.6s
> > > ext4 dax 8.4s
> > > xfs dax 12.2s
> > >
> > >
> > > dir-test /mnt/test/linux-2.6 63000 1048576 link
> > > nvfs 4.7s
> > > ext4 dax 5.6s
> > >
On Wed, Sep 23, 2020 at 09:11:43AM -0400, Mikulas Patocka wrote:
> I also don't know how to implement journling on persistent memory :) On
> EXT4 or XFS you can pin dirty buffers in memory until the journal is
> flushed. This is obviously impossible on persistent memory. So, I'm
> considering
On Wed, 23 Sep 2020, Jan Kara wrote:
> On Tue 22-09-20 12:46:05, Mikulas Patocka wrote:
> > > mapping 2^21 blocks requires a 5 level indirect tree. Which one if going
> > > to be faster to truncate away - a single record or 2 million individual
> > > blocks?
> > >
> > > IOWs, we can take
On Tue 22-09-20 12:46:05, Mikulas Patocka wrote:
> > mapping 2^21 blocks requires a 5 level indirect tree. Which one if going
> > to be faster to truncate away - a single record or 2 million individual
> > blocks?
> >
> > IOWs, we can take afford to take an extra cacheline miss or two on a
> >
On Tue, Sep 22, 2020 at 12:46:05PM -0400, Mikulas Patocka wrote:
> Thanks for reviewing NVFS.
Not a review - I've just had a cursory look and not looked any
deeper after I'd noticed various red flags...
> On Tue, 22 Sep 2020, Dave Chinner wrote:
> > IOWs, extent based trees were chosen because
On Tue, Sep 22, 2020 at 12:46:05PM -0400, Mikulas Patocka wrote:
> I agree that the b+tree were a good choice for XFS.
>
> In RAM-based maps, red-black trees or avl trees are used often. In
> disk-based maps, btrees or b+trees are used. That's because in RAM, you
> are optimizing for the number
Hi
Thanks for reviewing NVFS.
On Tue, 22 Sep 2020, Dave Chinner wrote:
> Hi Mikulas,
>
> I'll say up front that I think you're barking up the wrong tree
> trying to knock down XFS and ext4 to justify NVFS. NVFS will stand
> or fall on it's own merits, not on how you think it's better than
>
On Tue, 22 Sep 2020, Matthew Wilcox wrote:
> On Mon, Sep 21, 2020 at 12:20:42PM -0400, Mikulas Patocka wrote:
> > The same for directories - NVFS hashes the file name and uses radix-tree
> > to locate a directory page where the directory entry is located. XFS
> > b+trees would result in much
On Mon, Sep 21, 2020 at 12:20:42PM -0400, Mikulas Patocka wrote:
> The same for directories - NVFS hashes the file name and uses radix-tree
> to locate a directory page where the directory entry is located. XFS
> b+trees would result in much more accesses than the radix-tree.
What? Radix trees
Hi Mikulas,
I'll say up front that I think you're barking up the wrong tree
trying to knock down XFS and ext4 to justify NVFS. NVFS will stand
or fall on it's own merits, not on how you think it's better than
other filesystems...
I have some fundamental concerns about the NVFS integrity model,
On Wed, 16 Sep 2020, Mikulas Patocka wrote:
>
>
> On Wed, 16 Sep 2020, Dan Williams wrote:
>
> > On Wed, Sep 16, 2020 at 10:24 AM Mikulas Patocka
> > wrote:
> > >
> > > > My first question about nvfs is how it compares to a daxfs with
> > > > executables and other binaries configured to
13 matches
Mail list logo
