diff options
author | Karel Zak | 2007-03-30 13:10:59 +0200 |
---|---|---|
committer | Karel Zak | 2007-03-30 13:10:59 +0200 |
commit | dc8fdc57cd3ba0658cf4ab05031695c2d2965f93 (patch) | |
tree | 4d7e113dac6f95bed306907c1c4e7a1b488351cc /mount/losetup.8 | |
parent | tests: add lock_mtab() performance and reliability test (diff) | |
download | kernel-qcow2-util-linux-dc8fdc57cd3ba0658cf4ab05031695c2d2965f93.tar.gz kernel-qcow2-util-linux-dc8fdc57cd3ba0658cf4ab05031695c2d2965f93.tar.xz kernel-qcow2-util-linux-dc8fdc57cd3ba0658cf4ab05031695c2d2965f93.zip |
mount: fix mtab_lock
* the lock function uses F_SETLK / F_SETLKW as a conditional wait.
It's more reliable and better for performance to close the
MOUNTED_LOCK file in unlock_mtab(), otherwise concurrent process will
be wait by while () { link() } loop instead on fcntl(F_SETLKW).
Thanks to Jeff Moyer <moyer@redhat.com> who found the problem two
year ago.
* when open(MOUNTED_LOCK) failed, we need to try everything again, but
the original code didn't zeroize "we_created_lockfile" and the old
version in particular case left lock_mtab() without locked /etc/mtab.
This is nasty bug.
* the original locking code had bad performance due too long sleep
(1s), between attempts. Now we're more aggressive and we use
5000ms. The result is that more processes is able to lock mtab in
short time slice.
Thanks to Peter Rockai <prockai@redhat.com> who found the problem
and suggest a first version of the code with usleep.
* now we don't count number of attempts anymore, but we count sum of
time which we spend in the mtab_lock(). The number of attempts is
not important (and it also depends on CPU performance, load,
scheduler, ...), the important thing is how long we spend with
locking. Now time limit is 30s.
Signed-off-by: Karel Zak <kzak@redhat.com>
Diffstat (limited to 'mount/losetup.8')
0 files changed, 0 insertions, 0 deletions