Please unsubscribe me On Wed, Apr 1, 2015 at 9:26 PM Jonas Sicking <jo...@sicking.cc> wrote:
> On Thu, Apr 2, 2015 at 3:00 AM, ben turner (bent) > <bent.mozi...@gmail.com> wrote: > > On Wednesday, April 1, 2015 at 2:12:40 PM UTC-7, somb...@gmail.com > wrote: > >> - Crash-wise, are we talking about only the parent process crashing, or > >> are we talking about the child process crashing too? > > > > I was talking just about the parent process. If the child process > crashes then whether or not the transaction is durable depends on whether > or not the parent received the commit message and processed it (otherwise > we automatically abort any outstanding transactions). That behavior is > unchanged. > > That doesn't sound entirely right. > > As soon as the child process received the last "success" event for a > given request in a transaction, and we've sent the "go ahead and > commit" message to the parent, then I would expect that it's ok for > the child to crash at any point. This might match what you are saying. > > However the more important question that I believe Andrew is asking, > is if we receive a "commit" event, what can then crash without there > being a dataloss. My understanding is that at that point both the > child and the parent can crash. As long as the kernel doesn't panic, > or the battery runs out or is removed, the data will be written. > > I.e. once the "commit" event fires, the data has been transferred to > the OS, and as long as the OS shuts down cleanly, or has time to > flush, the data will be safe. > > >> 1. Device shutdown via the UI > > > > This should be fine, we will flush to disk before actually powering down. > > > >> 2. User pulls the battery. > >> 3. Hardware-shutdown via long-hold of the power button. > >> 4. Device runs out of power. > > > > These three cases may fail to flush the data to disk, and if so when we > restart the transaction will be rolled back. > > > >> For 3: long-power-button-hold it seems like > >> depending on how extensively things are wedged, we could notice at say 6 > >> seconds that we're headed for a shutdown and try to trigger an fsync and > >> put a stop to new transactions. > > > > That sounds reasonable, assuming we get that notification at the gecko > layer? I am not sure what kind of info we get when long-presses happen. > > I would think that when long-press happens, the CPU simply receives a > reset signal. So it's equivalent to pulling the battery and putting it > back. > > But maybe the OS is sent a signal a few seconds prior to that which > would encourage it to flush. I'm not sure. > > >> For 4: low-power, ideally there's just > >> a point that the device decides it's not safe to operate and shuts > >> itself down, and that's slightly before it would result in IndexedDB > >> badness. > > > > I don't know, but if it goes through normal shutdown then we will be > fine. > > I'm pretty sure this results in the OS getting shut down cleanly, and > so will flush any data it still holds. I.e. the data should be safe > given my answer at the top. > > >> My main question is what is a realistic risk model for power loss/crash > >> and are there mitigations we can put in place to reduce the risk to > >> users? > >> ... > >> The issue there is how long the IndexedDB window of vulnerability is. > > > > Flushing happens automatically after the database is idle (i.e. no > active transactions) for 2 seconds at present. If the database never goes > idle for that long then we continue to journal until the WAL size exceeds > 20MB on desktop or 10MB on mobile. > > But prior to that flushing the data has been write()ten, right? So the > OS will take care of flushing it eventually as long as it's shut down > cleanly. > > / Jonas > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
