“mds”用什么来迭代挂载的文件系统？答案

【问题标题】：What does "mds" use to iterate the mounted file systems?“mds”用什么来迭代挂载的文件系统？
【发布时间】：2014-09-22 04:08:02
【问题描述】：

在过去的几年里，我一直密切关注 OS X 的 Open ZFS 开发场景。自从 Greenbytes 等出现可悲的问题以来，过去几个月里事情取得了显着进展，但我很高兴看到我们终于接近获得真正的 Spotlight 支持。我注意到this email 前几天从 Jorgen Lundman （他投入了大量个人时间来推动这项工作并为社区做出贡献）经过，并认为这里的其他人可能有兴趣加入这个他的话题关于在 OS X 上实现对 ZFS 的 Spotlight 支持：

总而言之，我认为这个问题的症结在于：

So then, what does "mds" use to iterate the mounted file systems? I do not
think the sources for "Spotlight-800.28" was ever released so we can't just
go look and learn, like we did for xnu, and IOkit.

It doesn't use the BSD getfsstat(), more likely it asks IOKit, and for some
reason rejects the lower mounts.

以及为方便起见的电子邮件正文：

Hey guys,

So one of our long-term issues in OpenZFSonOSX is to play nice with Spotlight.

We have reached the point where everything sometimes pretends to work.

For example;

# mdfind helloworld4
/Volumes/hfs1/helloworld4.jpg
/Volumes/hfs2/helloworld4.jpg
/Volumes/zfs1/helloworld4.jpg
/Volumes/zfs2/helloworld4.jpg

Great, picks it up in our regular (control group) HFS mounted filesystems,
as well as the 2 ZFS mounts.


Mounted as:

/dev/disk2 on /Volumes/zfs1 (zfs, local, journaled)
/dev/disk2s1 on /Volumes/zfs2 (zfs, local, journaled)

# diskutil list

/dev/disk1
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *42.9 GB    disk1
   1:                        ZFS                         42.9 GB    disk1s1
   2: 6A945A3B-1DD2-11B2-99A6-080020736631               8.4 MB     disk1s9

/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:             zfs_pool_proxy FEST                   *64.5 MB    disk2
   1:       zfs_filesystem_proxy ssss                    64.5 MB    disk2s1


So you can see, the actual pool disk is /dev/disk1, and the fake nodes we
create for mounting as /dev/disk2*, as it appears to be required by
Spotlight to work at all. We internally also let the volumes auto-mount,
from issuing "diskutil mount -mountPoint %s %s".

We are not a VOLFS, so there is no ".vol/" directory, nor will mdutil -t
work. But these two points are true for MS-DOS as well, and that does work
with Spotlight.


We correctly reply to zfs.fsbundle's zfs.util for "-p" (volume name) and
"-k" (get uuid), done pre-flight to mounting by DA.


Using FSMegaInfo tool, we can confirm that stat, statfs, readdir, and
similar tests appear to match that of HFS.



So then, the problem.



The problem comes from mounting zfs inside zfs. Ie,

When we mount

/Volumes/hfs1/
/Volumes/hfs1/hfs2/
/Volumes/zfs1/
/Volumes/zfs1/zfs2/

# mdfind helloworld4
/Volumes/hfs1/helloworld4.jpg
/Volumes/hfs1/hfs2/helloworld4.jpg
/Volumes/zfs1/helloworld4.jpg

Absent is of course, "/Volumes/zfs1/zfs2/helloworld4.jpg".

Interestingly, this works

# mdfind -onlyin /Volumes/zfs1/zfs2/ helloworld4
/Volumes/zfs1/zfs2/helloworld4.jpg


And additionally, mounting in reverse:

/Volumes/hfs2/
/Volumes/hfs2/hfs1/
/Volumes/zfs2/
/Volumes/zfs2/zfs1/

# mdfind helloworld4
/Volumes/hfs2/helloworld4.jpg
/Volumes/hfs2/hfs1/helloworld4.jpg
/Volumes/zfs2/helloworld4.jpg


So whichever ZFS filesystem was mounted first, works, but not the second.
So the individual ZFS filesystems are both equal. It is as if it doesn't
realise the lower mount is its own device.


So then, what does "mds" use to iterate the mounted fileystems? I do not
think the sources for "Spotlight-800.28" was ever released so we can't just
go look and learn, like we did for xnu, and IOkit.

It doesn't use the BSD getfsstat(), more likely it asks IOKit, and for some
reason rejects the lower mounts.


Some observations:

# /System/Library/Filesystems/zfs.fs/zfs.util -k disk2
87F06909-B1F6-742F-7355-F0D597849138

# /System/Library/Filesystems/zfs.fs/zfs.util -k disk2s1
8F60C810-2D29-FCD5-2516-2D02EED4566B

# grep uu /Volumes/zfs1/.Spotlight-V100/VolumeConfiguration.plist
          <key>uuid.87f06909-b1f6-742f-7355-f0d597849138</key>

# grep uu /Volumes/zfs1/zfs2/.Spotlight-V100/VolumeConfiguration.plist
          <key>uuid.8f60c810-2d29-fcd5-2516-2d02eed4566b</key>



Any assistance is appreciated, the main issue tracking Spotlight is;
https://github.com/openzfsonosx/zfs/issues/116

The branch for it;
https://github.com/openzfsonosx/zfs/tree/issue116

vfs_getattr;
https://github.com/openzfsonosx/zfs/blob/issue116/module/zfs/zfs_vfsops.c#L2307

【问题讨论】：

这里真的有问题吗？
是的@MikeW，请仔细阅读它从哪里开始“那么，问题来了。”
很难看出这是一个适合Stack Overflow 的问题。问题似乎与 ZFS 文件系统的特殊性有关。这不是编程问题，或者看起来不是，而且远不清楚您的要求。
这实际上是 OS X 文件系统和 kext 开发人员的问题，而不是 ZFS 本身。这是一个关于了解mds 用于迭代已挂载文件系统的编程问题。请参阅我上面的修改来总结这一点。我还修改了标题以更好地总结和澄清这一点。

标签： macos filesystems darwin kernel-extension zfs

【解决方案1】：

这似乎是由于 vfs_vget 方法中的一些未记录的期望，完全基于 inode 编号查找条目。即stat /.vol/16777222/1102011 预计 vfs_vget 在此处正确设置 vnode_name，使用类似 vnode_update_identity() 或类似的调用。

【讨论】：