Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"zfs mount -a" adds incorrect device/dataset entry to /etc/mtab when current directory is "/" #101

Closed
fajarnugraha opened this issue Feb 18, 2011 · 2 comments

Comments

@fajarnugraha
Copy link
Contributor

Currently running your latest zpl branch. I found this issue when writing an init script that will run "zfs mount -a" during boot process. Here's a simple test: http://pastebin.com/rHfuzzSa

In that example, there's a pool called testpool. When the fs is unmounted (zfs umount -a), and then you run "zfs mount -a" when current directory is "/", /etc/mtab will record the wrong device/dataset with leading "/" ("/testpool" instead of "testpool").

This effectively prevents "zfs umount -a" from running correctly.

Workaround: change working directory somewhere else (anywhere but "/") before running "zfs mount -a"

@behlendorf
Copy link
Contributor

The problem here is actually with the mount(8) command. Because I needed to ensure that the /etc/mtab file is always locked properly, the 'zfs (u)mount' command actually calls mount(8) to do the heavy lifting. The mount(8) command then helpfully tries to resolve the 'device' which is passed to it based on some heuristics. One of these heuristics is to prepend the cwd to the passed 'device', if the resulting path exists this new device name is passed to mount(2). In this case when your cwd is root it prepends '/' to say the dataset named 'tank'. Since the directory '/tank' exists it calls mount(2) with this device. The mount then fails because the kernel doesn't understand the dataset named '/tank', it expects 'tank'. You can cause this same failure by running to mount command in any directory with a file/dir named the same as your dataset.

The long term fix for this will be to push a patch upstream to util-linux so I doesn't mess around with the 'device' names for zfs type datasets. In the short term I'll update the mount.zfs helpers to undo the damage done by mount(8) before it calls mount(2).

@behlendorf
Copy link
Contributor

Fix mount helper

Several issues related to strange mount/umount behavior were reported
and this commit should address most of them. The original idea was
to put in place a zfs mount helper (mount.zfs). This helper is used
to enforce 'legacy' mount behavior, and perform any extra mount argument
processing (selinux, zfsutil, etc). This helper wasn't ready for the
0.6.0-rc1 release but with this change it's functional but needs to
extensively tested.

This change addresses the following open issues.
Closed by 6adf458
Closed by 6adf458
Closed by 6adf458
Closed by 6adf458
Closed by 6adf458

dajhorn referenced this issue in zfsonlinux/pkg-zfs Sep 7, 2012
Previously, the SPL tried to maintain Solaris semantics by freeing
all available (empty) slabs from its slab caches when the shrinker
was called. This is not desirable when running on Linux. To make
the SPL shrinker more Linux friendly, the actual number of freed
slabs from each of the slab caches is now derived from nr_to_scan
and skc_slab_objs.

Additionally, an accounting bug was fixed in spl_slab_reclaim()
which could cause us to reclaim one more slab than requested.

Signed-off-by: Prakash Surya <surya1@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #101
richardelling pushed a commit to richardelling/zfs that referenced this issue Oct 15, 2018
… degraded (openzfs#101)

- Initializing zinfo's checkpointed io sequence number with old value stored in ZAP

Signed-off-by: mayank <mayank.patel@cloudbyte.com>
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants