On Friday 15 June 2012, Andreas Dilger wrote: > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
