Arch Linux User Repository

@Bevan: anyway today and yesterday it seams like we have some network problems. So it may not be worth wasting your weekend right now.

Thank you @Bevan.

My results are:

ping -s $((1500 - 28)) -M do 8.8.8.8 -c 1
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
76 bytes from 8.8.8.8: icmp_seq=1 ttl=116 (truncated)

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 15.731/15.731/15.731/0.000 ms

ping -s $((1500)) -M do 8.8.8.8 -c 1
PING 8.8.8.8 (8.8.8.8) 1500(1528) bytes of data.
ping: local error: message too long, mtu=1500

@drslmr: I will do some testing on the weekend but currently I don't think that this is related to our packaging of OpenAFS.

This is really just a shot in the dark, but when I had similar issues, it was (partially) caused by my internet connection which provides a lower MTU than normal for IPv4 connections. You may try adding "-rxmaxmtu 1404" (or even lower numbers) to AFSD_ARGS in /etc/conf.d/openafs. You'll need to restart the OpenAFS client afterwards. You can also use ping to determine your MTU (see for example https://mike632t.wordpress.com/2019/03/03/determine-mtu-size-using-ping/). If it's anything below 1492, this may be the reason.

Similar as described at https://bbs.archlinux.org/viewtopic.php?id=295218 I get hangs also in firefox. My .mozilla is in AFS. I found that I can "cd" to .mozilla/firefox but "cd" hangs when changing into the default profile sub-directory.

$ cmdebug localhost
Lock afs_discon_lock status: (none_waiting, 3 read_locks(pid:0))
** Cache entry @ 0x15bfdd80 for 182.537041393.18360.17115257 [<my domain>]
    locks: (none_waiting, upgrade_locked(pid:2455 at:121))
         2426640 bytes  DV        14448  refcnt     2
    callback c3dfa100   expires 1714731281
    4 opens     4 writers
    normal file
    states (0x21), stat'd
** Cache entry @ 0x21dcfb40 for 182.537041393.284080.16762084 [<my domain>]
    locks: (none_waiting, write_locked(pid:670 at:51))
               0 bytes  DV            0  refcnt     3
    callback c3dfa100   expires 1714731280
    1 opens     1 writers
    normal file
    states (0x21), stat'd
** Cache entry @ 0x21dca640 for 182.537041393.50053.16761613 [<my domain>]
    locks: (none_waiting, write_locked(pid:3003 at:147))
            6144 bytes  DV       166272  refcnt     2
    callback c3dfa100   expires 1714731280
    0 opens     0 writers
    normal file
    states (0x1), stat'd
** Cache entry @ 0x095fc840 for 182.537041393.50669.17578544 [<my domain>]
    locks: (none_waiting, write_locked(pid:2507 at:142))
            2048 bytes  DV           39  refcnt     2
    callback c3dfa100   expires 1714732222
    0 opens     0 writers
    normal file
    states (0x1), stat'd

Some system info:

openafs 1.8.11-1
openafs-modules-dkms 1.8.11-1
linux 6.8.7.arch1-1

Hi,

I get some hungs, I reported elsewhere : https://bbs.archlinux.org/viewtopic.php?id=295218

I thought it has to do with the xorg-server, but maybe it is related to AFS?

Can anyone report their experience with OpenAFS and Linux 6.7? I'm personally having issues with that combination (hanging accesses) but developers working with the exact same software versions cannot reproduce any issues. See: https://lists.openafs.org/pipermail/openafs-devel/2024-January/020909.html

Update 2024-01-31: No need for feedback anymore. This turned out to be a regression in the Linux kernel which is only triggered in specific scenarios. This should be solved in an upcoming kernel release. A corresponding patch has been submitted: https://lore.kernel.org/netdev/20240131155220.82641-1-bevan@bi-co.net/T/

@Bevan: Thank you for the quick solution.

I guess it is caused by this change, enabling the backup scripts in tar: https://gitlab.archlinux.org/archlinux/packaging/packages/tar/-/commit/23d47df2369e70dba362ac0e70036baef2475bdb#9b9baac1eb9b72790eef5540a1685306fc43fd6c_37_40

Still, I would not call this a tar issue. /usr/bin/backup is a very generic name to use and OpenAFS is quite niche while everyone uses tar. So I think we should rename the binary in this package.

Conflict with tar?

I'm getting the following error when upgrading tar:

error: failed to commit transaction (conflicting files) tar: /usr/bin/backup exists in filesystem (owned by openafs)

Probably an tar issue?

The kernel BUG with Linux 6.5 should now be fixed in openafs-modules 1.8.10-4 and openafs-modules-dkms 1.8.10-4.