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.

Sign up for GitHub

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

Jump to bottom

Infinite hang with ZVOL #54

Closed
rincebrain opened this issue Aug 23, 2010 · 2 comments
Closed

Infinite hang with ZVOL #54

rincebrain opened this issue Aug 23, 2010 · 2 comments

Comments

@rincebrain
Copy link
Contributor

Not entirely clear to me what happened - I made two ZVOLs, concatenated them into a RAID-0 using Linux MD, made an ext4 filesystem on it, mounted it, and started rsyncing data.

...then the rsync hung, then the machine became unresponsive to anything short of sysrq.

Log available at http://gist.github.com/544526

Git commit 18568e1
@behlendorf
Copy link
Contributor

According to the attached stack traces the system locked up because a few unrelated threads started a synchronous memory reclaim. The reclaim triggered a flush of pages dirty data pages to disk to free up memory. Unfortunately, they could not be synced to disk because they couldn't open the txg group. This may be because the currently committing transaction was blocked on something, or just very very slow, but it's impossible to tell from the logs. We'll just need to watch for something like this to happen again and get more debugging.

@behlendorf
Copy link
Contributor

A deadlock exactly like this was recently mostly addressed in the SPL. That's likely what happened here, I'm closing the bug as fixed.

akatrevorjay added a commit to akatrevorjay/zfs that referenced this issue Dec 16, 2017
@akatrevorjay
# This is a combination of 56 commits.
4ae6a0d 
# This is the 1st commit message:
Merge branch 'master' of https://github.com/zfsonlinux/zfs

* 'master' of https://github.com/zfsonlinux/zfs:
  Enable QAT support in zfs-dkms RPM

# This is the commit message openzfs#2:

Import 0.6.5.7-0ubuntu3

# This is the commit message openzfs#3:

gbp changes

# This is the commit message openzfs#4:

Bump ver

# This is the commit message openzfs#5:

-j9 baby

# This is the commit message openzfs#6:

Up

# This is the commit message openzfs#7:

Yup

# This is the commit message openzfs#8:

Add new module

# This is the commit message openzfs#9:

Up

# This is the commit message openzfs#10:

Up

# This is the commit message openzfs#11:

Bump

# This is the commit message openzfs#12:

Grr

# This is the commit message openzfs#13:

Yay

# This is the commit message openzfs#14:

Yay

# This is the commit message openzfs#15:

Yay

# This is the commit message openzfs#16:

Yay

# This is the commit message openzfs#17:

Yay

# This is the commit message openzfs#18:

Yay

# This is the commit message openzfs#19:

yay

# This is the commit message openzfs#20:

yay

# This is the commit message openzfs#21:

yay

# This is the commit message openzfs#22:

Update ppa script

# This is the commit message openzfs#23:

Update gbp conf with br changes

# This is the commit message openzfs#24:

Update gbp conf with br changes

# This is the commit message openzfs#25:

Bump

# This is the commit message openzfs#26:

No pristine

# This is the commit message openzfs#27:

Bump

# This is the commit message openzfs#28:

Lol whoops

# This is the commit message openzfs#29:

Fix name

# This is the commit message openzfs#30:

Fix name

# This is the commit message openzfs#31:

rebase

# This is the commit message openzfs#32:

Bump

# This is the commit message openzfs#33:

Bump

# This is the commit message openzfs#34:

Bump

# This is the commit message openzfs#35:

Bump

# This is the commit message openzfs#36:

ntrim

# This is the commit message openzfs#37:

Bump

# This is the commit message openzfs#38:

9

# This is the commit message openzfs#39:

Bump

# This is the commit message openzfs#40:

Bump

# This is the commit message openzfs#41:

Bump

# This is the commit message openzfs#42:

Revert "9"

This reverts commit de488f1.

# This is the commit message openzfs#43:

Bump

# This is the commit message openzfs#44:

Account for zconfig.sh being removed

# This is the commit message openzfs#45:

Bump

# This is the commit message openzfs#46:

Add artful

# This is the commit message openzfs#47:

Add in zed.d and zpool.d scripts

# This is the commit message openzfs#48:

Bump

# This is the commit message openzfs#49:

Bump

# This is the commit message openzfs#50:

Bump

# This is the commit message openzfs#51:

Bump

# This is the commit message openzfs#52:

ugh

# This is the commit message openzfs#53:

fix zed upgrade

# This is the commit message openzfs#54:

Bump

