DAFS: Remove AFS_DEMAND_ATTACH_UTIL
authorAndrew Deason <adeason@sinenomine.net>
Thu, 1 Aug 2013 19:06:52 +0000 (14:06 -0500)
committerDerrick Brashear <shadow@your-file-system.com>
Fri, 2 Aug 2013 15:48:06 +0000 (08:48 -0700)
commit7f15a1bbb34fa6f0d52800880f31be367d77a64f
tree5fd32820e1457f12da359943f2da0e7b00088fda
parentf393612d8f0a121d0cb8755f3eb9913c0f09606d
DAFS: Remove AFS_DEMAND_ATTACH_UTIL

Currently we have two DAFS-related preprocessor defines in the
codebase: AFS_DEMAND_ATTACH_FS and AFS_DEMAND_ATTACH_UTIL. DAFS_FS is
the symbol for enabling DAFS code, and turns on demand attachment and
all of the related complicated volume handling; it requires pthreads.
DAFS_UTIL is supposed to be used for utilities interacting with DAFS,
but do not have pthreads and so cannot build the relevant threads for
e.g. the VLRU, so they don't support demand attachment and a lot of
more advanced volume handling techniques.

Having both of these exist is confusing. For example, currently in
partition.c we only initialize dp->volLockFile for DAFS_FS, even
though the structure exists if _either_ DAFS_FS or DAFS_UTIL is
defined. This means when only DAFS_UTIL is defined, volLockFile will
exist in the partition structure, but will be uninitialized!

Amongst other possible issues, this means right now that DAFS_UTIL
users (dasalvager is the only one right now) will try to use an
uninitialized volLockFile whenever they try to use a volume that needs
locking. Since the partition struct is usually initialized to all
zeroes, this means we'll try to issue a lock request for FD 0,
whatever FD 0 is. If FD 0 is not open, we'll fail with EBADF and bail
out. But if FD 0 is open to some random file, the lock will probably
succeed, and we'll proceed without actually locking the volume lock
file. While the fssync volume checkout mechanism still works, the
on-disk locking mechanism protects against race conditions the fssync
volume checkout mechanism cannot protect against, and so handling
volumes in this way is not safe.

This is just one example; there are other issues with the partition
headerLockFile and probably may other things; most instances of
DAFS_FS really should be enabled for DAFS_UTIL as well.

So, instead of trying to account for and fix all of these problems
individually, get rid of AFS_DEMAND_ATTACH_UTIL, and just use
AFS_DEMAND_ATTACH_FS. This means that all relevant code must be
pthreaded, but since the only relevant code is for the dasalvager, we
can just make dasalvager pthreaded. Salvaging does not make use of any
threads or LWPs, so this should not have any side-effects.

Thanks to Ralf Brunckhorst for reporting the issue where we encounter
EBADF when FD 0 is not open, leading to the discovery of this.

Change-Id: I3848eb877f26b9d65833d5ce0e03f5cf7ba28de4
Reviewed-on: http://gerrit.openafs.org/10123
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@your-file-system.com>
src/tsalvaged/Makefile.in
src/vol/partition.h
src/vol/salvager.c
src/vol/vol-salvage.c
src/vol/volume.h
src/vol/volume_inline.h