On Tue, Jun 12, 2012 at 05:51:22PM +0530, Saugata Das 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. Yes --- I was trying to explore if we should try to do better than that. For example, it would probably be a good idea (at minimum) to hash some kind of partition id into the inode number to form the context id. It's probably rare that a MMC card would be partitioned, but it might be much more common for other flash devices. I could also imagine schemes where via some fcntl, additional file descriptors could be joined to the context of another file descriptor. Or maybe we have a scheme whereby some high-level, abstract, context id's could be generated, and assigned to a group of file descriptors. A hueristic where all file creations that occur within close together in time are considered to be related might work well for the package installation case, but might break down in others. Which is why I asked the question of what is the downside if the hueristics screw up, and occasionally group together files/blocks that aren't related with respect to when they are deallocated (since that *is* what the flash devices care about, right?) - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
