legacy mountpoints not working for RHEL6

[cburroughs]

centos6

# zfs list
NAME                 USED  AVAIL  REFER  MOUNTPOINT
tank                 127M  1.76T    30K  none
tank/HOME             68K  1.76T    68K  /home
tank/ROOT            126M  1.76T    30K  none
tank/ROOT/opt        547K  1.76T   524K  /opt
tank/ROOT/tmp       99.5K  1.76T  52.5K  legacy
tank/ROOT/usr-java    30K  1.76T    30K  /usr/java
tank/ROOT/var        125M  1.76T  97.4M  legacy
tank/sstables         29K  1.76T    29K  /data/sstables

# cat /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Tue Apr 14 20:14:26 2015
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=bfb9af67-8d9f-4fd5-94e0-64808edcb810 /                       ext4    noatime         1 1
UUID=5e6b0ca2-0718-413d-8d96-808b9c55b013 /boot                   ext4    defaults        1 2
UUID=dc63f3eb-8d47-4970-a072-95f515a4037d swap                    swap    defaults        0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
tank/ROOT/var              /var          zfs       defaults,noatime      0      0
tank/ROOT/tmp              /tmp          zfs       defaults,noatime      0      0

That was the starting state After yum update zfs and reboot /var is messed up. Ater reboot /var seems to be missing all of the files that are normally there, and only contains some files that were created along the way during boot:

# ls /var
lib  lock  log  run
``

[sl6xx]

I met the same problem while upgrade my setup from 0.6.3 to 0.6.4. I'm running zfsonlinux on CentOS 6.6 x86_64. The whole system is up to date. I built a virtual machine to see if I can duplicate this situation. The answer is yes. For version 0.6.3 I wouldn't have such a problem.

I have been populating my /var, /home and swap partition on my zfs pool since 0.6.0 using legacy mount without a problem until now.

[cburroughs]

@sl6xx with your VM: Could you repro only with a 0.6.3->0.6.4 upgrade, or are legacy mountpoints broken even when created with 0.6.4?

[sl6xx]

Actually this is what I have done first on out backup server, to upgrade from 0.6.3 to 0.6.4. It was broken tha I removed all 0.6.4 packages and reinstalled 0.6.3 to have it work again. I then tried another clean setup for 0.6.4 to reproduce the problem that I went here to report this problem.
For your information, I did a minimal CentOS installation plus zfs packages.

[DeHackEd]

Set the ZFS module parameter zfs_autoimport_disable=0 and try again.

It was changed to 1 as the default during the 0.6.4 development release and /etc/fstab is executed too early in the bootup process for the init script to perform an explicit import.

[sl6xx]

Yes this did solve the problem. Thanks.

[behlendorf]

This is something which #3337 will address. The patch breaks up the startup in to multiple init scripts so things can be staged properly. This will be critical because my intention was to remove zfs_autoimport_disable for the next release.

[cburroughs]

From a user perspetive it would be nice if the relase that removed zfs_autoimport_disable was the one after the release that obviated the need for it.

[behlendorf]

@cburroughs that's was supposed to be this release. But I don't mind leaving this functionality in place if possible until we get this sorted out. The idea was to change to default but leave the option in place so we'd have a chance to detect any issues.

[behlendorf]

Originally, we'd planned to remove zfs_autoimport_disable in the 0.6.5 release but doing so isn't critical and I don't mind leaving it in place for another release. The default is already for it to be disabled.

[behlendorf]

Closing, we've leave the open in place since there's no compelling reason to remove it.