On Wed, Jun 13, 2012 at 07:44:35PM +0000, Arnd Bergmann wrote: > > I think using the inode number is a reasonable fit. Using the > inode number of the parent directory might be more appropriate > but it breaks with hard links and cross-directory renames (we > must not use the same LBA with conflicting context numbers, > or flush the old context inbetween). I think the inode number of the parent directory by itself is actually *not* a good idea, because there are plenty of cases where files in the same directory do not have the same life time. For example, consider your openoffice files in ~/Documents, for example. Or worse, the files in ~/Downloads written by your web browser. It might be worth considering the hueristic of a series of files written by a single process close together in time as belonging to a single context. That still might not be quite right in the case of a git checkout for example, most of the time I think that hueristic would be quite valid. One thing that *would* be worth consider when trying to decide the right granularity for a context would be the size of the erase block. If the erase block is 2 megs, and we are writing a lot of 8 meg files, a per-inode context granularity probably makes a lot of sense. OTOH, if the erase block size is 8mb, and we are writing a whole bunch of small files, we probably want to use a much more aggressive way of aggregating relating blocks than just "inodes" that average in size of say, 32k or 128k. Getting this information may requiring leaning rather hard on the eMMC manufacturers, since they (irrationally, in my opinion) think this should be trade secret information. :-( - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
