[OpenAFS] afsdb feature locking up afs_ioctl?

[Mike Polek]

Jeffrey Hutzelman wrote:
> On Monday, May 09, 2005 06:03:14 PM -0700 Mike Polek <mike@pictage.com> 
> wrote:
> 
>> When the -afsdb flag is used for afsd, there appears to be
>> an extra process that gets started to loop in the
>> AfsdbLookupHandler function. (Process id 12269 below.)
>> It looks like this process is holding /proc/fs/openafs/afs_ioctl
>> open. Is this intended/necessary? Or an accidental side
>> effect of something?
> 
> 
> It's necessary.  That function spends most of its time blocked in an AFS 
> system call, waiting for the AFS kernel module to need its services. 
 > [...] So yes, this process
> is not only holding that file open but is actually blocked in an ioctl 
> on it.
> 
> 
>> The reason it's important to me is that
>> I can't umount /proc while the process has the open file
>> descriptor, and I need to umount /proc in order to properly
>> get my system booted after a pivot_root.
> 
> 
> I'm afraid afsd really wasn't intended to be started in this manner. 
> However, there are a couple of options that might work for you:
> 
> (1) Extract AfsdbLookupHandler() and its dependencies into a separate
>    program.  Run afsd without the -afsdb switch, and start the AFSDB
>    handler in a separate program after you've pivoted the real root
>    into place and remounted /proc.
> 
> (2) Instead of unmounting and remounting /proc, move the mounted tree
>    with mount --move.  It should be possible to do this even while
>    there are open files on the filesystem.


For anyone interested, I've discovered that mount --move /initrd/proc /proc
hangs the system. I also discovered that using the 2.6 kernel with the
newfangled cpio initrd (2.4 used a loopback device), attempting to umount
/initrd (if I switch to using pivot_root) also hangs the system.
In fact, the standard way of booting Fedora Core appears to be to
do a mount --move /sysroot / at the last minute, which actually
ends up keeping the old rootfs kicking around in memory, stacked
under the new root filesystem.

My solution to the dilemma was to just delete all of the files out of
the initial ramdisk right before the final switchroot. If not using
-afsdb, this clears up all of the memory used by the initial ramdisk,
maybe with the exception of a mountpoint or two. If I want to use the
-afsdb switch, then the process running AfsdbLookupHandler keeps about
1.5Mb of libraries locked up in the ramdisk, which I consider a
small price to pay, under the circumstances.

Thanks for all of your assistance. I now have Fedora Core 3 booting
cleanly with nearly everything in replicated volumes, and less than
1Mb used by the tmpfs root filesystem when the system is booted.
(Thanks to the individual whose name I can't remember who, at
last years conference, suggested that even /etc/ could be RO with
some modifications. So far so good... :-) )

I hope to see many familiar faces at the conference this year.
Any idea when the agenda will be set, and registration open?

Take care,
Mike Polek
Pictage, Inc.