The dirs blocking the mount are created at import/mount time.
how you know that??
In the previous example I could reconstruct that using zfs mount. Just look at
the last post.
I doubt ZFS removes mount directories.
If you're correct you should been able to reproduce
the problem by doing a
We import the pool with the -R parameter, might that contribute to the
problem? Perhaps a zfs mount -a bug in correspondence with the -R parameter?
This Bugreport seems to confirm this:
http://bugs.opensolaris.org/view_bug.do?bug_id=6612218
Note that the /zz directory mentioned in the
We are also running into this bug.
Our system is a Solaris 10u4
SunOS sunsystem9 5.10 Generic_127112-10 i86pc i386 i86pc
ZFS version 4
We opened a Support Case (Case ID 71912304) which after some discussion came to
the conclusion that we should not use /etc/reboot for rebooting.
This leads me
If you umount a ZFS FS that has some other FS's underneath it, then the
mount points for the child FS needs to be created to have those
mounted; that way if you don't export the pool the dirs won't be deleted
and next time you import the pool the FS will fail to mount because your
mount
When I attempt again to import using zdb -e ztank
I still get zdb: can't open ztank: I/O error
and zpool import -f, whilst it starts and seems to
access the disks sequentially, it stops al the 3rd
one (no sure which precisely - it spins it up and the
process stops right there, and the system
I have a server with a huge number of datasets (around 9000)
When the pool containing the datasets is imported on boot up, a few (10)
datasets are not mounted and thus not exported via nfs. Which dataset is not
mounted is random.
All datasets are exported via nfs. A zfs import takes around 30
