[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fuse-devel
Subject:    [fuse-devel] Kernel bug with entry TTL and link?
From:       Han-Wen Nienhuys <hanwenn () gmail ! com>
Date:       2011-10-02 17:31:48
Message-ID: CAOw_e7amkFDn8W9FqBjVZEt5HT_unu0KoKdM0kyYjF9C-3WYGA () mail ! gmail ! com
[Download RAW message or body]

Hi there,

I am debugging a strange problem with the Link operation not working correctly.

The symptom is as follows:

echo hoi > x/a ;  ln /tmp/x/a /tmp/x/b    # x is the fuse mount
ln: failed to create hard link `/tmp/x/b' => `/tmp/x/a': No such file
or directory

The relevant part of the strace is:

stat64("/tmp/x/b", 0xbfa93cec)          = -1 ENOENT (No such file or directory)
lstat64("/tmp/x/a", {st_mode=S_IFREG|0664, st_size=4, ...}) = 0
linkat(AT_FDCWD, "/tmp/x/a", AT_FDCWD, "/tmp/x/b", 0) = -1 ENOENT (No
such file or directory)

curiously, the Link operation is never issued against filesystem.
The filesystem has a 1 second entry TTL, and the problem goes away if
either:

1. I try link to an existing file
2. I set the entry TTL to 0.

I tried to isolate the problem in a unittest, but for some reason it
only surfaces if I use GNU coreutils ln, but not if I try directly
with Go's os.Link operation.

You can reproduce by fetching and compiling the latest go-fuse release
and running

cd /tmp ; mkdir x; mkdir rw
~/vc/go-fuse/example/unionfs/unionfs -portable -debug  -mem
-negative_ttl 0.0 -entry_ttl 1.0 x rw /

Here is the debug trace:

Dispatch: INIT, NodeId: 0. data: {7.16 Ra 0x20000
DONT_MASK,EXPORT_SUPPORT,BIG_WRITES,ASYNC_READ,ATOMIC_O_TRUNC,POSIX_LOCKS}
Serialize: INIT code: OK value: {7.13 Ra 0x20000 BIG_WRITES,ASYNC_READ
9/12 Wr 0xf000}
Dispatch: LOOKUP, NodeId: 1. names: [a] 2 bytes
Serialize: LOOKUP code: 2=no such file or directory value:
Dispatch: CREATE, NodeId: 1. data: {0100664
[TRUNC,CREAT,WRONLY,LARGEFILE] (02)} names: [a] 2 bytes
Serialize: CREATE code: OK value: {{2 E1.000000000 A1.000000000
{M0100664 S=0 L=1 0:0 0*0 0:2 A 1317575849.051247000 M
1317575849.051247000 C 1317575849.051247000}} {Fh 410433696 }}
Dispatch: FLUSH, NodeId: 2. data: {Fh 410433696}
Serialize: FLUSH code: OK value:
Dispatch: GETXATTR, NodeId: 2. names: [security.capability] 20 bytes
Serialize: GETXATTR code: 38=function not implemented value:
Dispatch: WRITE, NodeId: 2.  4 bytes
Serialize: WRITE code: OK value:
Dispatch: FLUSH, NodeId: 2. data: {Fh 410433696}
Serialize: FLUSH code: OK value:
Dispatch: RELEASE, NodeId: 2. data: {Fh 410433696 WRONLY,LARGEFILE  L0}
Serialize: RELEASE code: OK value:
Dispatch: LOOKUP, NodeId: 1. names: [b] 2 bytes
Serialize: LOOKUP code: 2=no such file or directory value:
Dispatch: GETATTR, NodeId: 2. data: {Fh 0}
Serialize: GETATTR code: OK value: {A1.000000000 {M0100664 S=4 L=0 0:0
8*0 0:2 A 1317575849.051247000 M 1317575849.051247000 C
1317575849.051247000}}
Dispatch: LOOKUP, NodeId: 1. names: [b] 2 bytes
Serialize: LOOKUP code: 2=no such file or directory value:


-- 
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
fuse-devel mailing list
fuse-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel
[prev in list] [next in list] [prev in thread] [next in thread]