On Tuesday 12 June 2012, Saugata Das wrote:

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

quoted

On Mon, Jun 11, 2012 at 02:41:31PM +0300, Artem Bityutskiy wrote:
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.

quoted

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

I don't think that is correct. The most obvious implementation in eMMC
hardware for this would be to group all data from one context to be
written into the same erase block, in order to reduce the amount
of garbage collection that needs to happen at erase time. AFAICT,
the main interest here is, as Ted is guessing correctly, to make sure
that all data which gets written into one context has roughly the
same life time before it gets erased or overwritten.

quoted

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

That is of course the defined behavior of a block device that does
not change with the use of contexts. To get the best performance,
a random-write database file would always reside in a context by itself
and not get mixed with long-lived write-once data. If we have a way
in the file system to tell whether a file is written linearly or randomly
(e.g. by looking at the O_APPEND or O_CREAT flag), it might make sense
to split the context space accordingly.

quoted

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.

One suggestion that has been made before was to base the context on
the process ID rather than the inode number, but that has many other
problems, e.g. when the same file gets written by multiple processes.

	Arnd