All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Hejtmanek <xhejtman@ics.muni.cz>
To: linux-nfs@vger.kernel.org
Subject: NFS bug with utime/file create
Date: Thu, 7 Oct 2010 18:06:59 +0200	[thread overview]
Message-ID: <20101007160659.GP12489@ics.muni.cz> (raw)

Hello,

I noticed an interesing bug in 2.6.26 kernel, not sure whether this has been
fixed in newer version or not.

I have an application, that does basically the following code:
int
main(int argc, char *argv[]) {
        int fd = open(argv[1], O_WRONLY|O_CREAT|O_TRUNC, 0666);
        char buff[300];
        write(fd, buff, 300);
        while(1) {
                utime(argv[1], NULL);
                sleep(30);
        }
        return 0;
}


another application that runs on a different client does:
17:57:30.605304 nanosleep({24, 0}, {24, 0}) = 0
17:57:54.605526 stat64("/storage/home/xhejtman/gangadir/workspace/xhejtman/LocalXML/0",
{st_mode=S_IFDIR|0700, st_size=59, ...}) = 0
17:57:54.606029 mkdir("/storage/home/xhejtman/gangadir/workspace/xhejtman/LocalXML/0/output",
0777) = -1 EEXIST (File exists)
17:57:54.606414 open("/storage/home/xhejtman/gangadir/workspace/xhejtman/LocalXML/0/output/__jobstatus__",
O_RDONLY|O_LARGEFILE) = 3
17:57:54.607073 fstat64(3, {st_mode=S_IFREG|0644, st_size=300, ...}) = 0
17:57:54.607230 mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb74ef000
17:57:54.607325 _llseek(3, 0, [0], SEEK_CUR) = 0
17:57:54.607408 read(3, "\0\0\0\0\0\0\0\0\336e\356,\345\177\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 300
17:57:54.607765 read(3, "", 1048576)    = 0
17:57:54.607854 close(3)                = 0
17:57:54.608128 munmap(0xb74ef000, 1048576) = 0
17:57:54.608224 stat64("/storage/home/xhejtman/gangadir/workspace/xhejtman/LocalXML/0/output/__jobstatus__",
{st_mode=S_IFREG|0644, st_size=300, ...}) = 0

The first application tries to create a file (something like:
open("time_elapsed.txt", O_WRONLY|O_CREAT|O_TRUNC, 0666) (*)

at this point, it emits PUTFH, SAVEFH, OPEN, GETFH, GETATTR, RESTOREFH,
GETATTR compount. The server replies with NFS4ERR_EXPIRED.

The client tries to RENEW, the server replies NFS4ERR_EXPIRED.

The client restarts using SETCLIENTID and so on. During this phase, the first
application emits utime call. It seems that orignial open (*) get lost and system
deadlocks. 

Using NFS debugs, I can see a warning, that the lease is not expired (from the
client's point of view, but the server is conviced that the lease is expired).

I can reliably reproduce it with diane/ganga framework. I cannot fully reproduce it
just using simple C programs. 


Is there something I could do?

-- 
Lukáš Hejtmánek

             reply	other threads:[~2010-10-07 16:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-07 16:06 Lukas Hejtmanek [this message]
2010-10-21 19:56 ` NFS bug with utime/file create J. Bruce Fields
2010-10-21 19:59   ` Lukas Hejtmanek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101007160659.GP12489@ics.muni.cz \
    --to=xhejtman@ics.muni.cz \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.