sunxfancy / whefs

Automatically exported from code.google.com/p/whefs
Other
0 stars 0 forks source link

RFC: ability to store key/value pair metadata for a given EFS #21

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Something like:

int whefs_fs_meta_set( whefs_fs *, char const * key, char const * val );

this could be used to add, e.g., publisher or license info. The problem is 
we'd need a set size for the records. Another idea would be to store the 
data in inode 0, but that would require that some (much) other code handle 
that special case. We could also reserve the last inode for this purpose, 
but then we (or the user) also needs to reserve a data space for this.

i've been working on a whio_dev-based btree, which we could use on top of a 
pseudofile to store this data. It's basically working but the way it saves 
its records is way too low-level, as it writes the blocks directly to the 
device without any sort of encoding. That means a little-endian-written 
version can't be read by a big-end efs. That would be bad. If i can get 
that fixed (the code its based on is hard to follow and change, as it's so 
low-level), i could use that to trivially add a user-managed btree of 
key/val pairs.

But until then... just another feature to think about.

Original issue reported on code.google.com by sgbeal@googlemail.com on 1 Dec 2009 at 9:54

GoogleCodeExporter commented 8 years ago
i'm not going to pursue this for the time being, but it's something to consider 
for 
after the whio_epfs refactoring.

Original comment by sgbeal@googlemail.com on 16 Feb 2010 at 2:19