remove usage of d_revalidate

[cyphar]

This is a tracking issue for the main blocker of #8648, which is that ZFS makes use of d_revalidate. This leads to Linux treating ZFS as a "remote" filesystem (like NFS) and thus things like overlayfs won't work with ZFS.

It seems to me that the solution is to make it so that rollbacks (which appear to be the only reason we have zpl_revalidate) correctly invalidate the dcache so that we don't need to use d_revalidate (but I'm not super familiar with dcache internals so this is going to be fun).

[behlendorf]

That's right. You might be able to do something relatively straight forward like invalidate the entire dentry cache as part of the rollback. That wouldn't be great for performance, but rollbacks should be a rare operation.

The only other gotcha here is that d_revalidate is also leveraged to prevent active snapshots automounted under .zfs/ from being automatically unmounted. This logic will need to be moved somewhere else.

[snajpa]

Maybe a noob question: why would the entire dcache need to be invalidated?

My understanding is, that dcache can be flushed per superblock instance, as is already done in the rollback path @
https://github.com/zfsonlinux/zfs/blob/master/module/os/linux/zfs/zfs_vfsops.c#L1710
-> maybe we can just do it once more in zfs_resume_fs before the teardown lock release @
https://github.com/zfsonlinux/zfs/blob/master/module/os/linux/zfs/zfs_vfsops.c#L2236;

And as for the automounted snapshots, would a new taskq dedicated to periodically calling zfsctl_snapshot_unmount_delay for all mounted snapshots? Every time a snapshot would be mounted, a task would be queued, which would first check, whether the snapshot is mounted (in case user umounted it) and then call zfsctl_snapshot_unmount_delay and after finishing successfully it would requeue itself to the taskq.

Is that approach OK? I'd like to take this one on, but I'll need a little guidance, please ;)

[snajpa]

Well, with a little ugly hack to make Docker run without a patch (so it doesn't detect ZFS and runs with OverlayFS) - I've got OverlayFS with unpatched Docker in LXC container now :)

https://github.com/vpsfreecz/zfs/commits/ovl

Example docker session:

https://paste.vpsfree.cz/Onh4XtG5/

@cyphar would you mind if I send this as a new PR for a fresh review?

[cyphar]

@snajpa I don't mind you sending it as long as you keep my Signed-off-bys for the patches I wrote. Thanks for carrying this, I think I bit off a bit more than I expected when I started working on this. But I think there are a few things left to do in your branch if you wanted to deal with all of the discussion:

• Remove TX_WHITEOUT and re-implement it as TX_RENAME+TX_CREATE.
• Drop zfs_drop_nlink as suggested.
• Complete the rest of the cleanups.

[snajpa]

I'll keep your original patches as you wrote them (+-, only they're rebased) - if that's not in conflict with some guidelines I've yet to read :)

[snajpa]

I'm not exactly clear on a few details, so I've started a disscussion on zfs-devel (as I'll go ahead and try to rewrite this without the new txtypes for me to test anyway). Best way for me to learn is to fail often and fast :-D

https://zfsonlinux.topicbox.com/groups/zfs-devel/Tebb527f71cbeed1e/spafeatureincr-decr-context

[cyphar]

@behlendorf Can you re-open this, since I think the zpl_revalidate change was reverted? It will be fixed in my carry of #9414 but probably best to keep it open until it's fixed.

[behlendorf]

Sure, reopened.

[stale]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

[cyphar]

Still an issue.