This should hopefully reduce local db corruption issues.
Signed-off-by: Allan McRae allan@archlinux.org --- lib/libalpm/be_local.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/libalpm/be_local.c b/lib/libalpm/be_local.c index 4574bd4..cb12abb 100644 --- a/lib/libalpm/be_local.c +++ b/lib/libalpm/be_local.c @@ -841,6 +841,7 @@ int _alpm_local_db_write(pmdb_t *db, pmpkg_t *info, pmdbinfrq_t inforeq) fprintf(fp, "\n"); }
+ fdatasync(fileno(fp)); fclose(fp); fp = NULL; } @@ -869,6 +870,8 @@ int _alpm_local_db_write(pmdb_t *db, pmpkg_t *info, pmdbinfrq_t inforeq) } fprintf(fp, "\n"); } + + fdatasync(fileno(fp)); fclose(fp); fp = NULL; }
This should hopefully reduce local db corruption issues.
Signed-off-by: Allan McRae allan@archlinux.org
lib/libalpm/be_local.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/libalpm/be_local.c b/lib/libalpm/be_local.c index 4574bd4..cb12abb 100644 --- a/lib/libalpm/be_local.c +++ b/lib/libalpm/be_local.c @@ -841,6 +841,7 @@ int _alpm_local_db_write(pmdb_t *db, pmpkg_t *info, pmdbinfrq_t inforeq) fprintf(fp, "\n"); }
fdatasync(fileno(fp));@@ -869,6 +870,8 @@ int _alpm_local_db_write(pmdb_t *db, pmpkg_t *info, pmdbinfrq_t inforeq) } fprintf(fp, "\n"); }
fdatasync(fileno(fp));
Wouldn't this cause a notable slow-down?
NG
On Sat, Oct 30, 2010 at 3:01 PM, Nagy Gabor ngaba@bibl.u-szeged.hu wrote:
Wouldn't this cause a notable slow-down?
I thought the issue was rather that the local db entries would be synced when the actual package files are probably not synced. But if we sync everything, then it's very likely to become very slow.
I seem to remember that Dan sent a fdatasync patch a while ago, I don't remember if it affected only the db or both db and files.
Also let's not forget this : Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
On 30/10/10 23:40, Xavier Chantry wrote:
On Sat, Oct 30, 2010 at 3:01 PM, Nagy Gaborngaba@bibl.u-szeged.hu wrote:
Wouldn't this cause a notable slow-down?
I thought the issue was rather that the local db entries would be synced when the actual package files are probably not synced. But if we sync everything, then it's very likely to become very slow.
This is to fix issues like: error: could not open file /var/lib/pacman/local/texlive-bin-2010.1-4/depends: No such file or directory
Missing package files can be detected using -Qk and fixed by reinstall so I find it reasonable to just sync the local db entries. Also, doing just that should not slow down the sync operation too much.
I seem to remember that Dan sent a fdatasync patch a while ago, I don't remember if it affected only the db or both db and files.
Also let's not forget this : Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
That would probably be better. I only did the files because the file descriptor for those was handy...
Allan
On Sat, Oct 30, 2010 at 6:01 PM, Allan McRae allan@archlinux.org wrote:
On 30/10/10 23:40, Xavier Chantry wrote:
On Sat, Oct 30, 2010 at 3:01 PM, Nagy Gaborngaba@bibl.u-szeged.hu wrote:
Wouldn't this cause a notable slow-down?
I thought the issue was rather that the local db entries would be synced when the actual package files are probably not synced. But if we sync everything, then it's very likely to become very slow.
This is to fix issues like: error: could not open file /var/lib/pacman/local/texlive-bin-2010.1-4/depends: No such file or directory
Missing package files can be detected using -Qk and fixed by reinstall so I find it reasonable to just sync the local db entries. Also, doing just that should not slow down the sync operation too much.
I seem to remember that Dan sent a fdatasync patch a while ago, I don't remember if it affected only the db or both db and files.
Also let's not forget this : Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
That would probably be better. I only did the files because the file descriptor for those was handy...
I have a bunch of local work that does all thsi right, so for now I'm going to toss this patch and I'll let you guys comment on my work once I get it posted here.
-Dan
pacman-dev@lists.archlinux.org