[718] in arla-drinkers
bsd-xfs, signaling to break a wait
daemon@ATHENA.MIT.EDU (Robert Watson)
Sun Mar 28 09:22:48 1999
From owner-arla-drinkers@stacken.kth.se Sun Mar 28 14:22:47 1999
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 1235 invoked from network); 28 Mar 1999 14:22:46 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 28 Mar 1999 14:22:46 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id QAA02318
for arla-drinkers-list; Sun, 28 Mar 1999 16:14:34 +0200 (MET DST)
Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.93.229])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id QAA02306
for <arla-drinkers@stacken.kth.se>; Sun, 28 Mar 1999 16:14:19 +0200 (MET DST)
Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3])
by fledge.watson.org (8.8.8/8.8.8) with SMTP id JAA06474
for <arla-drinkers@stacken.kth.se>; Sun, 28 Mar 1999 09:14:17 -0500 (EST)
(envelope-from robert@cyrus.watson.org)
Date: Sun, 28 Mar 1999 09:14:17 -0500 (EST)
From: Robert Watson <robert@cyrus.watson.org>
X-Sender: robert@fledge.watson.org
Reply-To: Robert Watson <robert@cyrus.watson.org>
To: arla-drinkers@stacken.kth.se
Subject: bsd-xfs, signaling to break a wait
Message-ID: <Pine.BSF.3.96.990328090652.6339C-100000@fledge.watson.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
Arla Folk,
I've been playing with XFS some over the last week or so. I ran into the
following behavior:
When a user process touches a section of the mounted xfs file system and
the appropriate data is not in the kernel cache or owned by the kernel,
then the user process is blocked while a request message is sent to the
daemon listening on /dev/xfsn, and remains blocked until an appropriate
wakeup message is sent with the sequence number of the request message.
If additional user processes want to access the same object that that
an existing outgoing request is for, they also block, but additional
messages are not sent (or at least, this is true of getroot).
The first process can be signaled to break its wait on the object.
Example: \ls -d /cachefs (where /cachefs is the mountpoint). Pressing
ctrl-c to interrupt the first user process works. However, if you ctrl-c
a second process running the same command, but started after the first
process, it will not be released from the block until the first user
process is released. That is, its blocking appears to be uninterruptable.
Preferred behavior would seem to be: if any process blocking on a message
receives a signal (such as ctrl-c) it may be woken up, not just the first
one (presumably the first in the chain of sleepers?)
Robert N Watson
robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C
Carnegie Mellon University http://www.cmu.edu/
TIS Labs at Network Associates, Inc. http://www.tis.com/
Safeport Network Services http://www.safeport.com/
