Lists

Open Menu Close Menu

Terms and Conditions
Lists hosted on this site
Email the Postmaster
Tips for posting to public mailing lists

Re: Seeking cooperation from mds and Spotlight

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Seeking cooperation from mds and Spotlight

Subject: Re: Seeking cooperation from mds and Spotlight
From: Thomas Tempelmann <email@hidden>
Date: Wed, 18 Dec 2013 10:21:06 +0100

Lund,

A few thoughts:

Currently mds would appear to work, but nothing is ever stored in its index
database. Ie, if you create new file/directory, those will generally show.
But nothing scanned/pre-existing is. Nor will mds remember anything after
unmount, so there is no persistent data.

I am just guessing here, but could it be that your ZFS volume is on an external disk? OSX makes a difference between internal and external disk devices in serveral places, and maybe mds does that, too. In that case, try creating a ZFS volume on an internal disk and see if that helps. If so, there are tricks to make an external disk appear internal, I think.

1)

vnop_searchfs. We currently do not support it, but we don't claim to
support it either. Darwin sources suggest that it works "around it" if it
receives ENOTSUP, and 'msdos' kext does not have vnop_searchfs and works
with mds.

No, the OS does not work around it. Instead, applications can query if a volume supports it (aka FSCatalogSearch), and are then required to traverse the dir tree in the classical way by reading each dir separately.

Support for searchfs makes sense if your file system’s directory is organized in clusters or in one big file, because then searching can be made much faster that instead of traversing recursively from the root, as it reduces seeks and also reduces the amount of data being moved between the kernel (VFS) and the user app doing the search.

For instance, download my search tool “Find Any File” (http://apps.tempel.org) that relies on searchfs, but can also fall back to the slow recursive mode. Since ZFS is made, apart from data safely, for large volumes and many files, I suggest you look into supporting searchfs eventually because it’ll make your users happy if they can use FAF or EasyFind to search for file names etc. on the disk - without mds! The searchfs code for HFS is open source, so you can see there how it works. It’s not difficult to implement if you can read ZFS dirs as a single stream inside your VFS.

But also know that mds does not rely on searchfs at all. searchfs is rather the old search method supported by Macs for 20 years, and is limited to searching for directory data, not file content.

mds only really works if mounted with diskutil? Currently, we mount ZFS
with regular mount(2) call, and not via diskutil and Disk Arbitration.
Would a HFS+ filesystem mounted with mount(2) also fail with mds? Should we
create a fs.bundle, with zfs.util -k to reply with a UUID for DA, and use
diskutil to mount?

The mount command does not make the new mount available as a new volume to OSX, AFAIK. Only diskutil / diskarb do that.

And mfs relies on volumes. In fact, mds also relies on fsevents, in order to learn of file changes. It might well be that mount does not invoke fsevents to make mds aware of the new node. Just guessing here, again, though.

3)

FinderInfo appears to store the data for VolumeUUID (MD5), stored under the
filesystem's root. But this appears to only happen from hfs.util and DA
requesting UUID. Not if you mount HFS+ manually. Creating my own FinderInfo
makes no difference.

Yeah. Same as (2). I suggest you stop using mount and get used to mounting your ZFS as a proper OSX volume using diskutil or whatever else is there.

--
Thomas Tempelmann, http://www.tempel.org/
Follow me on Twitter: http://twitter.com/#!/tempelorg
Read my programming blog: http://blog.tempel.org/

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

Follow-Ups:
- Re: Seeking cooperation from mds and Spotlight
  - From: Jorgen Lundman <email@hidden>
- Re: Seeking cooperation from mds and Spotlight
  - From: Alexander Dimitrov <email@hidden>

References:
	>Seeking cooperation from mds and Spotlight (From: Jorgen Lundman <email@hidden>)

Prev by Date: Seeking cooperation from mds and Spotlight
Next by Date: Re: Seeking cooperation from mds and Spotlight
Previous by thread: Seeking cooperation from mds and Spotlight
Next by thread: Re: Seeking cooperation from mds and Spotlight
Index(es):
- Date
- Thread