For people (like myself) that dont have a SSD pool, but do have a SSD for the boot pool, it would be nice to use it for the TrueSearch/Spotlight search index. I understand the logic behind not wanting to partition the boot pool to store data, but the search index data doesnt really matter at all since it can be regenerated at any time. Would be fantastic to be able to utilize the unused space on that disk and get the advantage of a fast search without needing to add an entire SSD pool.
Impact
This should not affect any user who does not explicitly set it up. The benefits would be getting the search speed increases of using SSDs, without needing to add a new pool. Would allow you to get more out of the large boot disk that most people have, but don’t use.
User Story
(Please give a short description on how you envision some user taking advantage of this feature, what are the steps a user will follow to accomplish it)
As a user I want to be able to select the boot partition when selecting the pool to use for TrueSearch.
I beg to differ. I think the current very limited scope for the boot pool is quite appropriate. If you want to use TrueSearch at a scale where your current pool doesn’t support it, then the problem is with your choice of hardware and not of the platform.
What is your concern with allowing the index to use the boot pool?
TrueNAS already uses the boot pool for logs, and as I mentioned in the original post, the index is completely derived data. If it’s lost, it can simply be rebuilt, so it isn’t critical.
I understand the instinct to say “just use different hardware,” but for a lot of smaller hobby users that isn’t really practical. If someone is already using redundant boot disks, they may not have spare slots for additional NVMe drives. And with the current cost of flash storage, it’s hard to justify a dedicated flash pool just for a TrueSearch index.
Yeah, that’s fair. My system only has a single-drive boot pool. I don’t want to use a single-drive app pool, though, because that data actually matters.
I suppose I could replicate it frequently to a spinning-disk pool, but that still isn’t ideal. For my setup, I don’t have much need or interest in creating a flash pool for apps. At the same time, an index like this is effectively useless on a spinning pool. So I’d be creating a flash pool just for the index, which feels pretty inefficient.
What I keep coming back to is this: if you already have a flash pool, that’s obviously the best place to put the index. But if you don’t, what is the actual downside of using the boot pool?
I understand why the boot pool shouldn’t be used for real user data. But for a system-controlled index made entirely from derived data, what is the practical reason not to allow it?
I believe that new features should be of value to enterprise customers before it makes any sense to spend money on implementing it. And I don’t think that enterprise customers would find this an issue at all.
You’ve made your case well. So well that the answer lies in it: The feature request is of relevance solely for users with no dedicated flash pool for apps but the use for a TrueSerach index, and the size of this population does not appear to justify the cost of developing, testing and validating the feature.
For your own use, you may search the forum for the procedure to install the boot pool to a partition (which is strongly advised against, but you can hack it), and then use the other partition on the boot drive for your index.
