> And I guess you will see these messages after a while. > tail: A/B: Stale NFS file handle > tail: no files remaining No it never happens. I waited a long time. Tail should not die because the file still opens.
> I think it was renamed to .nfsXXX by the feature of nfs server, which is > called silly-rename. Silly-rename was the keyword that I need ;) From: http://nfs.sourceforge.net/ Unix applications often open a scratch file and then unlink it. They do this so that the file is not visible in the file system name space to any other applications, and so that the system will automatically clean up (delete) the file when the application exits. This is known as "delete on last close", and is a tradition among Unix applications. Because of the design of the NFS protocol, there is no way for a file to be deleted from the name space but still remain in use by an application. Thus NFS clients have to emulate this using what already exists in the protocol. If an open file is unlinked, an NFS client renames it to a special name that looks like ".nfsXXXXX". This "hides" the file while it remains in use. This is known as a "silly rename." Note that NFS servers have nothing to do with this behavior. > Still I don't understand your problem (except the delay). > Do you want to say this ENOTEMPTY is the problem? No, it is not the problem. The strace I sent you was of a mutt working on a nfs /tmp. With NFS+AUFS it is different: ----> Mutt + /tmp+aufs+nfs mkdir("/tmp/.muttqYTz5v", 0700) = 0 open("/tmp/.muttqYTz5v/mutt-estrella-0-21858-0", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE|O_NOFOLLOW, 0600) = 4 link("/tmp/.muttqYTz5v/mutt-estrella-0-21858-0", "/tmp/mutt-estrella-0-21858-0") = 0 stat64("/tmp/.muttqYTz5v/mutt-estrella-0-21858-0", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 stat64("/tmp/mutt-estrella-0-21858-0", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 unlink("/tmp/.muttqYTz5v/mutt-estrella-0-21858-0") = 0 unlink("/tmp/.muttqYTz5v/mutt-estrella-0-21858-0") = -1 ENOENT (No such file or directory) rmdir("/tmp/.muttqYTz5v") = -1 ENOTEMPTY (Directory not empty) lstat64("/tmp/mutt-estrella-0-21858-0", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 fstat64(4, 0xbfc9934c) = -1 ENOENT (No such file or directory) ----> Mutt + /tmp+nfs mkdir("/tmp/.muttIOAHhM", 0700) = 0 open("/tmp/.muttIOAHhM/mutt-bowmore-1413-22816-0", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE|O_NOFOLLOW, 0600) = 4 link("/tmp/.muttIOAHhM/mutt-bowmore-1413-22816-0", "/tmp/mutt-bowmore-1413-22816-0") = 0 stat64("/tmp/.muttIOAHhM/mutt-bowmore-1413-22816-0", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 stat64("/tmp/mutt-bowmore-1413-22816-0", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 unlink("/tmp/.muttIOAHhM/mutt-bowmore-1413-22816-0") = 0 unlink("/tmp/.muttIOAHhM/mutt-bowmore-1413-22816-0") = -1 ENOENT (No such file or directory) rmdir("/tmp/.muttIOAHhM") = -1 ENOTEMPTY (Directory not empty) lstat64("/tmp/mutt-bowmore-1413-22816-0", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 fstat64(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 In both bases it open "/tmp/.muttXXX/mut-XXX", hard-link it to /tmp/mut-XXX; then remove /tmp/.muttXX/mut-XXX" But in ext2+nfs case it still can access the fd from "/tmp/.muttXXX/mutt-XXX", with aufs it fails. (look the last fstat) > I don't think it is a problem as long as your /tmp is nfs. > You already have to know that by the result of your '/boot' test. Okay, but with /boot it has the behaviour expected, tail do not die. But with a /tmp with aufs tail dies. > If you have time, please try strace for the delay problem and let me > know which systemcall took a long time. The systemcall returns imediatly. It take times to make effect. Bona ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
