- 30 Jan, 2019 6 commits
-
-
Han-Wen Nienhuys authored
This fixes race conditions found by the race detector.
-
Han-Wen Nienhuys authored
If we call AddEntry/RemoveEntry before the update to the deletion list in storage, a poorly timed cache refill that happens just before the storage update will result in storing the old state for as long as the cache's TTL.
-
Han-Wen Nienhuys authored
-
Han-Wen Nienhuys authored
-
Han-Wen Nienhuys authored
-
Han-Wen Nienhuys authored
-
- 23 Jan, 2019 1 commit
-
-
Jakob Unterwurzacher authored
This makes it clear when (and why) the filesystem was unmounted. Example output: $ gocryptfs -fg -nosyslog -fusedebug a b Password: Decrypting master key Filesystem mounted and ready. 2019/01/23 21:52:59 rx 2: ACCESS i1 {r} 2019/01/23 21:52:59 tx 2: OK 2019/01/23 21:52:59 rx 3: LOOKUP i1 [".Trash"] 7b 2019/01/23 21:52:59 tx 3: OK, {i0 g0 tE=1s tA=0s {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000}} 2019/01/23 21:52:59 rx 4: LOOKUP i1 [".Trash-1026"] 12b 2019/01/23 21:52:59 tx 4: OK, {i0 g0 tE=1s tA=0s {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000}} 2019/01/23 21:53:02 received ENODEV (unmount request), thread exiting 2019/01/23 21:53:02 received ENODEV (unmount request), thread exiting 2019/01/23 21:53:02 received ENODEV (unmount request), thread exiting
-
- 11 Jan, 2019 1 commit
-
-
Kirill Smelkov authored
d1c826d1 ("fuse: increase signal/noise in log messages", https://github.com/hanwen/go-fuse/pull/249) changed log to use abbreviations in the name of improving signal/noise ratio. However it might be not evident offhand what an abbreviation means. Add a short reference in the readme with the summary on how to read the log and a short example. The summary is incomplete - for example I don't describe Fh and other attributes that d1c826d1 did not change. I propose we review logging more, e.g. consider doing `Fh X` -> `fX` and maybe similarly for other fields, and while doing so, also populate/update the summary and example in the readme. In other words it is good to document current state, but it is not fixed in stone and can be evolved.
-
- 08 Jan, 2019 1 commit
-
-
Kirill Smelkov authored
- use tA=...s instead of `A...` or `AttrValid=...` for time(Attr valid); - use tE=...s instead of `EntryValid` for time(Entry valid); - use iX instead of `NodeId: X` for inode X; - use gX instead of `Generation=X` for generation X; - use `[<off> +<size>)` instead of `off <off> sz <sz>`; - use rx uniq: Op iX opargs tx uniq: status reply... instead of Dispatch uniq: Op NodeId: X opargs Serialize uniq: Op code: status reply... for received/replied messages; - use `["file1", "file2"]` instead of `names: [file1, file2]` for filenames. - use `xb` instead of `x bytes` - for replied data, also log data content, but only up to first 8 bytes. This does not flood the log, but at the same time makes filesystem diagnostics easier.
-
- 17 Dec, 2018 2 commits
-
-
Kirill Smelkov authored
nodeMap.Handle(&node) == 0 means the kernel does not currently have an entry for this node in its dentry cache. And the kernel would return ENOENT if we would try to send it notify store message with nodeID it does not currently know. So return proper ENOENT when we see that currently there is no handle for the inode, instead of returning EINVAL, which means that call arguments - e.g. off is invalid. NOTE contrary to cache retrieve (where we could turn such error into empty OK read; see previous patch) for cache store we cannot ignore the error. Fixes bdca0e6a (Add support for store notify). See also: https://github.com/hanwen/go-fuse/pull/246#discussion_r242050595
-
Kirill Smelkov authored
This patch continues bdca0e6a (Add support for store notify) and adds corresponding support for counterpart to cache-store - to retrieve an inode data from kernel cache. As it was already noted in bdca0e6a, FUSE protocol provides primitives for pagecache control: to invalidate a data region for inode (notify_inval_inode), to store data into inode kernel's cache (notify_store), and to retrieve data from inode kernel's cache (notify_retrieve). For the latter 2 FUSE protocol messages and brief documentation about semantic can be seen here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/fuse.h?id=v4.19-rc6-177-gcec4de302c5f#n68 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/fuse.h?id=v4.19-rc6-177-gcec4de302c5f#n756 https://git.kernel.org/linus/a1d75f2582 https://git.kernel.org/linus/2d45ba381a In short, to retrieve data from kernel cache, filesystem server sends S > C NOTIFY_RETRIEVE_CACHE{notifyUnique, inode, offset, size} and if that message was sent correctly, the kernel sends back another write-style message with unique=notifyUnique S < C NOTIFY_REPLY{inode, offset, size, data} Since so far there were no cases when a server was querying the kernel, and the reply comes as separate kernel "request", we have to add infrastructure for tracking such in-flight queries. This is done by adding Server.retrieveTab and friends. Otherwise the implementation is straightforward. A particular note is that from a user-level API point of view we are not following e.g. libfuse to register a callback to be invoked upon reply, but instead provide {Inode,File}RetrieveCache that synchronously send notify query and wait for kernel's reply. This fits more naturally to Go and is easier to use.
-
- 12 Dec, 2018 2 commits
-
-
Han-Wen Nienhuys authored
-
Han-Wen Nienhuys authored
-
- 11 Dec, 2018 1 commit
-
-
Natalie Fioretti authored
-
- 27 Oct, 2018 1 commit
-
-
Tsuyoshi Hombashi authored
-
- 26 Oct, 2018 1 commit
-
-
Natalie Fioretti authored
-
- 15 Oct, 2018 1 commit
-
-
Kirill Smelkov authored
I've made the notes for myself, but then though it could be maybe useful as the package documentation.
-
- 11 Oct, 2018 2 commits
-
-
Kirill Smelkov authored
- it is not NOTIFY_INVAL_DELETE, but just NOTIFY_DELETE as the kernel is notified of entry being deleted and there is no invalidation here. uapi/linux/fuse.h does not use "_INVAL_" for NOTIFY_DELETE neither. - similarly for "notify store/retrieve" _INVAL_ is not appropriate and neither is used in uapi/linux/fuse.h . However since we took more explicit approach for "notify store/retrieve" naming (see bdca0e6a "Add support for store notify") let's also add _CACHE suffix for "notify store/retrieve" operation names for consistency and for being less ambiguous. - for inode/entry invalidation operations, let's use _INVAL_ in internal _OP_NOTIFY_*, similarly to how it is used in corresponding NOTIFY_* constant. For example: _OP_NOTIFY_ENTRY -> _OP_NOTIFY_INVAL_ENTRY (corresponds to NOTIFY_INVAL_ENTRY)
-
Han-Wen Nienhuys authored
-
- 10 Oct, 2018 1 commit
-
-
Han-Wen Nienhuys authored
The debug printout in the -race tests interferes with timing, so it makes race conditions less likely to appear.
-
- 09 Oct, 2018 9 commits
-
-
Han-Wen Nienhuys authored
-
Han-Wen Nienhuys authored
There was a thinko in PathFS.Lookup: if GetAttr returns OK, we did not copy the attribute if there was a known child with that name. This lead returning status OK, with a zeroed out Attr structure. The 0 mode would sometimes lead to I/O errors, as files without type are not allowed. Fixes #239
-
Han-Wen Nienhuys authored
Otherwise, printing inodes generates panics, because of concurrent writes.
-
Han-Wen Nienhuys authored
-
Han-Wen Nienhuys authored
The CAP_POSIX_ACL and CAP_HANDLE_KILLPRIV opcodes were swapped.
-
Kirill Smelkov authored
@rfjakob reports that after bdca0e6a (Add support for store notify) build got broken on ARM: $ GOARCH=arm go build ./example/loopback # github.com/hanwen/go-fuse/fuse fuse/server.go:490:11: constant 4294967295 overflows int fuse/server.go:492:9: constant 4294967295 overflows int Fix it by amending "store notify" patch by chunking data into 2GB instead of full-32bit-range 4GB.
-
Han-Wen Nienhuys authored
These two tests failed in recent travis runs.
-
Han-Wen Nienhuys authored
This helps debugging timing issues
-
Han-Wen Nienhuys authored
-
- 08 Oct, 2018 3 commits
-
-
Jakob Unterwurzacher authored
gocryptfs user Felix Lechner reported a nil pointer dereference in GetAttr: https://github.com/rfjakob/gocryptfs/issues/260 The crash is in line n.setClientInode(fi.Ino) because fi is nil. This can happen when file.GetAttr() returns an error code other than ENOSYS and EBADF. For gocryptfs, this can only happen when an open file descriptor breaks. In this case it was triggered by a failing NFS volume. Fix the crash by erroring out for error codes that are not handled by the retry-by-path logic.
-
Kirill Smelkov authored
Current state is: fuse's godoc package-level description is completely empty because there is a blank link between package-level description and package clause. Yes, a user still has to go through api.go and read it in full, but having at least something for the description is a better start, and removing one line is easy. We already do it this way e.g. for nodefs and in other places.
-
Kirill Smelkov authored
I'm writing a networked filesystem which reads data in 2MB blocks from remote database. However read requests from the kernel come in much smaller sizes - for example 4K-128K. Since it would be very slow to refetch the 2MB block for e.g. every consecutive 4K reads, a cache for fetched data is needed. A custom cache would do, however since the kernel already implements pagecache to cache file data, it is logical to use it directly. FUSE protocol provides primitives for pagecache control. We already have support for e.g. invalidating a data region for inode (InodeNotify), but there is more there. In particular it is possible to store and retrieve data into/from the kernel cache with "store notify" and "retrieve notify" messages: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/fuse.h?id=v4.19-rc6-177-gcec4de302c5f#n68 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/fuse.h?id=v4.19-rc6-177-gcec4de302c5f#n756 https://git.kernel.org/linus/a1d75f2582 https://git.kernel.org/linus/2d45ba381a This patch adds support for "store notify". Adding support for "retrieve notify" might be added later since a) it is not needed right now, and b) supporting it is a bit more work since the kernel sends a separate reply with data and infrastructure has to be added to glue it back to original "retrieve notify" server-originated request. For user-visible API I decided not to duplicate FUSE-protocol naming 1-1 and to be more explicit in names - emphasizing it is about cache control - it is e.g. InodeNotifyStoreCache instead of InodeNotifyStore, and for retrieving it (hopefully) should be just InodeRetrieveCache instead of InodeNotifyRetrieveCache and a separate callback. Thanks beforehand, Kirill
-
- 01 Oct, 2018 3 commits
-
-
Kirill Smelkov authored
Current code was requiring that both in.Major >= maj _and_ in.Minor >= min this way e.g. kernel's 7.27 would satisfy requirement of e.g. 7.25, but 8.1 won't do. Fix it.
-
Kirill Smelkov authored
out.Attr is already of type fuse.Attr .
-
Kirill Smelkov authored
-
- 24 Sep, 2018 1 commit
-
-
Han-Wen Nienhuys authored
Improve test to eliminate backing FS semantics
-
- 31 Aug, 2018 3 commits
-
-
Sebastien Binet authored
-
Sebastien Binet authored
-
Sebastien Binet authored
-
- 10 Aug, 2018 1 commit
-
-
Chris Marget authored
On a Linux system with go-fuse program running as root, the mount is performed by calling /bin/fusermount, and the unmount is performed with syscall.Unmount() This creates a problem on systems (CentOS 6) with a static-but-edited-by-mount /etc/mtab file. - fusermount adds a line to mtab when the go-fuse program starts - syscall.Unmount() doesn't edit the file on program exit - subsequent invocations of the program fail to mount with: "Mount fail: fusermount exited with code 256" Deleting the now-inaccurate mtab entry clears things up. There's probably a workaround by adding "-n" option so that mount doesn't edit mtab in the first place, but it's not obvious where to insert that when starting with the hello.go example.
-