I think it would be an interesting experiment as well.
The paper provided a lot of interesting information on DRAM failure
rates, but I don't think you can infer failure rates about the
general population solely from examining the DRAM failures in a very
isolated (though large) population such
On Tue, Oct 6, 2009 at 6:49 PM, John Abd-El-Malek j...@chromium.org wrote:
It's about getting rid of nasty problems like the browser process crashing
every startup because of a corrupt database and decreasing browser process
crashes in general.
I am pretty sure that the sqlite wrapper and
It will be helpful to get our own measurement on database failures.
Carlos just added something like that.
Huan
On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.org wrote:
Saw this on
slashdot: http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf
The conclusion is an
I'm not sure how Carlos is doing it? Will we know if something is corrupt
just on load/save? I imagine there's no way we can know when corruption
happen in steady-state and the next query leads to some other browser memory
(or another database) getting corrupted?
On Tue, Oct 6, 2009 at 3:58 PM,
On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote:
On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org
wrote:
I'm not sure how Carlos is doing it? Will we know if something is
corrupt
just on load/save?
Many sqlite calls can return sqlite_corrupt. For
Our use of exclusive locking and page-cache preloading may open us up
more to this kind of shenanigans. Basically SQLite will trust those
pages which we faulted into memory days ago. We could mitigate
against that somewhat, but this problem reaches into areas we cannot
materially impact, such
On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org wrote:
On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote:
On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org
wrote:
I'm not sure how Carlos is doing it? Will we know if something is
On Tue, Oct 6, 2009 at 5:09 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.orgwrote:
On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote:
On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org
On Tue, Oct 6, 2009 at 5:09 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org wrote:
On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote:
On Tue, Oct 6, 2009 at 4:14 PM, John Abd-El-Malek j...@chromium.org wrote:
On Tue, Oct 6, 2009 at 5:10 PM, Scott Hess sh...@chromium.org wrote:
Our use of exclusive locking and page-cache preloading may open us up
more to this kind of shenanigans. Basically SQLite will trust those
pages which we faulted into memory days ago. We could mitigate
against that
On Tue, Oct 6, 2009 at 5:16 PM, Scott Hess sh...@chromium.org wrote:
On Tue, Oct 6, 2009 at 5:09 PM, Jeremy Orlow jor...@chromium.org wrote:
On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org
wrote:
On Tue, Oct 6, 2009 at 4:30 PM, Carlos Pizano c...@google.com wrote:
On
On Tue, Oct 6, 2009 at 4:59 PM, John Abd-El-Malek j...@chromium.org wrote:
The point I was trying to make is that the 'limit' factor as you put it is
proportional to memory usage. Given our large memory consumption in the
browser process, the numbers from the paper imply dozens of corruptions
On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.org wrote:
Given that sqlite corruption means (repeated) crashing of the browser
process, it seems this data heavily suggests we should separate sqlite code
into a separate process.
What does this mean for cases like the
On Tue, Oct 6, 2009 at 5:24 PM, Dan Kegel d...@kegel.com wrote:
1) zfs was right: checksums are a good idea. Can we add them to sqlite?
I believe so, but I'm still working through the details. And by
working I mean thinking. The challenge is in finding places to
tuck things away where they
Out of curiosity does Firefox do anything special w/ regard to how they
manage Sqlite? I can't imagine this problem is totally unique to us.
Kind Regards,
Anthony Laforge
Technical Program Manager
Mountain View, CA
On Tue, Oct 6, 2009 at 5:35 PM, Scott Hess sh...@chromium.org wrote:
On Tue,
On Tue, Oct 6, 2009 at 5:30 PM, Peter Kasting pkast...@google.com wrote:
On Tue, Oct 6, 2009 at 3:49 PM, John Abd-El-Malek j...@chromium.orgwrote:
Given that sqlite corruption means (repeated) crashing of the browser
process, it seems this data heavily suggests we should separate sqlite code
On Tue, Oct 6, 2009 at 5:53 PM, John Abd-El-Malek j...@chromium.org wrote:
If corruption in the in-memory URL database doesn't survive a crash (i.e.
because it's recreated each time),
It doesn't
I'm not sure I understand why moving it to another process is unworkable?
Chrome code is
On Tue, Oct 6, 2009 at 5:56 PM, Peter Kasting pkast...@google.com wrote:
On Tue, Oct 6, 2009 at 5:53 PM, John Abd-El-Malek j...@chromium.orgwrote:
If corruption in the in-memory URL database doesn't survive a crash (i.e.
because it's recreated each time),
It doesn't
I'm not sure I
I am with the others that don't see move sqlite to another process
as a natural outcome of these thread.
If using more memory is the concern, another process uses more memory.
sqlite is not crashing *that* much; yes it was the top crasher for a
while but it was a data race
This isn't about decreasing memory usage. It's about getting rid of nasty
problems like the browser process crashing every startup because of a
corrupt database and decreasing browser process crashes in general.
I think it's fair that not everyone shares the same opinion, but I do hope
that an
On Tue, Oct 6, 2009 at 6:49 PM, John Abd-El-Malek j...@chromium.org wrote:
This isn't about decreasing memory usage. It's about getting rid of nasty
problems like the browser process crashing every startup because of a
corrupt database and decreasing browser process crashes in general.
I
21 matches
Mail list logo
