Memory leak when Attribute.Valid is set to 0

[ncw]

In rclone recently I decided to set the attribute caching time to 0s.

This stopped a number of file system oddities I was seeing.

However it seems to have provoked a possible bug in this library. Here is the background: rclone/rclone#2157

The reason why I think it is the library is that if I set the attribute caching to non-zero the memory leak disappears, and the pprof is quite suggestive:

(pprof) list allocMessage
Total: 1.83GB
ROUTINE ======================== github.com/ncw/rclone/vendor/bazil.org/fuse.allocMessage in /home/ncw/go/src/github.com/ncw/rclone/vendor/bazil.org/fuse/fuse.go
    1.76GB     1.76GB (flat, cum) 96.03% of Total
         .          .    419:var reqPool = sync.Pool{
         .          .    420:	New: allocMessage,
         .          .    421:}
         .          .    422:
         .          .    423:func allocMessage() interface{} {
    1.76GB     1.76GB    424:	m := &message{buf: make([]byte, bufSize)}
         .          .    425:	m.hdr = (*inHeader)(unsafe.Pointer(&m.buf[0]))
         .          .    426:	return m
         .          .    427:}
         .          .    428:
         .          .    429:func getMessage(c *Conn) *message {

Any thoughts?

It setting attribute caching to zero a really bad idea?

[tv42]

That sounds like you caused a lot more FUSE requests to happen, by disabling the cache.

I'm not sure why they'd stay inuse, apart from sync.Pool doing something non-optimal (again).

I have a near-rewrite of the core bits of the FUSE library that changes how it manages memory, and it shouldn't have these kinds of issues. Just need to find enough time to get it to feature parity..

[ncw]

OK! I'll set the attribute timeout back to 1s in the mean time.