----- Forwarded message from Dave Chinner <david@fromorbit.com> -----
To: (a few filesystem lists)
Subject: Re: [PATCH v2] iomap: report collisions between directio and buffered
writes to userspace

On Mon, Nov 20, 2017 at 08:32:40PM -0800, Matthew Wilcox wrote:

On Mon, Nov 20, 2017 at 05:37:53PM -0800, Darrick J. Wong wrote:

On Tue, Nov 21, 2017 at 09:27:49AM +1100, Dave Chinner wrote:

[xa_ prefix is already taken]

FWIW, why is it named "XArray"? "X" stands for what? It still
looks like a tree structure to me, but without a design doc I'm a
bit lost to how it differs to the radix tree (apart from the API)
and why it's considered an "array".

/me nominates 'xarr' for the prefix because pirates. :P

The X stands for 'eXpandable' or 'eXtending'. I really don't want to
use more than a two-letter acronym for whatever the XArray ends up being called. One of the problems with the radix tree is that everything has
that 11-character 'radix_tree_' prefix; just replacing that with 'xa_'
makes a huge improvement to readability.

Yeah, understood. That's why
we have very little clear
prefix namespace left.... :/

[ somedays I write something that looks sorta like a haiku, and from
that point on everything just starts falling out of my brain that
way. I blame Eric for this today! :P ]

I'm open to renaming it, but I want a good name. I think it needs to
be *something* array, so we're looking for a prefix used nowhere in the kernel. Running 'git grep' in turn for '\<[a-z]a_' really only allows
for ja, ya and za. 'ja_' and 'ya_' only have one user, while 'za_'
has none. So ... anyone got a good retcon for JArray, YArray or ZArray?

A Yellow Array.
Colour is irrelevant.
The bikeshed looks nice.

It's considered an array because it behaves "as if" it's an infinite
array.

Infinite Array.
Namespace prefix collision
this haiku can't solve.

The fact that we chop it up into chunks of 64 entries, and then
arrange those chunks into a tree is not something the average user needs
to concern themselves with.

Jumbo Array. Many
pieces hidden behind walls.
Will anyone notice?

We have a lot of places in the kernel that
fuss around with "allocate N entries, whoops, we exceeded N, kmalloc some more, oh no kmalloc failed, vmalloc it instead". So the idea is to give these places an interface that acts like an automatically-resizing array.

Zoetrope Array.
Labyrinth of illusion.
Structure never ends.

Cheers,

Dave.
----- End forwarded message -----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)