# This is the commit message openzfs#55:

conf file zed.d

# This is the commit message #56:

Bump
richardelling pushed a commit to richardelling/zfs that referenced this issue Oct 15, 2018
US1541 Debugging and logging at cStor target (openzfs#54)
f4a98dc 
Signed-off-by: Jan Kryl <jan.kryl@cloudbyte.com>
pcd1193182 added a commit to pcd1193182/zfs that referenced this issue Jun 25, 2019
@pcd1193182
Implement Redacted Send/Receive (openzfs#54)
29b6d56 
Redacted send/receive allows users to send subsets of their data to 
a target system. One possible use case for this feature is to not 
transmit sensitive information to a data warehousing, test/dev, or 
analytics environment. Another is to save space by not replicating 
unimportant data within a given dataset, for example in backup tools 
like zrepl.

Redacted send/receive is a three-stage process. First, a clone (or 
clones) is made of the snapshot to be sent to the target. In this 
clone (or clones), all unnecessary or unwanted data is removed or
modified. This clone is then snapshotted to create the "redaction 
snapshot" (or snapshots). Second, the new zfs redact command is used 
to create a redaction bookmark. The redaction bookmark stores the 
list of blocks in a snapshot that were modified by the redaction 
snapshot(s). Finally, the redaction bookmark is passed as a parameter 
to zfs send. When sending to the snapshot that was redacted, the
redaction bookmark is used to filter out blocks that contain sensitive 
or unwanted information, and those blocks are not included in the send 
stream.  When sending from the redaction bookmark, the blocks it 
contains are considered as candidate blocks in addition to those 
blocks in the destination snapshot that were modified since the 
creation_txg of the redaction bookmark.  This step is necessary to 
allow the target to rehydrate data in the case where some blocks are 
accidentally or unnecessarily modified in the redaction snapshot.

The changes to bookmarks to enable fast space estimation involve 
adding deadlists to bookmarks. There is also logic to manage the 
life cycles of these deadlists.

The new size estimation process operates in cases where previously 
an accurate estimate could not be provided. In those cases, a send 
is performed where no data blocks are read, reducing the runtime 
significantly and providing a byte-accurate size estimate.

Reviewed-by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed-by: Matt Ahrens <mahrens@delphix.com>
Reviewed-by: Prashanth Sreenivasa <pks@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: George Wilson <george.wilson@delphix.com>
Reviewed-by: Chris Williamson <chris.williamson@delphix.com>
Reviewed-by: Pavel Zhakarov <pavel.zakharov@delphix.com>
Reviewed-by: Sebastien Roy <sebastien.roy@delphix.com>
Reviewed-by: Prakash Surya <prakash.surya@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Paul Dagnelie <pcd@delphix.com>
Closes openzfs#7958
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue May 24, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
c34e84d 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue May 24, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
8163af3 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue May 24, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
fbec260 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue May 28, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
26e3393 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue May 31, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
dd4639b 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 6, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
d41a3a7 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 6, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
4f92cd8 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 6, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
fa0a3ec 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 6, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
4c6b7d1 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 8, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
346bd38 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 9, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
f781d63 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 10, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
3989f89 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 21, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
5d2628b 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 22, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
8ea3fc1 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 22, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
2b7900f 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 23, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
2ddf693 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 23, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
008a5e6 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 25, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
8d4bc6f 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jun 30, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
1cd14bf 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jul 13, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
e91c94e 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jul 13, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
d2beb59 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jul 17, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
08f41aa 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Jul 27, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
d97f5d4 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
lundman added a commit to openzfsonosx/openzfs-fork that referenced this issue Sep 1, 2021
@lundman
Upstream: Zdb inode mapping fix (openzfs#54)
2ebb7ac 
* macOS: Move INO map macros

The INO mapping macros need to also be accessable from userland.

* Upstream: zdb needs to map inodes on macOS
Signed-off-by: Jorgen Lundman <lundman@lundman.net>
tonynguien pushed a commit to tonynguien/zfs that referenced this issue Dec 21, 2021
@ahrens
halve ObjectBlockMap RAM by using ObjectId = min_block (openzfs#54)
1708728 
The memory footprint of the ObjectBlockMap can be cut in half by
treating the ObjectId as the minimum BlockId that it could contain. Now
the ObjectBlockMap only needs to be a sorted list of ObjectId's, rather
than (ObjectId, BlockId) tuples.

In other words, rather than having the ObjectId's be 0, 1, 2, 3, ...
they are 0, (first BlockId in the second object), (first blockId in the
third object), etc. Since we already treat ObjectId's as potentially
non-sequential (due to object consolidation), the implications on the
rest of the code are minimal.

Rather than rotating to a new ReclaimLog every 1000 ObjectId's, we now
rotate every 1,000,000 ObjectId's (i.e. every 1,000,000 BlockId's).

side cleanup: ObjectDeletePhys -> ObjectDeleterPhys
@512yottabytes 512yottabytes mentioned this issue Sep 22, 2022
Open
rkojedzinszky pushed a commit to rkojedzinszky/zfs that referenced this issue Mar 7, 2023
@anodos325
Add ability for xattr handler to "strip" NFSv4 ACL (openzfs#54)
b5059be 
On Linux POSIX ACLs can be removed via rmxattr() for the
relevant system xattrs. On FreeBSD a non-trivial ACL
can be converted to one that is described by the mode with
no loss of info via combination of acl_get_file(), acl_strip_np(),
and acl_set_file(). Since there's no libc equivalent of these
ops in Linux for NFSv4 ACLs, this commit makes this less error
prone by handling entirely in ZFS. When user performs
rmxattr() vfs_setxattr() is called with value of NULL and length
of 0. Add special handling for this situation in the xattr
handler for the NFSv4 ACL so that we generate a new ACL and
zfs_acl_chmod() with the existing mode of file, then set the ACL.

Signed-off-by: Andrew Walker <awalker@ixsystems.com>
ixhamza pushed a commit to ixhamza/zfs that referenced this issue Nov 15, 2023
@anodos325 @ixhamza
Add ability for xattr handler to "strip" NFSv4 ACL (openzfs#54)
6bf8daf 
On Linux POSIX ACLs can be removed via rmxattr() for the
relevant system xattrs. On FreeBSD a non-trivial ACL
can be converted to one that is described by the mode with
no loss of info via combination of acl_get_file(), acl_strip_np(),
and acl_set_file(). Since there's no libc equivalent of these
ops in Linux for NFSv4 ACLs, this commit makes this less error
prone by handling entirely in ZFS. When user performs
rmxattr() vfs_setxattr() is called with value of NULL and length
of 0. Add special handling for this situation in the xattr
handler for the NFSv4 ACL so that we generate a new ACL and
zfs_acl_chmod() with the existing mode of file, then set the ACL.

Signed-off-by: Andrew Walker <awalker@ixsystems.com>
arter97 pushed a commit to arter97/zfs that referenced this issue Nov 23, 2023
@anodos325 @arter97
Add ability for xattr handler to "strip" NFSv4 ACL (openzfs#54)
73078a3 
On Linux POSIX ACLs can be removed via rmxattr() for the
relevant system xattrs. On FreeBSD a non-trivial ACL
can be converted to one that is described by the mode with
no loss of info via combination of acl_get_file(), acl_strip_np(),
and acl_set_file(). Since there's no libc equivalent of these
ops in Linux for NFSv4 ACLs, this commit makes this less error
prone by handling entirely in ZFS. When user performs
rmxattr() vfs_setxattr() is called with value of NULL and length
of 0. Add special handling for this situation in the xattr
handler for the NFSv4 ACL so that we generate a new ACL and
zfs_acl_chmod() with the existing mode of file, then set the ACL.

Signed-off-by: Andrew Walker <awalker@ixsystems.com>
ixhamza pushed a commit to ixhamza/zfs that referenced this issue Jun 13, 2024
@anodos325 @ixhamza
Add ability for xattr handler to "strip" NFSv4 ACL (openzfs#54)
d1df3f6 
On Linux POSIX ACLs can be removed via rmxattr() for the
relevant system xattrs. On FreeBSD a non-trivial ACL
can be converted to one that is described by the mode with
no loss of info via combination of acl_get_file(), acl_strip_np(),
and acl_set_file(). Since there's no libc equivalent of these
ops in Linux for NFSv4 ACLs, this commit makes this less error
prone by handling entirely in ZFS. When user performs
rmxattr() vfs_setxattr() is called with value of NULL and length
of 0. Add special handling for this situation in the xattr
handler for the NFSv4 ACL so that we generate a new ACL and
zfs_acl_chmod() with the existing mode of file, then set the ACL.

Signed-off-by: Andrew Walker <awalker@ixsystems.com>
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@behlendorf @rincebrain