Bug 1023779 - ZFS filesystems not being indexed
ZFS filesystems not being indexed
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: mlocate (Show other bugs)
6.4
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Michal Sekletar
Stefan Kremen
:
Depends On:
Blocks: 1304416
  Show dependency treegraph
 
Reported: 2013-10-27 15:26 EDT by Durval Menezes
Modified: 2016-05-06 02:29 EDT (History)
4 users (show)

See Also:
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.
Story Points: ---
Clone Of:
: 1065366 1304416 (view as bug list)
Environment:
Last Closed: 2015-03-12 05:00:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Durval Menezes 2013-10-27 15:26:13 EDT
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 08:19:12 EST
Fixed in fedora by 6f379f79f0c8ff9383bad57f871661a904606d15. Easily backportable with pretty much no risk.
Comment 11 errata-xmlrpc 2015-03-12 05:00:32 EDT
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.