We've found an XO-1 running Fedora 11 + Sugar 0.84 with an interesting
datastore corruption issue.
The journal was showing just one object, but the
~/.sugar/default/datastore directory contained 4-5 invisible entries.
After removing index_updated and restarting Sugar, the entries
reappeared.
Ther
(also filed as http://bugs.sugarlabs.org/ticket/2132, but let's keep the
discussion on the mailing-list, please).
Today we figured out one of the possibly many ways in which the index of
the datastore can get corrupted in Sugar.
Here's an almost infallible recipe to reproduce it:
1. open Write
On Sat, Jun 19, 2010 at 08:33:50PM -0400, Bernie Innocenti wrote:
> We've found an XO-1 running Fedora 11 + Sugar 0.84 with an interesting
> datastore corruption issue.
>
> The journal was showing just one object, but the
> ~/.sugar/default/datastore directory contained 4-5 invisible entries.
> Af
On Sun, Jun 20, 2010 at 01:10:16AM +, Aleksey Lim wrote:
> On Sat, Jun 19, 2010 at 08:33:50PM -0400, Bernie Innocenti wrote:
> > We've found an XO-1 running Fedora 11 + Sugar 0.84 with an interesting
> > datastore corruption issue.
> >
> > The journal was showing just one object, but the
> > ~
Excerpts from Bernie Innocenti's message of Sun Jun 20 00:33:50 + 2010:
> The journal was showing just one object, but the
> ~/.sugar/default/datastore directory contained 4-5 invisible entries.
When were these "invisible" entries written? Directly before a crash?
With the way the current data
El Sun, 20-06-2010 a las 01:10 +, Aleksey Lim escribió:
> There were patches on bugs.sl.o that are using fsync on every ds change
> (file based fsync) to make journal more robust. I'm personally not happy
> with this method. And maybe most of journal issues with "lost" data could
> be effective
Excerpts from Bernie Innocenti's message of Sun Jun 20 14:20:45 + 2010:
> To implement the dirty flag, we could recycle the index_updated flag
> file: we could remove it before performing any change and restore it
> when we're done updating the journal.
If we're careful enough and prevent the
On Sun, Jun 20, 2010 at 02:33, Bernie Innocenti wrote:
> We've found an XO-1 running Fedora 11 + Sugar 0.84 with an interesting
> datastore corruption issue.
>
> The journal was showing just one object, but the
> ~/.sugar/default/datastore directory contained 4-5 invisible entries.
> After removin
On Sun, Jun 20, 2010 at 03:10, Aleksey Lim wrote:
> On Sat, Jun 19, 2010 at 08:33:50PM -0400, Bernie Innocenti wrote:
>> We've found an XO-1 running Fedora 11 + Sugar 0.84 with an interesting
>> datastore corruption issue.
>>
>> The journal was showing just one object, but the
>> ~/.sugar/default/
On Wed, Jul 28, 2010 at 07:21:12PM -0400, Bernie Innocenti wrote:
> 1. open Write
> 2. type something
> 3. close Write
> 4. wait a few seconds
> 5. kill -9 the datastore process
> 6. restart sugar (ctrl-alt-del)
>
> Your saved entry is gone. It still takes up space on disk, but it's no
> longer vi
On Thu, 2010-07-29 at 15:15 +1000, James Cameron wrote:
> Ugh. So Write has terminated before data is saved? That's bad. Should
> it not wait for data to be fully saved?
I believe data was saved, but the metadata index was not flushed to disk
by the datastore process.
--
// Bernie Innocent
On Thu, Jul 29, 2010 at 01:39:45AM -0400, Bernie Innocenti wrote:
> On Thu, 2010-07-29 at 15:15 +1000, James Cameron wrote:
> > Ugh. So Write has terminated before data is saved? That's bad. Should
> > it not wait for data to be fully saved?
>
> I believe data was saved, but the metadata index
On 29 Jul 2010, at 00:21, Bernie Innocenti wrote:
> (also filed as http://bugs.sugarlabs.org/ticket/2132, but let's keep the
> discussion on the mailing-list, please).
>
> Today we figured out one of the possibly many ways in which the index of
> the datastore can get corrupted in Sugar.
>
> H
On Thu, 2010-07-29 at 15:50 +1000, James Cameron wrote:
> On Thu, Jul 29, 2010 at 01:39:45AM -0400, Bernie Innocenti wrote:
> > On Thu, 2010-07-29 at 15:15 +1000, James Cameron wrote:
> > > Ugh. So Write has terminated before data is saved? That's bad. Should
> > > it not wait for data to be ful
On Thu, 2010-07-29 at 07:19 +0100, Gary Martin wrote:
> > Meanwhile, we're working on a work-around that will hopefully fix all
> > problems of this sort: a "Rescan" or "Reindex" item on the Journal
> > palette.
>
> Unsurprisingly, a massive -1 from me, but you knew that was coming already! ;)
Th
On Thu, Jul 29, 2010 at 03:15:46AM -0400, Bernie Innocenti wrote:
> Which is why the Repair function ought to be there. My first impulse was
> to make it hidden (ctrl-R in the Journal), but the others asked me how
> would users get to discover it if it were hidden.
How harmless is it? If quite ha
On Thu, 2010-07-29 at 17:26 +1000, James Cameron wrote:
> How harmless is it? If quite harmless, why can't it be included in the
> startup of the datastore?
Reindexing takes time proportional to the number of objects in the
datastore.
With a full journal, it can take 30-60 seconds on an XO-1.
-
On Thu, Jul 29, 2010 at 03:53:56AM -0400, Bernie Innocenti wrote:
> On Thu, 2010-07-29 at 17:26 +1000, James Cameron wrote:
> > How harmless is it? If quite harmless, why can't it be included in the
> > startup of the datastore?
>
> Reindexing takes time proportional to the number of objects in t
On Thu, 2010-07-29 at 19:15 +1000, James Cameron wrote:
> Does this block other activity, or can it be done without impact to user
> operations on the journal?
The journal icon does not show up in the frame until the indexing is
finished and no journal operations are possible. So, I guess, you al
On 29 Jul 2010, at 15:10, Bernie Innocenti wrote:
> On Thu, 2010-07-29 at 19:15 +1000, James Cameron wrote:
>
>> Does this block other activity, or can it be done without impact to user
>> operations on the journal?
>
> The journal icon does not show up in the frame until the indexing is
> fini
On Wed, 2010-07-28 at 19:21 -0400, Bernie Innocenti wrote:
> Here's an almost infallible recipe to reproduce it:
>
> 1. open Write
> 2. type something
> 3. close Write
> 4. wait a few seconds
> 5. kill -9 the datastore process
> 6. restart sugar (ctrl-alt-del)
>
> Your saved entry is gone. It sti
On Thu, Jul 29, 2010 at 05:01:32PM -0400, Bernie Innocenti wrote:
> We figured out that the datastore delays writes to disk by about 60
> seconds. This braindead behavior appears to be a *designed*
> optimization!
I recall encountering something like this last week. The test case was
to start Rec
On Thu, Jul 29, 2010 at 05:01:32PM -0400, Bernie Innocenti wrote:
> On Wed, 2010-07-28 at 19:21 -0400, Bernie Innocenti wrote:
> > Here's an almost infallible recipe to reproduce it:
> >
> > 1. open Write
> > 2. type something
> > 3. close Write
> > 4. wait a few seconds
> > 5. kill -9 the datasto
On Thu, 2010-07-29 at 17:45 +0100, Gary Martin wrote:
> OK... Here's a horrible kludge, but I think it's less of a horrible
> kludge than placing a big 'click this if you think random s##t has
> happened' button in one of our primary UIs.
>
> Make a new control panel for such admin/maintenance ac
On Thu, Jul 29, 2010 at 3:15 AM, Bernie Innocenti wrote:
> On Thu, 2010-07-29 at 07:19 +0100, Gary Martin wrote:
>> > Meanwhile, we're working on a work-around that will hopefully fix all
>> > problems of this sort: a "Rescan" or "Reindex" item on the Journal
>> > palette.
>>
>> Unsurprisingly, a
On Mon, 2010-08-02 at 16:04 -0400, Martin Langhoff wrote:
> There are much smarter ways to tackle this. Make the index rebuild
> automatic on Sugar startup, with some kind of spinner indicating we're
> working on something, conditional on
>
> - look at the newest file in ~/.sugar/default/datastor
26 matches
Mail list logo
