-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Comments
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). |
Fix mount helper Several issues related to strange mount/umount behavior were reported This change addresses the following open issues. |
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
… degraded (openzfs#101) - Initializing zinfo's checkpointed io sequence number with old value stored in ZAP Signed-off-by: mayank <mayank.patel@cloudbyte.com>
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"
The text was updated successfully, but these errors were encountered: