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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140723143453.GE6754@linux.intel.com>
Date:	Wed, 23 Jul 2014 10:34:53 -0400
From:	Matthew Wilcox <willy@...ux.intel.com>
To:	Howard Chu <hyc@...as.com>
Cc:	Linux Kernel Mailing List <Linux-Kernel@...r.Kernel.ORG>
Subject: Re: [PATCH v8 00/22] Support ext4 on NV-DIMMs

On Wed, Jul 23, 2014 at 07:10:32AM -0700, Howard Chu wrote:
> Matthew Wilcox wrote:
> >One of the primary uses for NV-DIMMs is to expose them as a block device
> >and use a filesystem to store files on the NV-DIMM. While that works,
> >it currently wastes memory and CPU time buffering the files in the page
> >cache. We have support in ext2 for bypassing the page cache, but it
> >has some races which are unfixable in the current design. This series
> >of patches rewrite the underlying support, and add support for direct
> >access to ext4.
> 
> This is an awful lot of work to go thru just to get a glorified ext4
> RAMdisk. RAMdisks are one of the worst possible uses for RAM, requiring
> users to explicitly copy files to them before getting any benefit. Using RAM
> for a page cache instead brings benefits to all file accesses without
> requiring any user intervention.

Perhaps you misunderstand the problem.  There are many different kinds
of NV-DIMM out there today with different performance characteristics.
One that has been described to me has write times 1000x slower than read
times.  In that situation, you can't possibly "just use it as page cache";
you need to place the read-often; write-rarely files on that media.

> If the NVDIMM range was reserved for exclusive use of the page cache, then
> you would have an avenue to get persistence/safety for every filesystem
> mounted on a machine, not just a special case ext4.

No you wouldn't; you'd also need to have a mechanism to store the state
of the page cache persistently.  And you have to make sure that the
filesystem does appropriate cache invalidations.  By going the route
here, we can use the existing caching mechanisms (eg FS-Cache) which
have solved all the hard problems of making sure that local caches are
coherent with storage.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