Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 10 Jul 2019 21:32:22 +0200
From:   Michal Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "Stotland, Inga" <inga.stotland@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "jakub.witowski@silvair.com" <jakub.witowski@silvair.com>
Subject: Re: [PATCH BlueZ 6/9] mesh: Define storage format specific
 read/write routines
Message-ID: <20190710193222.obsrzfjgnfmhps4e@kynes>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "Stotland, Inga" <inga.stotland@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "jakub.witowski@silvair.com" <jakub.witowski@silvair.com>
References: <20190710050959.7321-1-inga.stotland@intel.com>
 <20190710050959.7321-7-inga.stotland@intel.com>
 <20190710075245.2koao3eyj22wbj7s@mlowasrzechonek2133>
 <DEBB0CAA2616974FAE35E4B560B9A4376CBCC4E9@ORSMSX103.amr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DEBB0CAA2616974FAE35E4B560B9A4376CBCC4E9@ORSMSX103.amr.corp.intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Brian,

On 07/10, Gix, Brian wrote:
> > 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.

Precisely.

> 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.

Yes, I understand that. But, as you noticed, the rollback mechanism
doesn't need to be a backup *file*. This is an implementation detail of
a filesystem-backed JSON storage.

I would even go as far as saying that we don't need a backup - we need
atomicity and durability from ACID. Achieving that is non-trivial, but
is still an implementation detail.

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

Yes, this.

-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND