On Friday 15 June 2012, Andreas Dilger wrote:

quoted

Oh, that's cool.  And I don't think that's hard to do.  We could just
keep a flag in the in-core inode indicating whether it is in "large
unit" mode.  If it is in large unit mode, we can make the fs writeback
function make sure that we adhere to the restrictions of the large
unit mode, and if at any point we need to do something that might
violate the constraints, the file system would simply close the
context.

This is very similar to what was implemented in mballoc preallocation.
Large files will get their own preallocation context, while small files
would share a context (i.e. an 8MB extent) and be packed densely into
this extent to avoid seeking.  It wouldn't be unreasonable to just give
each mballoc context a different eMMC context.

My understanding is that once we do that, we have already won much more
than we can by using contexts, because we get perfect write patterns.
The only thing that contexts would still buy us is that the device has
more freedom to cache things separately in each context if we write
with less than superpage alignment.

Is the mballoc algorithm you describe something that is already implemented
with the semantics you describe, or is there something we need to change
still, e.g. making sure that all allocations are aligned to the stripe-width?

	Arnd