Re: Seeking cooperation from mds and Spotlight
Re: Seeking cooperation from mds and Spotlight
- Subject: Re: Seeking cooperation from mds and Spotlight
- From: Jorgen Lundman <email@hidden>
- Date: Thu, 19 Dec 2013 09:07:11 +0900
Thomas Tempelmann wrote:
>
> 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.
Worth double checking, although I think I tested msdos file-systems marked
external, and mds played ball there.
>
> 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.
Sorry yes, I didn't mean that the Darwin kernel works around it, but mds
does (works with msdos). Whereas the kernel certainly handles the lack of
getattrlist by calling getattr iteratively, which is nice.
>
> 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.
It is certainly on the TODO list, but leaning more toward "nice feature"
when we are currently in the "fix things actually broken" phase :)
vnop_searchfs takes a ridiculous amount of arguments, but reading HFS+
implementation of it, quite a few of them are not used.
> 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.
fsevents do show up either way, from what I can tell. But interestingly enough;
newfs_hfs
mount -t hfs
will break mds.
Whereas format HFS with diskutility (mounts it once with DA), then use
mount -t hfs will work. Possibly that first DA mount does something that is
required.
> 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.
>
It is worth testing more then. The issue is further complicated with that a
ZFS pool can have many mounted filesystems, and we would have to fool DA
somehow to trigger mounts, for each filesystem
--
Jorgen Lundman | <email@hidden>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
_______________________________________________
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