[pacman-dev] filesystem performance

[Vesa Kaihlavirta]

but we haven't got reassuring answers to our "database corruption" fear.
>
> So I would like to ask you to convince us, why sqlite is safe (well,
> personally I have very limited sql[ite] knowledge now). Please try to
> understand that for most of the pacman devels/contributors "stability"
> is more important than speed [obviously corrupted localdb == unusable
> system]. That's why I can guess that this idea won't be accepted until
> we cannot see the proof of the fact that the new db back-end is as safe
> as the old one (or more safer ;-P).


Of course. Although I hope you don't mean 'proof' as in 'mathematical
proof'. It might take me some while to complete that...

Sqlite implements ACID except for Consistency, and that because it ignores
foreign key constraints. But otherwise, I believe that part would be
immediately safer than what we have now.

As for filesystem corruption (how often does this even happen with current
sensible filesystems?), one option would be to back up the localdb after
every commiting pacman operation. Probably with some autoexpiration logic.
For instance, extra.db is 337KB unpacked (using sqlize.py -- might be
missing some fields for now), extra.db.bz2 is 126K, so we could clone those
quite a lot of times before using more space than what /var/lib/pacman/
always does (which may be as high as 50MB on a fresh install, ext3).

By the way, how safe do you see the current DB currently? I remember having
at least a couple of disasters with the filedb when trees were truncated.
Sure it was my fault for trying out alternative filesystems, but still, this
is exactly the sort of corruption you're afraid of, is it not?

--vk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://archlinux.org/pipermail/pacman-dev/attachments/20080128/ab64173d/attachment.htm>