From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 27 17:13:24 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43E0E1065692 for ; Tue, 27 Oct 2009 17:13:24 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 00B3D8FC21 for ; Tue, 27 Oct 2009 17:13:23 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so148575qwb.7 for ; Tue, 27 Oct 2009 10:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=5jj8yzoEJ6R+weElp9jQGjV74i1YJ6p6VOsbm88+S6g=; b=ktqvtcrEgkYlO1ZJ0hMjn2Ikx6IGuo3baTpfRfqth83h+XQlI/xP2hAG0C6NJODBDQ 1a6eScqKHk4WgqXK5zxizTsW9UrpFiWJYdNS9Uy8DElCKEqaugId8Ni6Q8m5RocXE3hP EInVBnbowv2CJLvJgQMrfH87dHyM7aoHppFtM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HIHbemx8etKvfyKPSRB2QzNEL6vgw6Zbnoj50pIctHUXlmOVvb7OEQ9ecbFvPLv5Ek ktzUZx/Z/EXwQQ9rH/AEL8D2VKxJPDk7eFA5JSxRxHtOxdfbIK1y6fujilsNOpBXp32L z1olLFDT6PB/oUQMEJNw+6am7kl5+I6+Yp5x8= MIME-Version: 1.0 Received: by 10.220.126.214 with SMTP id d22mr9781955vcs.114.1256663598562; Tue, 27 Oct 2009 10:13:18 -0700 (PDT) Date: Tue, 27 Oct 2009 13:13:18 -0400 Message-ID: <237c27100910271013s1d8602d0l74d7d9d2c137adee@mail.gmail.com> From: Linda Messerschmidt To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: FreeBSD 7.2 + NFS + nullfs + unlink + fstat = Stale NFS File Handle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 17:13:24 -0000 We have encountered a problem with a weird behavior when NFS and nullfs are combined and a program creates, unlinks, and then fstats a file in the resulting directory. After encountering this problem in the wild, I wrote a quick little C program. It creates a file, unlinks the file, and then fstat's the open file descriptor. The results: UFS: OK NFS: OK UFS+NULLFS: OK NFS+NULLFS: fstat returns ESTALE The UFS test is just run in /tmp. All others are run in /mnt (with umounts in between). The NFS setup looks like this: client# mount -o tcp server:/export/example /mnt The UFS+NULLFS setup looks like this: client# mount -t nullfs /tmp /mnt The NFS+NULLFS mount setup looks like this: client# mount -o tcp server:/export /export client# mount -t nullfs /export/example /mnt As far as I understand, this behavior should be supported, and the file should be "finally" deleted when the descriptor is closed. Even so, this is obscure enough that the response would be "don't do that" except that the open-unlink-fstat behavior was encountered with /usr/bin/vi, which does exactly that on its temporary files. So, we either fix it or retool everything not to use nullfs. Does anyone know what the likely source of this different behavior is, and whether it is feasible to address? Or is NFS+NULLFS just pushing the envelope a little too far? This is on 7.2-RELEASE-p1 and 7.2-STABLE. Thanks for any advice! Test program source below: #include #include #include #include #include #include int main() { int fd; struct stat st; fd = open("testfile", O_RDWR | O_CREAT | O_TRUNC, 0666); if (!fd) { fprintf(stderr, "open failed: %s\n",strerror(errno)); return 10; } if (unlink("testfile")) { fprintf(stderr, "unlink failed: %s\n",strerror(errno)); return 20; } if (fstat(fd, &st)) { fprintf(stderr, "fstat failed: %s\n",strerror(errno)); return 30; } close(fd); return 0; }