Excerpts from Simon Schampijer's message of 2012-01-10 14:19:59 +0100:
It would be good to add here information what the patch does, that it
adds the uid and filesize to the metadata but does not write it to disk etc.
How about this additional paragraph:
We now determine and fill in the
Hi Sascha,
thanks for the patch.
On 02/11/11 23:21, Sascha Silbe wrote:
The copy in the metadata storage can get corrupted, e.g. due to low level
crashes or running out of battery (see OLPC#11372 [1] for a real-life
example).
This is especially problematic for the uid property, since without
Excerpts from James Cameron's message of 2011-11-02 23:42:59 +0100:
I'm glad to see fixes for corrupted metadata, but I wonder if the
application (the datastore process) is properly asking the kernel to
retain the data? I wouldn't like to see it block on a sync, but I
thought there were ways
Yes, blocking on fsync() would be bad. How about a fork-and-fsync?
I wonder how long the kernel is leaving the filesystem in this state?
--
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
The copy in the metadata storage can get corrupted, e.g. due to low level
crashes or running out of battery (see OLPC#11372 [1] for a real-life
example).
This is especially problematic for the uid property, since without it the
caller (i.e. the Journal) can't even figure out which entry to
I'm glad to see fixes for corrupted metadata, but I wonder if the
application (the datastore process) is properly asking the kernel to
retain the data? I wouldn't like to see it block on a sync, but I
thought there were ways to ask for the data to be written soon.
--
James Cameron
6 matches
Mail list logo
