You are not logged in.
Pages: 1
Topic closed
While configuring X on my laptop, I forgot to install xf86-input-* and was presented with an X session where the keyboard was not functional (not even C-M-F1). I turned off the laptop and then turned it on again. Unfortunately, upon rebooting, the files from the packages which I had just installed 10-20 seconds before poweroff (Xorg, xf86-video-intel, etc) became empty (length = 0 bytes), and it sort of took me a while until I figured that out
.
Now, I know that this is a hot topic with Ext4, but nonetheless, shouldn't pacman and yaourt call fsync() after installing a package? Should I report this as a bug/feature request in the Arch Flyspray?
Thanks.
Offline
I think this branch does it : http://code.toofishes.net/cgit/dan/pacm … g/?h=fsync
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
sorry ignore me, the idea was only to sync the database.
http://www.archlinux.org/pipermail/pacm … 08439.html
Adding an fsync() in the write_db_entry() call would probably make sense.
However, note the funny part here- if we sync our DB entries, and then
your machine gets powered off, you might end up with a DB that got
committed but files in the package never actually got written to disk.
But even this small change seemed to slow down pacman a lot. (though I should benchmark this again).
Btw, you cannot do a general fsync(), you do fsync on a specific file (descriptor).
And its likely this would cause a huge performance drop when installing packages if you do it on every file.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
What about just calling sync() after pacman finishes? That shouldn't affect performance that much.
Offline
Well this is where I am lost.
Theoretically, calling sync() at the end should be more costly that calling fsync() on each file, because it has to push all changes, not only pacman ones. This could be quite bad if the system is under heavy i/o.
AFAIK, here are the ups and down of a main sync() call over individual fsync() calls :
+ very simple to implement (fsync on each file is apparently not enough, the changes need to be recorded on the directory level as well, and implementing this does not seem trivial)
+ also sync changes done by scriptlets (but here we can argue that the important programs used by scriptlets should take care of syncing)
- sync everything, not only changes caused by pacman
- if the crash/reboot happens in the middle of a pacman operation, it is useless
while searching for information about the problem yesterday, I felt on this interesting thread :
http://rpm5.org/community/rpm-devel/0400.html
this is where most of the arguments above come from. But I am don't know what we should do, if anything at all.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
Anything new on fsync after the pacman update?I'm having a system for which it is not uncommon to be shut down by pulling the power of the socket and it would be nice to prevent data loss.
Offline
BlackLotus89, please don't necro bump threads. If you have any issue, create a thread and link the old relevant threads to let the users know what you have attempted.
https://wiki.archlinux.org/index.php/Fo … Bumping.27
Closing...
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Pages: 1
Topic closed