[pacman-dev] [PATCH] libalpm: sync changes to disc when appropriate

Xavier shiningxc at gmail.com
Sat Mar 14 09:02:37 EDT 2009

On Sat, Mar 14, 2009 at 1:40 PM, Thomas Bächler <thomas at archlinux.org> wrote:
> Dan McGee schrieb:
>> We don't make calls to fsync() or fdatasync() when we are attempting to do
>> something transactionally, such as writing out one of our DB entries. Add
>> a
>> call to fdatasync() when we write DB entries, and also ensure we sync our
>> log changes to disc whenever we close it.
>> Another important thing to ensure is that we commit removals of DB
>> entries.
>> The method isn't necessarily pretty, but it works in _alpm_db_remove().
> Can we get this in the maint branch as well? I had this several times
> yesterday when experimenting with 2.6.29-rc8 and some experimental intel
> driver stuff and it crashed a lot. I eventually had to disable delalloc on
> my / to make this go away.

>From http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/
What’s the best path forward?   For now, what I would recommend to
Ubuntu gamers whose systems crash all the time and who want to use
ext4, to use the nodelalloc mount option.   I haven’t quantified what
the performance penalty will be for this mode of operation, but the
performance will be better than ext3, and at least this way they won’t
have to worry about files getting lost as a result of delayed
allocation.    Long term, application writers who are worried about
files getting lost on an unclena shutdown really should use fsync.

Short term : use nodelalloc if your system is likely to crash (using
experimental or unstable drivers)
Long term : fix the apps

I don't think that improving pacman on this side ASAP will solve the
general problem. You will still have many other apps affected on your
system, some of them also dealing with important files. Or not?

Anyway, I am not opposed to a new quick maint release, this decision
is up to Dan anyway. I am just saying I don't see a big need for it.
And in any cases, we should try to move forward for a 3.3 release :)

More information about the pacman-dev mailing list