You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the flist format (while uses sqlite db internally) is still has the information packed with capnp which makes it very hard to build tools to work with the flist (for example, modifying)
A new format that is easily editable by other users is needed, so a normalized sql db format will work the best since sqlite support is wide spread already.
normalization of the inode information in normal tables format easy (and more efficient) to process
this will simplify the fuse implementation already
0-fs tools to build flists, using different storage backends for blobs, we will support zdb of course but other distributed object stores need to be researched
on creation of flist, the flist need to hold partitioning and replication information about where the objects are stored. it means on creation the replication/partitioning policies need to be configured
this works with the backend of choice to store the blobs in the right locations and keep this information in the db
Specifications
TBD
The text was updated successfully, but these errors were encountered:
Right now the flist format (while uses sqlite db internally) is still has the information packed with capnp which makes it very hard to build tools to work with the flist (for example, modifying)
A new format that is easily editable by other users is needed, so a normalized sql db format will work the best since sqlite support is wide spread already.
Specifications
TBD
The text was updated successfully, but these errors were encountered: