GNOME Bugzilla – Bug 588596
g-p-m calls fsync() after writing power history data
Last modified: 2012-03-23 14:37:44 UTC
Please describe the problem: It seems like g-p-m is calling fsync() after writing power history data to a disk file. This happens every 150 seconds according to an strace run I performed on my active g-p-m. This is an issue for systems that have been configured to spin hard disks down after some idle time since fsync() calls cause disks to spin up. Steps to reproduce: 1. Let g-p-m run as usual 2. strace g-p-m with "strace -t -o output.txt -p <PID of g-p-m> 3. Disconnect power 4. Let the strace run for about 6 minutes (a couple of 150-second cycles) 5. Kill the strace, open the strace output file and search for "fsync" Actual results: It can be seen that g-p-m, or something that g-p-m calls, is calling fsync() as part of an open(), write(), fsync(), close() cycle that repeats every 150 seconds (2.5 minutes) Expected results: To avoid unnecessary disk spin ups it'd make sense for the writes to disk files to not be followed by fsync() calls Does this happen every time? I believe so, yes. According to a comment by Richard in unrelated #586582, the fsync() calls should be happening only when battery is low, but I am seeing this with a fully-charged battery Other information: My battery info: $ cat /proc/acpi/battery/BAT0/info present: yes design capacity: 84240 mWh last full capacity: 84610 mWh battery technology: rechargeable design voltage: 10800 mV design capacity warning: 4230 mWh design capacity low: 200 mWh capacity granularity 1: 1 mWh capacity granularity 2: 1 mWh model number: 42T4532 serial number: 1218 battery type: LION OEM info: Panasonic Battery state right before disconnecting power: $ cat /proc/acpi/battery/BAT0/state present: yes capacity state: ok charging state: charged present rate: 0 mW remaining capacity: 84570 mWh present voltage: 12567 mV
Forgot to mention: I am running the latest released version of Ubuntu (9.04). For some reason g-p-m is at 2.24.2 in Ubuntu 9.04; I don't know why it didn't ship with 2.26, especially since the rest of the Gnome applications and libraries are at 2.26.x. Hope this is not something that only affects Ubuntu users and this old version of g-p-m. Apologies in advance if that is the case. I'll attach the full strace output I obtained after strace'ing g-p-m, but what I am seeing is the following calls repeating every 150 seconds: 21:33:39 open("/home/elparis/.gnome2/gnome-power-manager/profile-42T4532-84240-_1218-charging.csv.AAN3WU", O_RDWR|O_CR EAT|O_EXCL|O_LARGEFILE, 0666) = 17 21:33:39 fcntl64(17, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 21:33:39 fstat64(17, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 21:33:39 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5fb8000 21:33:39 _llseek(17, 0, [0], SEEK_CUR) = 0 21:33:39 write(17, "0, 0, 0\n0, 120, 14\n0, 119, 14\n0, "..., 1168) = 1168 21:33:39 access("/home/elparis/.gnome2/gnome-power-manager/profile-42T4532-84240-_1218-charging.csv", F_OK) = 0 21:33:39 fsync(17) = 0 21:33:39 close(17) = 0
Created attachment 138422 [details] strace's output strace that shows the open(), write(), fsync(), close() cycle that repeats every 150 seconds
g-p-m is not the only application that has this problem; Firefox has it (or had it since it is apparently fixed in recent Firefox versions.) The following Firefox bug explains the issue in detail: https://bugzilla.mozilla.org/show_bug.cgi?id=421482 And this blog entry from one of the Firefox developers has a lot of great information about the issue in Firefox: http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/ These two links are only for background/related information; hopefully everybody will agree that it is a bad thing that g-p-m does an fsync() after writing power history to disk, if that is really what is happening.
That old version of g-p-m just used g_file_set_contents, which probably does a fsync. The latest stable version uses DeviceKit-power, which is much smarter about when to save the profile data.