Thread (7 messages) 7 messages, 3 authors, 2015-06-24

Re: [PATCH 02/15] libnvdimm: infrastructure for btt devices

From: Dan Williams <hidden>
Date: 2015-06-23 20:33:44
Also in: linux-fsdevel, lkml, nvdimm

On Tue, Jun 23, 2015 at 8:19 AM, Dan Williams [off-list ref] wrote:
On Tue, Jun 23, 2015 at 3:19 AM, Christoph Hellwig [off-list ref] wrote:
quoted
On Mon, Jun 22, 2015 at 12:02:54PM -0700, Dan Williams wrote:
quoted
I don't see the need to re-invent partitioning which is the path this
requested rework is putting us on...

However, when the need arises for smaller granularity BTT we can have
the partition fight then.  To be clear, I believe that need is already
here today, but I'm not in a position to push that agenda at this late
date.

Instead of all this complaining and moaning let's figure out what
architecture you'd actually want.  The one I had in mind is:

+------------------------------+
|  block layer (& partitions)  |
+---------------+--------------+--------------------+
|  pmem driver  |  btt driver  |  other consumers   |
+---------------+--------------+--------------------+
|        pmem API through libnvdimm                 |
+---------------------------------------------------+
I've got this mostly coded up.  The nice property is that BTTs now
become another flavor of the same namespace.
This approach has grown on me since yesterday.  I neglected to realize
that we can carve out a BLK-mode namespace to be a BTT enabled log
device if the need arises to satisfy what BTT on a partition was doing
previously.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help