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

mount on non-emtpy mountpoint: default -O for 'zfs mount' #667

Closed
GregorKopka opened this issue Apr 15, 2012 · 6 comments
Closed

mount on non-emtpy mountpoint: default -O for 'zfs mount' #667

GregorKopka opened this issue Apr 15, 2012 · 6 comments
Labels
Type: Documentation Indicates a requested change to the documentation Type: Feature Feature request or new feature
Milestone

Comments

@GregorKopka
Copy link
Contributor

2nd bullet here: #274

Currently i can't create a dataset (update: not a zvol) covering /etc/dfs since every zfs and zpool command touches the sharetab in there, so even when i clear out the contents of the directory is repopulated the moment i issue an zfs command (like 'mount tank/etc/dfs').

The reason for me wanting to put /etc/dfs into a zfs dataset (update: not a zvol) is that the rootfs is on flash memory and the only thing which is left writing to / after boot is complete are the constant updates zfs does to /etc/dfs/sharetab - reducing the lifetime of the flash stick.

Can -O made be default for 'zfs mount' please ?

@ryao
Copy link
Contributor

ryao commented Apr 15, 2012

I believe that Solaris does not permit mounting on non-empty mount points, so I don't think that this is appropriate change to make. I think that your issue can be resolved by putting /etc/dfs on a tmpfs.

Add an entry like tmpfs /etc/dfs tmpfs size=32M,nosuid 0 0 to /etc/fstab, do rm /etc/dfs/sharetab and reboot. If that does not work, you might need to delete that file from a rescue environment.

@GregorKopka
Copy link
Contributor Author

Already did the the tmpfs mount, which - since it's on linux - didn't care that /etc/dfs isn't empty.

Surely a difficult decision to make, but since it's zfsonlinux (and not solarisonlinux) i sounds reasonable to me to not break the linux way of mounting filesystems.

I opened this to get a discussion rolling about how to deal with the situation. Any comments from others?

@ryao
Copy link
Contributor

ryao commented Apr 18, 2012

@GregorKopka Does zfs mount apply to zvols?

If this involved a dataset, I would suggest setting mountpoint=legacy, but I am somewhat confused after taking another look at this and realizing that it involves zvols.

@GregorKopka
Copy link
Contributor Author

/me stupid, i ment dataset. Sorry for the confusion. Updated original post.

@ryao
Copy link
Contributor

ryao commented Apr 18, 2012

Have you tried setting mountpoint=legacy and using /etc/fstab to mount it? That should do what you want.

@behlendorf
Copy link
Contributor

The root cause of this issue should be resolved by commit 27ccd41 . The /etc/dfs/sharetab file will now only be touched when your performing some NFS related operation.

behlendorf added a commit to behlendorf/zfs that referenced this issue May 21, 2018
The kernel_read & kernel_write functions have always wrapped the
vfs_read & vfs_write functions respectively.  However, they could
not be used by vn_rdwr() since the offset wasn't passed as a
pointer.  This prevented us from being able to properly update
the file offset.

Linux 4.14 unexported vfs_read & vfs_write but also changed the
signature of kernel_read & kernel_write to provide the needed
functionality.  Use these updated functions when available.

Reviewed-by: Pritam Baral <pritam@pritambaral.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes openzfs#656 
Closes openzfs#667
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Documentation Indicates a requested change to the documentation Type: Feature Feature request or new feature
Projects
None yet
Development

No branches or pull requests

3 participants