Re: New packages and cross-config.gnu
> ... last time I accidently replaced my Hurd sync with the one from
> fileutils it didn't work adn my system hung on it. I haven't
> investigated it because the standard Hurd sync works fine, but you
> might want to check this before renaming it.
Well, that is odd. I would expect the opposite behavior, but a bug is a bug.
The Hurd sync calls file_syncfs with the wait flag set, so it blocks until
all disk writes have completed and all filesystems have responded. The
`sync' libc function has the traditional Unix behavior, i.e. the wait flag is
clear and it should return fairly quickly (after notifying every filesystem,
but not waiting for all writes to complete).
If some translator is hung and not responding, the file_syncfs RPC in the
root filesystem might block indefinitely waiting for a hung child filesystem
to handle its own file_syncfs RPC. However, it should always be possible to
cancel the RPC, i.e. interrupt sync with ^C and worst case respond after a
one second delay.
Either way, diskfs does some hairy locking processing a file_syncfs. I am
seeing strangeness too. I think there's some bug in diskfs's locking or
logic handling that. I was able to see threads blocked on a losing
translator (a crashing /hurd/term), but when I try to interrupt the root RPCs
(which after a second should just abandon talking to the losing translator),
thinks got weird and wedged.
Reply to: