Bug 1023779 - ZFS filesystems not being indexed
Summary: ZFS filesystems not being indexed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: mlocate
Version: 6.4
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Michal Sekletar
QA Contact: Stefan Kremen
URL:
Whiteboard:
Depends On:
Blocks: 1304416
TreeView+ depends on / blocked
 
Reported: 2013-10-27 19:26 UTC by Durval Menezes
Modified: 2016-05-06 06:29 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: When updatedb is spawned by cron it prunes all "API" filesystems, i.e. filesystems which have no backing device, thus are marked as nodev in /proc/filesystems. ZFS on Linux is also marked nodev despite the fact it is filesystem used to actually store the data. Consequence: ZFS volumes are not indexed. Fix: Exception for ZFS was added to cron script thus when updatedb is spawned it will also index ZFS filesystems. Result: It is possible to search with locate for files stored on ZFS filesystems.
Clone Of:
: 1065366 1304416 (view as bug list)
Environment:
Last Closed: 2015-03-12 09:00:32 UTC


Attachments (Terms of Use)
Patch implementing the proposed solution (1.21 KB, patch)
2013-10-27 19:26 UTC, Durval Menezes
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0676 normal SHIPPED_LIVE mlocate bug fix update 2015-03-12 13:00:18 UTC

Description Durval Menezes 2013-10-27 19:26:13 UTC
Created attachment 816584 [details]
Patch implementing the proposed solution

Description:

I've determined that mlocate's cronjob (/etc/cron.daily/mlocate.cron) doesn't index any ZFS filesystems. 

The reason for this is that the cronjob builds a list of all "nodev" filesystem types listed in /proc/filesystems, which unfortunately includes ZFS.

I can understand mlocate's rationale for doing that (so as to avoid indexing obviously pseudo filesystems like /proc, /sys, etc), but in ZFS case, it's wrong. Also, I can understand ZFS' rationale for listing itself as "nodev": a ZFS filesystem is not directly connected to a device, it's connected to a ZFS pool (which in turn is connected to a device). 

So, it seems we have an unintentional side-effect of the two rationales above. 

To fix it, I patched the cronjob to source a config file (/etc/sysconfig/mlocate) which defines a single env var called NODEV_FS_TO_SCAN_REGEXP; this should be an awk regexp matching every filesystem which should be indexed by mlocate *even* if it's listed as "nodev" in /proc/filesystems; this way, we have a generic fix which can be used for other filesystem types, in case others in the future fall in the same category as ZFS.

Version-Release number of selected component (if applicable): 0.22.2-4.el6 on RHEL 6.4.


How reproducible: 100%


Steps to Reproduce:
1. Run "/etc/cron.daily/mlocate" with a mounted ZFS filesystem;
2. Wait for it to finish;
3. Try to locate any file in the ZFS filesystem using "locate filename"

Actual results:
Files in ZFS filesystem aren't shown by "locate".

Expected results:
Files in ZFS filesystem should be shown by "locate".

Additional info:
Problem originally reported in the zfs-discuss mailing list (see my post here: https://groups.google.com/a/zfsonlinux.org/forum/#!msg/zfs-discuss/nxlya9MNmYc/2u9jZTr2W4oJ); I've fixed the issue and determined that "upstream" in this case is Redhat EL6, so I'm reporting it here along with my patch.

Comment 5 Michal Sekletar 2014-11-04 13:19:12 UTC
Fixed in fedora by 6f379f79f0c8ff9383bad57f871661a904606d15. Easily backportable with pretty much no risk.

Comment 11 errata-xmlrpc 2015-03-12 09:00:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0676.html


Note You need to log in before you can comment on or make changes to this bug.