Symlink issue: ZPL branch, RHEL5, kernel 2.6.32

[fajarnugraha]

symlink doesn't work (it works fine using kq's port). Here's an
example (I have a zpool called "vm")

# zfs create vm/test
filesystem successfully created, but not shared
# cd /vm/test/
# touch test1
# ln -s test1 test2
# ls -la
total 4
drwxr-xr-x 2 root root 4 Feb 11 16:54 .
drwxr-xr-x 7 root root 7 Feb 11 16:53 ..
-rw-r--r-- 1 root root 0 Feb 11 16:54 test1
lrwxrwxrwx 1 root root 5 Feb 11 16:54 test2 ->
# cat test1
# cat test2
cat: test2: Is a directory

[behlendorf]

Thanks for the heads up, I hadn't gotten around to verifying symlinks yet. In fact, I've just taken a step back and will be trying to run the pjd-fstest suite. This is the functional test suite which was put together for the ZFS FreeBSD work and it's been updated to be Linux friendly. Anyway, once this full suite passes and perhaps the Sun/Oracle ZFS test suite for the tool chains we'll look at merging this development branch in to the master.

[behlendorf]

Create minors for all zvols

It was noticed that when you have zvols in multiple datasets
not all of the zvol devices are created at module load time.
Fajarnugraha did the leg work to identify that the root cause of
this bug is a non-zero return value from zvol_create_minors_cb().

Returning a non-zero value from the dmu_objset_find_spa() callback
function results in aborting processing the remaining children in
a dataset. Since we want to ensure that the callback in run on
all children regardless of error simply unconditionally return
zero from the zvol_create_minors_cb(). This callback function
is solely used for this purpose so surpressing the error is safe.

Closed by d567444

[fajarnugraha]

I believe this is the wrong issue to close with that comment, and we should leave this issue open until symlink issue is fixed.

[behlendorf]

Your right, I mistyped the bug ID in the commit message so the wrong bug got closed. Sorry about that.

However, I did commit a fix yesterday which specifically addresses the issue above, 8b4f9a2. This issue was with readlink(2) incorrectly reading the symlink value from the ZFS SA. Links now almost work properly.

Unfortunately, there's at least one bug still remaining which causing a crash when a symlink in removed. I'm pretty sure this is caused by a missing iget() in the symlink path and my plan is to run that issue down today.

[behlendorf]

Fix symlink(2) inode reference count

Under Linux sys_symlink(2) should result in a inode being created
with one reference for the inode itself, and a second reference on
the inode which is held by the new dentry. Under Solaris this
appears not to be the case. Their zfs_symlink() handler drops
the inode reference before returning.

The result of this under Linux is that the reference count for
symlinks is always one smaller than it should have been. This
results in a BUG() when the symlink is unlinked. To handle this
the Linux port now keeps the inode reference which differs from
the Solaris behavior. This results in correct reference counts.

Closed by efd1832