ZFS hangs after heavy work #595
Milestone
Comments
|
I forgot to mention that sometimes after hard resetting the machine the pool needs a export and a forced import because of 'faulted' devices. |
|
The issue with 'faulted' devices on reboot can most likely be avoided by importing the pool with '-d /dev/disk/by-id' once. |
|
I believe this is a duplicate of issue #496. A workaround was merged in to 0.6.0.53 daily release. Can you please upgrade to the latest daily and let me know if the issue persists. |
|
Great :) I've updated today in the morning and until now everything is fine. |
behlendorf
added a commit
to behlendorf/zfs
that referenced
this issue
Jan 10, 2017
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Requires-spl: refs/pull/595/head
behlendorf
pushed a commit
to behlendorf/zfs
that referenced
this issue
May 21, 2018
When building SPL within the kernel tree, C99 initializers cause build failures and need to be converted to C89 as kernel CFLAGS specify -std=gnu89. This fix was provided by @behlendorf in openzfs#595 discussion notes and manually implemented in the current master revision. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: RageLtMan <rageltman@sempervictus> Closes openzfs#597
behlendorf
pushed a commit
to behlendorf/zfs
that referenced
this issue
May 21, 2018
SLAB_USERCOPY flag was used to indicate PAX not to kill copies from kernel to userland. With recent grsecurity patchset and CONFIG_GRKERNSEC_HIDESYM that enables CONFIG_PAX_USERCOPY zfs would panic. Handle newer API while keeping old one functional. Tested-by: RageLtMan <rageltman@sempervictus> Reviewed-by: spendergrsec <spender@grsecurity.net> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Kevin Tanguy <kevin.tanguy@ovh.net> Closes openzfs#595
pcd1193182
pushed a commit
to pcd1193182/zfs
that referenced
this issue
Sep 26, 2023
problem:
```
= ID: RUSTSEC-2022-0051
= Advisory: https://rustsec.org/advisories/RUSTSEC-2022-0051
= lz4-sys up to v1.9.3 bundles a version of liblz4 that is vulnerable to
[CVE-2021-3520](https://nvd.nist.gov/vuln/detail/CVE-2021-3520).
Attackers could craft a payload that triggers an integer overflow upon
decompression, causing an out-of-bounds write.
The flaw has been corrected in version v1.9.4 of liblz4, which is included
in lz4-sys 1.9.4.
= Announcement: lz4/lz4#972
= Solution: Upgrade to >=1.9.4
```
solution: `cargo update -p lz4`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm using my ZFS pool to archive my mac using timemachine and for other archiving stuff.
Sometimes during the backup process of a fresh backup (about 150GB) which writes with about 100-200Mbit/s zfs freezes and the whole system is unusable. I'm receiving the login 'form' via ssh but it hangs after entering the credentials. Active ssh sessions are unable to spawn new processes, they just do nothing and are not able to be aborted via Ctrl+C.
Scrubbing doesn't detect any error.
The kern.log: https://gist.github.com/2002476
My setup:
I'm using the daily packages for ubuntu located at https://launchpad.net/~zfs-native/+archive/daily which is 0.6.0.52-0ubuntu1~oneiric1. The stable version produced simmilar errors.
root@ubuntu:~# zpool status pool: tank state: ONLINE scan: scrub in progress since Thu Mar 8 19:17:00 2012 101G scanned out of 4.23T at 164M/s, 7h21m to go 0 repaired, 2.33% done config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 sdb ONLINE 0 0 0 sde ONLINE 0 0 0 sdg ONLINE 0 0 0 sdd ONLINE 0 0 0 sdf ONLINE 0 0 0 errors: No known data errorsIf you need more information, do not hesitate to ask for it.
The text was updated successfully, but these errors were encountered: