Yay, I am happy about this patch (when there is a patch :)<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
<br>
> - at every create and update, a json file is created next to the object's file,</div></blockquote><div><br>I definitely think it should be in the same directory as the object file, with a related name. It might even be worth using the macintosh ._name naming convention.<br>
<br>(Note that when we have directories as bundles, bundle-level metadata can live in a ._. file. If all bundles had some kind of manifest, then any subfiles which are used separately could grow their own metadata in ._subfile ; as long as that file were not in the manifest, it would not be packed up when exporting the bundle to foreign storage.)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
><br>
> - it's also deleted along the object,<br>
><br>
> - at startup, if the file <datastore_path>/.metadata.exported doesn't<br>
> exist, check how many objects need to get their metadata exported<br>
> (0.8s for 3000 entries)<br>
<br>
</div>That's pretty good.<br>
<div class="Ih2E3d"><br>
> - in an idle callback, process each of those objects one per iteration<br>
> (3ms per entry with simplejson, 2ms with cjson).<br>
<br>
</div>Exporting a few 100 per iteration probably is more efficient ;-)</blockquote><div><br>This brings up the issue of TamTam imperfect timing - it would be great if there were some way to turn off all unnecessary background CPU use for cases like TamTam. If so, I'd say 12*3ms is about the right size for a background click every second or two.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
> In my tests this has worked quite well, but I have one concern: can<br>
> something bad happen if we have 20k files in the same dir (for a<br>
> journal with 10k entries)?<br>
<br>
</div>Ok, we can split it into a subdir (which will only have 10K files then).<br>
<br>
If there's a cost to large dirs in jfffs2 then we can use hashed dirs,<br>
and that change will be needed for both the main datastore storage<br>
_and_ the metadata files.</blockquote><div><br>+1 </div></div><br>