(no subject)

A recurring issue that came to a head at this years AFS Best  
Practices Workshop is how we manage the standardisation of extensions  
to the protocol.

The attached document outlines a possible, formal, standardisation  
process for AFS extensions. None of it is set in stone, and your  
comments are greatly appreciated. Comments can be made either  
directly to me, or on the afs3-standardization <at> openafs.org list, to  
which replies are directed.

If you're interested in the future development of AFS, please take  
the time to review and comment upon the document.

Thanks,

Simon.

AFS                                                         S. Wilkinson
                                                 University of Edinburgh
                                                           July 15, 2008

                    Options for AFS Standardisation

Abstract

   With the impending formation of the foundation to house OpenAFS, the
   increasing pace of OpenAFS development, and the emergence of other
   AFS implementations, there is a growing need for a more formal,

Re: Patches to get Arla running on FreeBSD 8-CURRENT

On Tue, Feb 26, 2008 at 2:11 AM, Alec Kloss
<alec-keyword-arla.4d43de <at> setfilepointer.com> wrote:
> On 2008-02-25 22:23, Garance A Drosehn wrote:
>> At 9:38 PM -0400 2/25/08, Marc G. Fournier wrote:
>> >-----BEGIN PGP SIGNED MESSAGE-----
>> >Hash: SHA1
>> >
>> >Can we commit these patches to ports itself, maybe with the make
>> >file setup so  6.x is marked BROKEN while dealing with the problems
>> >there?  Might get more testers involved ... ?
>>
>> Or create a new port, "arla8", or "arla-dev".
>
> To the best of my knowledge, the port I made
> (http;//setfilepointer.com/pub/afs/FreeBSD) works for 6.3, 7.0 and
> -current, except maybe for changes in the last few days in -current
> which may have broken the port.  If there's sufficient interest,
> I'll add 5.x support (via arla 0.43) to the port as well, but I was
> hoping to avoid that, as it's a lot of overhead and arla's newish
> block-by-block cache (thanks Thomas) which isn't available in arla
> 0.43 makes arla highly competitive with the OpenAFS client
> available elsewhere.
>
> As for getting the port into the ports tree, I think everyone's all
> for it, but Thomas is volunteering to help merge our patch into the
> arla sources which I'd prefer over maintaining a jumbo patch like
> what we have now.  I'm optimistic that we can probably have
> everything ready by/after the weekend.
>
> So, please do test the port, and whine at me and/or Robert about

Re: Patches to get Arla running on FreeBSD 8-CURRENT

On 2008-07-16 00:52, Ben Kaduk wrote:
[chop]
> 
> Sorry to reply to such an old thread, but I see that there have been
> recent contributions to the AFS page on the FreeBSD wiki (such
> as testing on 7.0-release), but the port still hasn't made it into
> the FreeBSD Ports Collection.  Is this in the works?  Is it merely lacking
> for manpower?
> 
> Thanks,
> 
> Ben Kaduk
> 

No problem on the old thread...

I was hoping there might be a Arla release to use instead of my
homemade tarball that the arla-devel port is using for making an
official PR.  There are also some stability issues with arla on
FreeBSD which I haven't been able to track down successfully.
And finally, arla no longer seems to compile against -CURRENT.  All
of these things, plus a lack of time as you mention, have kept me
from making a PR for a port.  

Robert, my -CURRENT box needs a power supply which is on it's way;
when I get it running, do you mind if I ask for some assistance
getting a newer arla snapshot going on -CURRENT?  Once that's
working I'll commit to writing up a PR to get the arla-devel port
(and openafs-devel too) committed.

Re: Patches to get Arla running on FreeBSD 8-CURRENT

On Wed, Jul 16, 2008 at 7:41 AM, Alec Kloss
<alec-keyword-arla.4d43de <at> setfilepointer.com> wrote:
> On 2008-07-16 00:52, Ben Kaduk wrote:
> [chop]
>>
>> Sorry to reply to such an old thread, but I see that there have been
>> recent contributions to the AFS page on the FreeBSD wiki (such
>> as testing on 7.0-release), but the port still hasn't made it into
>> the FreeBSD Ports Collection.  Is this in the works?  Is it merely lacking
>> for manpower?
>>
>> Thanks,
>>
>> Ben Kaduk
>>
>
> No problem on the old thread...
>
> I was hoping there might be a Arla release to use instead of my
> homemade tarball that the arla-devel port is using for making an
> official PR.  There are also some stability issues with arla on
> FreeBSD which I haven't been able to track down successfully.
> And finally, arla no longer seems to compile against -CURRENT.  All
> of these things, plus a lack of time as you mention, have kept me
> from making a PR for a port.
>

I'm glad that you're still thinking about it, even if you don't have enough
time to do a whole lot with it.

Re: Patches to get Arla running on FreeBSD 8-CURRENT

I've been kicking around arla from CVS against a pretty
recent -current.  I can load nnpfs, start arlad, get and list
tokens, but attempting to "ls /afs" results in a seemingly
permanent hang after showing this:

lock order reversal:
 1st 0xc1c8dd64 user map (user map)  <at> 
/usr/current/src/sys/vm/vm_map.c:2208
 2nd 0xc2088ce8 ufs (ufs)  <at> 
/usr/current/src/sys/vm/vm_object.c:1053
KDB: stack backtrace:
db_trace_self_wrapper(c0b49785,c878ea98,c07d02ae,c0b4c052,c2088ce8,...)
at db_trace_self_wrapper+0x26
kdb_backtrace(c0b4c052,c2088ce8,c0b4049d,c0b4049d,c0b6d558,...) at
kdb_backtrace+0x29
witness_checkorder(c2088ce8,9,c0b6d558,41d,c0783fb4,...) at
witness_checkorder+0x6de
__lockmgr_args(c2088ce8,80400,c2088d04,0,0,...) at
__lockmgr_args+0x777
ffs_lock(c878eba0,0,9f,80400,c2088c90,...) at ffs_lock+0x8a
VOP_LOCK1_APV(c0c3e160,c878eba0,c0c56080,c2088c90,80400,...) at
VOP_LOCK1_APV+0xa5
_vn_lock(c2088c90,80400,c0b6d558,41d,28725000,...) at _vn_lock+0x5e
vm_object_sync(c2010174,0,0,2000,0,...) at vm_object_sync+0x186
vm_map_sync(c1c8dd20,28725000,28727000,0,0,...) at
vm_map_sync+0x281
msync(c1ebc000,c878ecf8,c,c0b4ca63,c0c1aed8,...) at msync+0x6c
syscall(c878ed38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (65, FreeBSD ELF32, msync), eip = 0x2827007f, esp =

Re: Patches to get Arla running on FreeBSD 8-CURRENT

I've rebuilt everything and now there's a panic trying to mount
nnpfs:

(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc079431e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xc07945e3 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:572
#3  0xc0496107 in db_panic (addr=Could not find the frame base for "db_panic".
) at /usr/src/sys/ddb/db_command.c:446
#4  0xc0496b38 in db_command (last_cmdp=0xc0c5e9f0, cmd_table=0x0, dopager=1)
    at /usr/src/sys/ddb/db_command.c:413
#5  0xc0496c6a in db_command_loop () at /usr/src/sys/ddb/db_command.c:466
#6  0xc049845d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:228
#7  0xc07c1746 in kdb_trap (type=12, code=0, tf=0xc89b682c)
    at /usr/src/sys/kern/subr_kdb.c:534
#8  0xc0ab8e6f in trap_fatal (frame=0xc89b682c, eva=0) at /usr/src/sys/i386/i386/trap.c:925
#9  0xc0ab90a3 in trap_pfault (frame=0xc89b682c, usermode=0, eva=0)
    at /usr/src/sys/i386/i386/trap.c:847
#10 0xc0ab9aa8 in trap (frame=0xc89b682c) at /usr/src/sys/i386/i386/trap.c:525
#11 0xc0a9da9b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#12 0xc08116be in vfs_filteropt (opts=0x0, legal=0xc2066418)
    at /usr/src/sys/kern/vfs_mount.c:1818
#13 0xc205d2d2 in nnpfs_mount_freebsd () from /usr/local/arla/bin/nnpfs.ko
#14 0xc0813711 in vfs_donmount (td=0xc1ebd690, fsflags=0, fsoptions=0xc89b6c18)
    at /usr/src/sys/kern/vfs_mount.c:1010
#15 0xc0813d78 in kernel_mount (ma=0xc1ddaa60, flags=0) at /usr/src/sys/kern/vfs_mount.c:2291
#16 0xc205d47d in nnpfs_cmount_freebsd () from /usr/local/arla/bin/nnpfs.ko
#17 0xc0811c67 in mount (td=0xc1ebd690, uap=0xc89b6cf8) at /usr/src/sys/kern/vfs_mount.c:816
#18 0xc0ab9384 in syscall (frame=0xc89b6d38) at /usr/src/sys/i386/i386/trap.c:1081

Re: Patches to get Arla running on FreeBSD 8-CURRENT

Never mind... everything from my last email appears to be related
to running inside qemu.  On bare metal, I'm still stuck with a
deadlock trying to ls /afs:

--- syscall (6, FreeBSD ELF32, close), eip = 0x281824c3, esp = 0xbfbfeb1c, ebp = 0xbfbfee78 ---
nnpfs: cdev: 0, syscall: 339
lock order reversal:
 1st 0xc68fed64 user map (user map)  <at>  /usr/src/sys/vm/vm_map.c:2208
 2nd 0xc6db9bdc ufs (ufs)  <at>  /usr/src/sys/vm/vm_object.c:1053
KDB: stack backtrace:
db_trace_self_wrapper(c0b48fe5,e919da98,c07d02ae,c0b4b852,c6db9bdc,...) at db_trace_self_wrapper+0x26
kdb_backtrace(c0b4b852,c6db9bdc,c0b3feed,c0b3feed,c0b6c718,...) at kdb_backtrace+0x29
witness_checkorder(c6db9bdc,9,c0b6c718,41d,c0783fb4,...) at witness_checkorder+0x6de
__lockmgr_args(c6db9bdc,80400,c6db9bf8,0,0,...) at __lockmgr_args+0x777
ffs_lock(e919dba0,0,9f,80400,c6db9b84,...) at ffs_lock+0x8a
VOP_LOCK1_APV(c0c3d220,e919dba0,c0c55140,c6db9b84,80400,...) at VOP_LOCK1_APV+0xa5
_vn_lock(c6db9b84,80400,c0b6c718,41d,2871f000,...) at _vn_lock+0x5e
vm_object_sync(c6fde7c0,0,0,2000,0,...) at vm_object_sync+0x186
vm_map_sync(c68fed20,2871f000,28721000,0,0,...) at vm_map_sync+0x281
msync(c69a7d20,e919dcf8,c,c0b4c243,c0c19f98,...) at msync+0x6c
syscall(e919dd38) at syscall+0x2a3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (65, FreeBSD ELF32, msync), eip = 0x283b99ef, esp = 0x2856d74c, ebp = 0x2856d7c8 ---

Sorry for all the noise... here's what shows up on the console with
fs nnpfsdebug all turned on:


/boot.config: -hConsoles: serial port
BIOS drive A: is disk0