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-0.6.0-rc1 regression with Ubuntu Lucid 2.6.32-28 kernel, mounts pass through #113

Closed
dajhorn opened this issue Feb 20, 2011 · 5 comments

Comments

@dajhorn
Copy link
Contributor

dajhorn commented Feb 20, 2011

The zfs-0.5.2 release (with the external lzfs) was compatible with the 2.6.32-28 kernel in Ubuntu Lucid.

The zfs-0.6.0-rc1 release is incompatible with the same kernel. When zfs mount -a is invoked, the filesystem hierarchy and all file i/o go to the underlying filesystem.

eg: zfs mount -a creates /tank/foo/bar and /tank/alpha/bravo on the root filesystem. echo stuff > /tank/baz also creates the 'baz' file on the root filesystem. The actual zfs filesystem is unmodified.

The zfs command returns 0, but nothing appears in /proc/mounts. All zfs and zpool commands seem to work properly. The splat -a and zpios-sanity.sh checks also pass.

@behlendorf
Copy link
Contributor

This is working well for me on Ubuntu Lucid, Maverick, and Natty. Closing bug.

@dajhorn
Copy link
Contributor Author

dajhorn commented Mar 6, 2011

I think that this could be a variant of issue #126. The mount points disappear when ZFS begins trashing data.

Even with the drop_caches changes, the VM that I posted still exhibits this bug if you loop it under load.

@behlendorf
Copy link
Contributor

Reopening issue until it can be completely explained.

I've been working on a collection of mount related bugs the last few days because it appears there are a few related issues open. This issue I suspected is simply caused by 'zfs mount -a' creating the directory for the mount point in the root fs, and then failing silently for some reason. Issue #101 was opened for a similar failure which can occur due to mount(8) prepending a string to the device name.

Anyway, on Monday I'll push my mount development branch for public developer consumption. I've got a good start on getting all the right infrastructure in place, it just needs some big fixing and testing all the test cases.

As for this bug could you describe what you mean by the mount point disappearing? I don't understand how anything like this is possible. Do you have a test case?

@dajhorn
Copy link
Contributor Author

dajhorn commented Mar 6, 2011

I can get the failure by putting the mount/unmount into a while loop. I will take a screen recording when I see it again.

@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

richardelling pushed a commit to richardelling/zfs that referenced this issue Oct 15, 2018
jgallag88 pushed a commit to jgallag88/zfs that referenced this issue Dec 6, 2019
sdimitro pushed a commit to sdimitro/zfs that referenced this issue Feb 14, 2022
no abbv in InsertForSpeculativeRead
ingestion buffers 256 million bytes -> 256MiB
evictions were being over-counted by add_to_index_or_evict()
only reads should count as hits/misses (not writes that need to check in cache before ingesting)
update PendingChanges stat when adding a pending change via ingestion
extract buffer space management to its own function
rkojedzinszky pushed a commit to rkojedzinszky/zfs that referenced this issue Mar 7, 2023
This removes an extra memory allocation / free from the
NFS4 ACL xattr handler. Initially this was written rather
quickly in the alpha cycle of SCALE and implemented in a
way to ensure that xattr was exactly matching format
used internally in samba's vfs_acl_xattr module. Since
this time a more efficient conversion between the Samba
format and various other ones was added for the purpose
of inclusion in the Kernel NFS server.

This change simplifies conversion between internal NFS ACL and
external xattr representation, but has no impact on userspace
and kernel consumers of this xattr (format does not change).

Signed-off-by: Andrew Walker <[email protected]>
ixhamza pushed a commit to ixhamza/zfs that referenced this issue Nov 15, 2023
This removes an extra memory allocation / free from the
NFS4 ACL xattr handler. Initially this was written rather
quickly in the alpha cycle of SCALE and implemented in a
way to ensure that xattr was exactly matching format
used internally in samba's vfs_acl_xattr module. Since
this time a more efficient conversion between the Samba
format and various other ones was added for the purpose
of inclusion in the Kernel NFS server.

This change simplifies conversion between internal NFS ACL and
external xattr representation, but has no impact on userspace
and kernel consumers of this xattr (format does not change).

Signed-off-by: Andrew Walker <[email protected]>
arter97 pushed a commit to arter97/zfs that referenced this issue Nov 23, 2023
This removes an extra memory allocation / free from the
NFS4 ACL xattr handler. Initially this was written rather
quickly in the alpha cycle of SCALE and implemented in a
way to ensure that xattr was exactly matching format
used internally in samba's vfs_acl_xattr module. Since
this time a more efficient conversion between the Samba
format and various other ones was added for the purpose
of inclusion in the Kernel NFS server.

This change simplifies conversion between internal NFS ACL and
external xattr representation, but has no impact on userspace
and kernel consumers of this xattr (format does not change).

Signed-off-by: Andrew Walker <[email protected]>
ixhamza pushed a commit to ixhamza/zfs that referenced this issue Jun 13, 2024
This removes an extra memory allocation / free from the
NFS4 ACL xattr handler. Initially this was written rather
quickly in the alpha cycle of SCALE and implemented in a
way to ensure that xattr was exactly matching format
used internally in samba's vfs_acl_xattr module. Since
this time a more efficient conversion between the Samba
format and various other ones was added for the purpose
of inclusion in the Kernel NFS server.

This change simplifies conversion between internal NFS ACL and
external xattr representation, but has no impact on userspace
and kernel consumers of this xattr (format does not change).

Signed-off-by: Andrew Walker <[email protected]>
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