On 11 June 2012 17:57, Ted Ts'o [off-list ref] wrote:

On Mon, Jun 11, 2012 at 02:41:31PM +0300, Artem Bityutskiy wrote:

quoted

Word "context" is very generic and it is widely used various things, and
I believe we should try to avoid overloading this term and obfuscating
the I/O stack with various functions and other identifiers like
"get_context()". This would hurt readability. It is fine to use it
withing the UFS-specific code, but not globally withing the kernel code.

I do not really have good name candidates, but even "ufscontext" is
already better than just "context". Or "iocontext" ? Or just "ufsdata" ?

Before we try naming it, can we get some more details about exactly
how context in the eMMC context works?

It appears to be a way of grouping related writes together (yes?) but
at what granularity?  What are the restrictions at the device level?

Yes, the idea is to group the read, write requests for a file to a
common context so that MMC can optimize the performance.

There is no restriction on the number of blocks which can be added in
the context. However, MMC restricts the number of contexts to 15. So,
potentially, multiple file system contexts will map to single MMC
context.

The proof-of-concept patches seem to use the inode number as a way of
trying to group related writes, but what about at a larger level than
that?  For example, if we install a RPM or deb package where all of
the files will likely be replaced together, should that be given the
same context?

In this patch, context is used at file level based on inode number.
So, in the above example, multiple contexts will be used for the
directory, file updates during RPM installation.

How likely does it have to be that related blocks written under the
same context must be deleted at the same time for this concept to be
helpful?

There is no restriction that related blocks within the MMC context
needs to be deleted together

If we have a context where it is the context assumption does
not hold (example: a database where you have a random access
read/write pattern with blocks updated in place) how harm will it be
to the device format if those blocks are written under the same
context?

MMC context allows the data blocks to be overwritten or randomly accessed

The next set of questions we need to ask is how generalizable is this
concept to devices that might be more sophisticated than simple eMMC
devices.  If we're going to expose something all the way out to the
file system layer, it would be nice if it worked on more than just
low-end flash devices, but also on more sophisticated devices as well.

This context mechanism will be used on both UFS and MMC devices. If
there are some alternate suggestions on what can be used as context
from file system perspective, then please  suggest.

Regards,

                                       - Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html