Differences

This shows you the differences between two versions of the page.

--- andriygapon:avgzfsproblemlist [2013/02/10 09:53] – AndriyGapon
+++ andriygapon:avgzfsproblemlist [2018/03/12 02:55] (current) – add to CategoryZfs. MarkLinimon
@@ Line 1: / Line 1: @@
 === List of interesting issues with ZFS (in no particular order) ===
-== Priorities of ZFS worker threads ==
+== LOR between page "lock" and z_teardown_lock ==
-Compression/decompression/etc potentially takes a lot of CPU.
+One thread could have a page busy and then stumble into z_teardown_lock while trying to write out the page.
+Another thread could be doing a rollback, thus it would hold z_teardown_lock and then try to discard potentially stale pages of a vnode.
-See a complaint here: http://thread.gmane.org/gmane.os.freebsd.stable/85097/focus=85100
+For that it would need to wait for each page to get "unbusied".
-One quick fix is to use PUSER priority as done in GELI driver.
-More investigation is needed.
 == Memory allocations in ARC ==
@@ Line 23: / Line 20: @@
     * pagedaemon calling arc_lowmem while there are other threads waiting on it in ARC memory allocations (via VM_WAIT)
   * arc_evict_needed should check for KVA shortage even on amd64
+== Memory allocation in zio aggregation ==
+A new aggregated zio may be created.  Its memory is allocated with KM_SLEEP / M_WAIT flag.
+So it may sleep.
+But because this happens in ZFS txg_sync thread it means that no new write operations may go through.
+Thus e.g. page daemon could get stuck in zfs_write and thus it wouldn't be able to page out and free any memory.
+This leads to a deadlock.
+== ZFS suspension is not visible to VFS ==
+There are situations when VFS actively tries to avoid sleeping on locks.
+But because ZFS suspension is completely hidden from VFS it may end up sleeping on z_teardown lock.
+This could lead to a deadlock if e.g. vnlru code gets stuck on a vnode from a suspended filesystem.
+Then new vnode allocation may have to sleep waiting for vnlru.
+These allocations could be requested by threads that are already in ZFS transactions.
+As such these threads may block txg quiescing and thus the sync thread may get stuck.
+But the sync thread could be required by the suspension lock owner that wants
+to perform an operation like a rollback that must go the sync thread.
 == Separate KVA submap for ZFS allocations ==
@@ Line 72: / Line 88: @@
 This needs support for "hierarchical" dumping in %%FreeBSD%%.
 Dump should call into ZVOL code and the ZVOL code should be able to do dumping onto geoms of vdev and all the way down to real disk drivers.
+== Priorities of ZFS worker threads ==
+Compression/decompression/etc potentially takes a lot of CPU.
+See a complaint here: http://thread.gmane.org/gmane.os.freebsd.stable/85097/focus=85100
+One quick fix is to use PUSER priority as done in GELI driver.
+More investigation is needed.
+----
+{{tag>Zfs}}