RE: [PATCH BlueZ 6/9] mesh: Define storage format specific read/write routines

Gix, Brian
2019-07-10T17:20:25Z

Hi Michał,

> -----Original Message-----
> From: Michał Lowas-Rzechonek [mailto:michal.lowas-rzechonek@silvair.com]
> Sent: Wednesday, July 10, 2019 12:53 AM
> To: Stotland, Inga <inga.stotland@intel.com>
> Cc: linux-bluetooth@vger.kernel.org; Gix, Brian <brian.gix@intel.com>;
> jakub.witowski@silvair.com
> Subject: Re: [PATCH BlueZ 6/9] mesh: Define storage format specific
> read/write routines
>
> On 07/09, Inga Stotland wrote:
> > This adds the following generic APIs to mesh-config.h
> > void *mesh_config_create_config(void);
> > void mesh_config_release_config(void *config);
> > void *mesh_config_get_config(const char *dir);
> > void *mesh_config_get_config_backup(const char *dir);
> > bool mesh_config_restore_backup(const char *dir);
> > bool mesh_config_save_config(const char *dir, void *cfg);
> >
> > The implementation of these API routines depends on the underlying
> > storage directory structure and can be specific to a chosen
> > configuration file format.
>
> I don't like the assumption that each node is stored in a separate file, and there
> needs to be a backup file.

I think I understand what you are saying about *How* the node data is persevered, and that the underlying storage might not be a typical file system.

We *do* need a mechanism to get to an earlier version of a Node if there is corruption detected in the most resent version (perhaps an unexpected loss of power during a write operation). That is the purpose of the current backup system. Whether this is accomplished by reading a backup file or "Rolling Back" the history on a journal (or git repo, or whatever) we do need that backup.

But we could certainly hide the mechanism of backing up (and of reverting to a backed up version).

> One of the storage formats I had in mind is a single transactional database
> (some flavor of berkeley db, or maybe even sqlite) that would hold all the
> nodes.
>