mkdir is hanging

[ninkisa]

Hello,

I'm using MFS via the go-ipfs-api and I'm running multiple goroutines against ipfs
It looks that mkdir dir command is hanging
I'm attaching goroutine dump
ipfs.stacks.txt

goroutine 4205 [semacquire, 113 minutes]:
sync.runtime_SemacquireMutex(0xc000b04cbc, 0x0)
	/usr/lib/go/src/runtime/sema.go:71 +0x3d
sync.(*Mutex).Lock(0xc000b04cb8)
	/usr/lib/go/src/sync/mutex.go:134 +0x109
github.com/ipfs/go-mfs.(*Directory).Child(0xc000b04c80, 0xc0021b6d72, 0x6, 0x0, 0x0, 0x0, 0x0)
	pkg/mod/github.com/ipfs/go-mfs@v0.0.7/dir.go:200 +0x47
github.com/ipfs/go-mfs.Mkdir(0xc001269290, 0xc0021b6d60, 0x1f, 0x100, 0x0, 0x0, 0x2, 0xc000305b20)
	pkg/mod/github.com/ipfs/go-mfs@v0.0.7/ops.go:154 +0x177
github.com/ipfs/go-ipfs/core/commands.glob..func71(0xc001ef13b0, 0x1ac57e0, 0xc0001d7300, 0x16ccf00, 0xc0006c2de0, 0x0, 0x0)
	pkg/mod/github.com/ipfs/go-ipfs@v0.4.22/core/commands/files.go:847 +0x1d8
github.com/ipfs/go-ipfs-cmds.(*Command).call(0x23b1fe0, 0xc001ef13b0, 0x1ac57e0, 0xc0001d7300, 0x16ccf00, 0xc0006c2de0, 0xd0000000149974f, 0xc0014975e0)

Can you help with this?

Thank you in advance

[Stebalien]

The issue is that we're trying to find a block on the network while holding that lock. Specifically, Child takes the lock and then eventually calls childFromDag. This may need to fetch something from the network.

The correct solution is to do whatever we need to do with the lock, unlock, fetch the next block from the dag, relock.

[Stebalien]

Specifically:

1. We take the lock here: https://github.com/ipfs/go-mfs/blob/f9f98206cc255d18add8909f5586f41e89e3e6e2/dir.go#L200.
2. Call childUnsync which calls childNode: https://github.com/ipfs/go-mfs/blob/f9f98206cc255d18add8909f5586f41e89e3e6e2/dir.go#L225
3. In childNode, we call childFromDag: https://github.com/ipfs/go-mfs/blob/f9f98206cc255d18add8909f5586f41e89e3e6e2/dir.go#L148.
4. childFromDag calls https://github.com/ipfs/go-mfs/blob/f9f98206cc255d18add8909f5586f41e89e3e6e2/dir.go#L214 which may use the underlying DAG.

Unfortunately, d.unixfsDir.Find is not threadsafe so this isn't going to be all that easy to fix.

[schomatis]

I think the given the architecture deficiencies in MFS right now the best we can do is to add a timeout option exposed so the go-ipfs consumer can set it to a value that satisfies expectations (I'm hoping there are other sane timeouts already set there we can derive this one from).

On the lock issue, it was never clear by design what were the expectations on it so investing more time now reworking this without a clear bigger picture of where that package is going doesn't seem like a good investment. Under the current uncertainty I might even claim I want to lock while fetching, otherwise in that "dead" time another call for example could have created a new child by that name that I would be overwriting later.

[schomatis]

cc @aschmahmann to confirm if we can go in the timeout direction.