Console View
|
Tags: Architectures Platforms default |
|
| Architectures | Platforms | default | ||||||||||||||||
|
|
|
|
||||||||||||||||
|
George Wilson
george.wilson@delphix.com |
|
|
|
|||||||||||||||
|
zio can deadlock during device removal When doing a device removal on a pool with gang blocks, the zio pipeline can deadlock when trying to free blocks from a device which is being removed with a stack similar to this: 0xffff8ab9a13a1740 UNINTERRUPTIBLE 4 __schedule+0x2e5 __schedule+0x2e5 schedule+0x33 schedule_preempt_disabled+0xe __mutex_lock.isra.12+0x2a7 __mutex_lock.isra.12+0x2a7 __mutex_lock_slowpath+0x13 mutex_lock+0x2c free_from_removing_vdev+0x61 metaslab_free_impl+0xd6 metaslab_free_dva+0x5e metaslab_free+0x196 zio_free_sync+0xe4 zio_free_gang+0x38 zio_gang_tree_issue+0x42 zio_gang_tree_issue+0xa2 zio_gang_issue+0x6d zio_execute+0x94 zio_execute+0x94 taskq_thread+0x23b kthread+0x120 ret_from_fork+0x1f Since there are gang blocks we have to read the gang members as part of the free. This can be seen with a zio dependency tree that looks like this: sdb> echo 0xffff900c24f8a700 | zio -rc | zio ADDRESS TYPE STAGE WAITER 0xffff900c24f8a700 NULL CHECKSUM_VERIFY 0xffff900ddfd31740 0xffff900c24f8c920 FREE GANG_ASSEMBLE - 0xffff900d93d435a0 READ DONE In the illustration above we are processing frees but because of gang block we have to read the constituents blocks. Once we finish the READ in the zio pipeline we will execute the parent. In this case the parent is a FREE but the zio taskq is a READ and we continue to process the pipeline leading to the stack above. In the stack above, we are blocked waiting for the svr_lock so as a result a READ interrupt taskq thread is now consumed. Eventually, all of the READ taskq threads end up blocked and we're unable to complete any read requests. In zio_notify_parent there is an optimization to continue to use the taskq thread to exectue the parent's pipeline. To resolve the deadlock above, we only allow this optimization if the parent's zio type matches the child which just completed. Signed-off-by: George Wilson <gwilson@delphix.com> External-issue: DLPX-80130 Pull-request: #14236 part 1/1 |
||||||||||||||||||
|
George Wilson
george.wilson@delphix.com |
|
|
|
|||||||||||||||
|
nopwrites on dmu_sync-ed blocks can result in a panic After a device has been removed, any nopwrites for blocks on that indirect vdev should be ignored and a new block should be allocated. The original code attempted to handle this but used the wrong block pointer when checking for indirect vdevs and failed to check all DVAs. This change corrects both of these issues and modifies the test case to ensure that it properly tests nopwrites with device removal. Signed-off-by: George Wilson <gwilson@delphix.com> Pull-request: #14235 part 1/1 |
||||||||||||||||||
|
George Wilson
george.wilson@delphix.com |
|
|
|
|||||||||||||||
|
nopwrites on dmu_sync-ed blocks can result in a panic After a device has been removed, any nopwrites for blocks on that indirect vdev should be ignored and a new block should be allocated. The original code attempted to handle this but used the wrong block pointer when checking for indirect vdevs and failed to check all DVAs. This change corrects both of these issues and modifies the test case to ensure that it properly tests nopwrites with device removal. Signed-off-by: George Wilson <gwilson@delphix.com> Pull-request: #14235 part 1/1 |
||||||||||||||||||
|
Richard Yao
richard.yao@alumni.stonybrook.edu |
|
|
|
|||||||||||||||
|
Rebase on avx512 code It is now running faster than the Intel written avx2 code in a KVM guest on Zen 3: 0 0 0x01 -1 0 1544703784 7905022158 implementation native byteswap scalar 9844805719 9474656265 superscalar 14186756773 12659613432 superscalar4 13727489481 12508784940 generic-avx2 49197257633 2958823554 sse2 22567594300 12265074850 ssse3 22566380108 20582510550 avx2 42224833182 38138634892 fastest generic-avx2 avx2 The problem with GCC 11.3.0's bad code generation for the byteswap case is still there. This works because the total theoretical bandwidth is 51.2GB/sec and Zen 3 is capable of performing two 256-bit vpaddq operations per cycle according to Agner Fog. i.e. superscalar SIMD is possible. Presumably, the sse2 and ssse3 code should be re-evaluated based on the revelation that superscalar SIMD is possible. They might benefit from additional accumulator streams. Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu> Pull-request: #14234 part 3/3 |
||||||||||||||||||
|
||||||||||||||||||
|
Richard Yao
richard.yao@alumni.stonybrook.edu |
|
|
|
|||||||||||||||
|
Add generic fletcher4 vector implementation This is written using GNU C's generic vector extensions to the C standard. This compiles on all supported architectures. However, initially, it only generates vector instructions in the kernel on x86, x86_64 and power64 when either AVX2 is avaliable or VSX is avaliable. Other architectures should see something equivalent to superscalar64.i In userspace, we are more likely to see vector instructions automatically generated for other architectures, but this depends on what the compiler is willing to use by default, since we make no attempt to force vector instruction generation on other architectures. Coincidentally, the compilers do not give us a generic way of doing that across all architectures. Supporting vector instructions on an architecture requires using compiler pragma directives. At present, there are directives for both GCC and Clang. ICC was tested and was found to need its own directives, which were not added, so anyone compiling ZFS with ICC will not have vector instructions emitted inside the kernel. For x86 and x86_64, AVX2 will be generated. This is mostly a proof of concept demonstration that shows that modern compilers are capable of generating optimal vector instructions from generic vector code. This comes with a caveat. GCC is actually unable to generate good assembly on its own, so a single handwritten instruction was added to fix the native case. In the byteswap case, another instruction is needed by GCC, but this was not implemented. On the other hand, Clang generates the correct instructions without any need for help. For POWER, VSX instructions will be generated. This will only occur on POWER8 or later with Clang or POWER9 or later with GCC. The assembly generated by Clang for POWER8 appears optimal. GCC's assembly output appears substantially less optimal, but it becomes less terrible when built for POWER9 and later. That is why we require POWER9 as a minimum for GCC, but only require POWER8 as a minimum for Clang. Support for AARCH64/ARM was considered, but the build system passes -mgeneral-regs-only and upon seeing this, both GCC and Clang refuse to emit NEON instructions. This is incompatible with the idea of selectively enabling them on key functions, so support for ARM was not implemented. Support for SPARC was also considered, but its SIMD instructions have a maximum 64-bit width. We need greater widths to be able to do 64-bit additions to be done simultaneously, so it was not possible to use its SIMD instructions. The result is that the best possible on SPARC is the superscalar code, which this resembles without vector instructions. Support for MIPS was also considered, but MIPS Release 5 is required for that, almost no hardware implements MIPS Release 5 and it was not apparent how to get the compilers to generate SIMD instructions for it. It would not surprise me if the compilers do not support MIPS Release 5's SIMD instructions at all. Support for Loongson was also considered, but a lack of documentation (depsite it being MIPS-based) prevented it from being done. Support for S390 was also considered, but it required compiling for the rather new Z13, and the compilers did not appear to emit vector instructions for it. Like for MIPS, it is quite possible that the compilers do not know how to emit them. Support for RISC-V was also considered. While the RISC-V Vector Extension was ratified in 2021, it does not appear to be supported by compilers at this time. Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu> Pull-request: #14234 part 2/3 |
||||||||||||||||||
|
||||||||||||||||||
|
Richard Yao
richard.yao@alumni.stonybrook.edu |
|
|
|
|||||||||||||||
|
Add POWER ISA 3.00 detection Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu> Pull-request: #14234 part 1/3 |
||||||||||||||||||
|
Richard Yao
richard.yao@alumni.stonybrook.edu |
|
|
|
|||||||||||||||
|
Add generic fletcher4 vector implementation This is written using GNU C's generic vector extensions to the C standard. This compiles on all supported architectures. However, initially, it only generates vector instructions in the kernel on x86, x86_64 and power64 when either AVX2 is avaliable or VSX is avaliable. Other architectures should see something equivalent to superscalar64.i In userspace, we are more likely to see vector instructions automatically generated for other architectures, but this depends on what the compiler is willing to use by default, since we make no attempt to force vector instruction generation on other architectures. Coincidentally, the compilers do not give us a generic way of doing that across all architectures. Supporting vector instructions on an architecture requires using compiler pragma directives. At present, there are directives for both GCC and Clang. ICC was tested and was found to need its own directives, which were not added, so anyone compiling ZFS with ICC will not have vector instructions emitted inside the kernel. For x86 and x86_64, AVX2 will be generated. This is mostly a proof of concept demonstration that shows that modern compilers are capable of generating optimal vector instructions from generic vector code. This comes with a caveat. GCC is actually unable to generate good assembly on its own, so a single handwritten instruction was added to fix the native case. In the byteswap case, another instruction is needed by GCC, but this was not implemented. On the other hand, Clang generates the correct instructions without any need for help. For POWER, VSX instructions will be generated. This will only occur on POWER8 or later with Clang or POWER9 or later with GCC. The assembly generated by Clang for POWER8 appears optimal. GCC's assembly output appears substantially less optimal, but it becomes less terrible when built for POWER9 and later. That is why we require POWER9 as a minimum for GCC, but only require POWER8 as a minimum for Clang. Support for AARCH64/ARM was considered, but the build system passes -mgeneral-regs-only and upon seeing this, both GCC and Clang refuse to emit NEON instructions. This is incompatible with the idea of selectively enabling them on key functions, so support for ARM was not implemented. Support for SPARC was also considered, but its SIMD instructions have a maximum 64-bit width. We need greater widths to be able to do 64-bit additions to be done simultaneously, so it was not possible to use its SIMD instructions. The result is that the best possible on SPARC is the superscalar code, which this resembles without vector instructions. Support for MIPS was also considered, but MIPS Release 5 is required for that, almost no hardware implements MIPS Release 5 and it was not apparent how to get the compilers to generate SIMD instructions for it. It would not surprise me if the compilers do not support MIPS Release 5's SIMD instructions at all. Support for Loongson was also considered, but a lack of documentation (depsite it being MIPS-based) prevented it from being done. Support for S390 was also considered, but it required compiling for the rather new Z13, and the compilers did not appear to emit vector instructions for it. Like for MIPS, it is quite possible that the compilers do not know how to emit them. Support for RISC-V was also considered. While the RISC-V Vector Extension was ratified in 2021, it does not appear to be supported by compilers at this time. Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu> Pull-request: #14234 part 2/2 |
||||||||||||||||||
|
||||||||||||||||||
|
Richard Yao
richard.yao@alumni.stonybrook.edu |
|
|
|
|||||||||||||||
|
Add POWER ISA 3.00 detection Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu> Pull-request: #14234 part 1/2 |
||||||||||||||||||
|
Richard Yao
richard.yao@alumni.stonybrook.edu |
|
|
|
|||||||||||||||
|
Add generic fletcher4 vector implementation This is written using GNU C's generic vector extensions to the C standard. This compiles on all supported architectures. However, initially, it only generates vector instructions in the kernel on x86, x86_64 and power64 when either AVX2 is avaliable or VSX is avaliable. Other architectures should see something equivalent to superscalar64.i In userspace, we are more likely to see vector instructions automatically generated for other architectures, but this depends on what the compiler is willing to use by default, since we make no attempt to force vector instruction generation on other architectures. Coincidentally, the compilers do not give us a generic way of doing that across all architectures. Supporting vector instructions on an architecture requires using compiler pragma directives. At present, there are directives for both GCC and Clang. ICC was tested and was found to need its own directives, which were not added, so anyone compiling ZFS with ICC will not have vector instructions emitted inside the kernel. For x86 and x86_64, AVX2 will be generated. This is mostly a proof of concept demonstration that shows that modern compilers are capable of generating optimal vector instructions from generic vector code. This comes with a caveat. GCC is actually unable to generate good assembly on its own, so a single handwritten instruction was added to fix the native case. In the byteswap case, another instruction is needed by GCC, but this was not implemented. On the other hand, Clang generates the correct instructions without any need for help. For POWER, VSX instructions will be generated. This will only occur on POWER8 or later with Clang or POWER9 or later with GCC. The assembly generated by Clang for POWER8 appears optimal. GCC's assembly output appears substantially less optimal, but it becomes less terrible when built for POWER9 and later. That is why we require POWER9 as a minimum for GCC, but only require POWER8 as a minimum for Clang. Support for AARCH64/ARM was considered, but the build system passes -mgeneral-regs-only and upon seeing this, both GCC and Clang refuse to emit NEON instructions. This is incompatible with the idea of selectively enabling them on key functions, so support for ARM was not implemented. Support for SPARC was also considered, but its SIMD instructions have a maximum 64-bit width. We need greater widths to be able to do 64-bit additions to be done simultaneously, so it was not possible to use its SIMD instructions. The result is that the best possible on SPARC is the superscalar code, which this resembles without vector instructions. Support for MIPS was also considered, but MIPS Release 5 is required for that, almost no hardware implements MIPS Release 5 and it was not apparent how to get the compilers to generate SIMD instructions for it. It would not surprise me if the compilers do not support MIPS Release 5's SIMD instructions at all. Support for Loongson was also considered, but a lack of documentation (depsite it being MIPS-based) prevented it from being done. Support for S390 was also considered, but it required compiling for the rather new Z13, and the compilers did not appear to emit vector instructions for it. Like for MIPS, it is quite possible that the compilers do not know how to emit them. Support for RISC-V was also considered. While the RISC-V Vector Extension was ratified in 2021, it does not appear to be supported by compilers at this time. Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu> Pull-request: #14234 part 2/2 |
||||||||||||||||||
|
||||||||||||||||||
|
Richard Yao
richard.yao@alumni.stonybrook.edu |
|
|
|
|||||||||||||||
|
Add POWER ISA 3.00 detection Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu> Pull-request: #14234 part 1/2 |
||||||||||||||||||
|
Richard Yao
richard.yao@alumni.stonybrook.edu |
|
|
|
|||||||||||||||
|
Add generic fletcher4 vector implementation This is written using GNU C's generic vector extensions to the C standard. This compiles on all supported architectures. However, initially, it only generates vector instructions in the kernel on x86, x86_64 and power64 when either AVX2 is avaliable or VSX is avaliable. Other architectures should see something equivalent to superscalar64.i In userspace, we are more likely to see vector instructions automatically generated for other architectures, but this depends on what the compiler is willing to use by default, since we make no attempt to force vector instruction generation on other architectures. Coincidentally, the compilers do not give us a generic way of doing that across all architectures. Supporting vector instructions on an architecture requires using compiler pragma directives. At present, there are directives for both GCC and Clang. ICC was tested and was found to need its own directives, which were not added, so anyone compiling ZFS with ICC will not have vector instructions emitted inside the kernel. For x86 and x86_64, AVX2 will be generated. This is mostly a proof of concept demonstration that shows that modern compilers are capable of generating optimal vector instructions from generic vector code. This comes with a caveat. GCC is actually unable to generate good assembly on its own, so a single handwritten instruction was added to fix the native case. In the byteswap case, another instruction is needed by GCC, but this was not implemented. On the other hand, Clang generates the correct instructions without any need for help. For POWER, VSX instructions will be generated. This will only occur on POWER8 or later with Clang or POWER9 or later with GCC. The assembly generated by Clang for POWER8 appears optimal. GCC's assembly output appears substantially less optimal, but it becomes less terrible when built for POWER9 and later. That is why we require POWER9 as a minimum for GCC, but only require POWER8 as a minimum for Clang. Support for AARCH64/ARM was considered, but the build system passes -mgeneral-regs-only and upon seeing this, both GCC and Clang refuse to emit NEON instructions. This is incompatible with the idea of selectively enabling them on key functions, so support for ARM was not implemented. Support for SPARC was also considered, but its SIMD instructions have a maximum 64-bit width. We need greater widths to be able to do 64-bit additions to be done simultaneously, so it was not possible to use its SIMD instructions. The result is that the best possible on SPARC is the superscalar code, which this resembles without vector instructions. Support for MIPS was also considered, but MIPS Release 5 is required for that, almost no hardware implements MIPS Release 5 and it was not apparent how to get the compilers to generate SIMD instructions for it. It would not surprise me if the compilers do not support MIPS Release 5's SIMD instructions at all. Support for Loongson was also considered, but a lack of documentation (depsite it being MIPS-based) prevented it from being done. Support for S390 was also considered, but it required compiling for the rather new Z13, and the compilers did not appear to emit vector instructions for it. Like for MIPS, it is quite possible that the compilers do not know how to emit them. Support for RISC-V was also considered. While the RISC-V Vector Extension was ratified in 2021, it does not appear to be supported by compilers at this time. Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu> Pull-request: #14234 part 2/2 |
||||||||||||||||||
|
||||||||||||||||||
|
Jorgen Lundman
lundman@lundman.net |
|
|
|
|||||||||||||||
|
maybe we need to add header files to makefile Pull-request: #14228 part 11/11 |
||||||||||||||||||
|
||||||||||||||||||
|
Jorgen Lundman
lundman@lundman.net |
|
|
|
|||||||||||||||
|
maybe we need to add header files to makefile Pull-request: #14228 part 11/11 |
||||||||||||||||||
|
lundman
lundman@play.lundman.net |
|
|
|
|||||||||||||||
|
Merge branch 'UnifyLinux' of github.com:openzfsonwindows/openzfs into UnifyLinux Pull-request: #14228 part 10/10 |
||||||||||||||||||
|
||||||||||||||||||
|
lundman
lundman@play.lundman.net |
|
|
|
|||||||||||||||
|
Add header path to libicp Pull-request: #14228 part 7/7 |
||||||||||||||||||
|
lundman
lundman@play.lundman.net |
|
|
|
|||||||||||||||
|
FreeBSD needs one as well Pull-request: #14228 part 6/6 |
||||||||||||||||||
|
lundman
lundman@play.lundman.net |
|
|
|
|||||||||||||||
|
FreeBSD needs one as well Pull-request: #14228 part 6/6 |
||||||||||||||||||
|
lundman
lundman@play.lundman.net |
|
|
|
|||||||||||||||
|
FreeBSD needs one as well Pull-request: #14228 part 6/6 |
||||||||||||||||||
|
||||||||||||||||||
|
lundman
lundman@play.lundman.net |
|
|
|
|||||||||||||||
|
Windows header snuck in there Pull-request: #14228 part 5/5 |
||||||||||||||||||
|
||||||||||||||||||
|
Jorgen Lundman
lundman@lundman.net |
|
|
|
|||||||||||||||
|
Restore ELF ifdef Pull-request: #14228 part 4/5 |
||||||||||||||||||
|
||||||||||||||||||
|
lundman
lundman@play.lundman.net |
|
|
|
|||||||||||||||
|
Add includes for Linux Pull-request: #14228 part 3/5 |
||||||||||||||||||
|
||||||||||||||||||
|
Jorgen Lundman
lundman@lundman.net |
|
|
|
|||||||||||||||
|
Linux assembler changes Plus missing file Signed-off-by: Jorgen Lundman <lundman@lundman.net> Pull-request: #14228 part 2/5 |
||||||||||||||||||
|
||||||||||||||||||
|
Jorgen Lundman
lundman@lundman.net |
|
|
|
|||||||||||||||
|
All the renames and deletes (Linux) Pull-request: #14228 part 1/5 |
||||||||||||||||||
|
Jorgen Lundman
lundman@lundman.net |
|
|
|
|||||||||||||||
|
Restore ELF ifdef Pull-request: #14228 part 4/4 |
||||||||||||||||||
|
||||||||||||||||||
|
lundman
lundman@play.lundman.net |
|
|
|
|||||||||||||||
|
Add includes for Linux Pull-request: #14228 part 3/4 |
||||||||||||||||||
|
||||||||||||||||||
|
Jorgen Lundman
lundman@lundman.net |
|
|
|
|||||||||||||||
|
Linux assembler changes Plus missing file Signed-off-by: Jorgen Lundman <lundman@lundman.net> Pull-request: #14228 part 2/4 |
||||||||||||||||||
|
||||||||||||||||||
|
Jorgen Lundman
lundman@lundman.net |
|
|
|
|||||||||||||||
|
All the renames and deletes (Linux) Pull-request: #14228 part 1/4 |
||||||||||||||||||
|
Ameer Hamza
ahamza@ixsystems.com |
|
|
|
|||||||||||||||
|
zfs_zaccess_trivial() causes deadlock for xattr attributes zfs_zaccess_trivial() calls the generic_permission() to read xattr attributes. This may cause deadlock if xattr and dent locks were already held. This commit add support to prevent deadlock if dent_lock() is held from generic_permission() context. Signed-off-by: Ameer Hamza <ahamza@ixsystems.com> Pull-request: #14220 part 1/1 |
||||||||||||||||||
|
||||||||||||||||||
|
Alexander Motin
mav@FreeBSD.org |
|
|
|
|||||||||||||||
|
Micro-optimize zrl_remove(). atomic_dec_32() should be a bit lighter than atomic_dec_32_nv(). Signed-off-by: Alexander Motin <mav@FreeBSD.org> Pull-request: #14200 part 1/1 |
||||||||||||||||||
|
Alexander Motin
mav@FreeBSD.org |
|
|
|
|||||||||||||||
|
Remove few pointer dereferences in dbuf_read(). Signed-off-by: Alexander Motin <mav@FreeBSD.org> Pull-request: #14199 part 1/1 |
||||||||||||||||||
|
Alexander Motin
mav@FreeBSD.org |
|
|
|
|||||||||||||||
|
Switch dnode stats to wmsums. I've noticed that some of those counters are used in hot paths like dnode_hold_impl(), and results of this change is visible in profiler. Signed-off-by: Alexander Motin <mav@FreeBSD.org> Pull-request: #14198 part 1/1 |
||||||||||||||||||
|
szubersk
szuberskidamian@gmail.com |
|
|
|
|||||||||||||||
|
zfs_setup_cmdline_props(): fix access violation First check if property is not an user property, then if it is not ineritable. Without this fix any user property (enum value -1) causes memory access violation inside zfs_prop_inheritable(). Signed-off-by: szubersk <szuberskidamian@gmail.com> Pull-request: #14187 part 8/8 |
||||||||||||||||||
|
szubersk
szuberskidamian@gmail.com |
|
|
|
|||||||||||||||
|
zfs_setup_cmdline_props(): fix access violation First check if property is not an user property, then if it is not ineritable. Without this fix any user property (enum value -1) causes memory access violation inside zfs_prop_inheritable(). Pull-request: #14187 part 8/8 |
||||||||||||||||||
|
Ameer Hamza
ahamza@ixsystems.com |
|
|
|
|||||||||||||||
|
zed: unclean disk attachment faults the vdev If the attached disk already contains a vdev GUID, it means the disk is not clean. In such a scenario, the physical path would be a match that makes the disk faulted when trying to online it. So, we would only want to proceed if either GUID matches with the last attached disk or the disk is in a clean state. Signed-off-by: Ameer Hamza <ahamza@ixsystems.com> Pull-request: #14181 part 1/1 |
||||||||||||||||||
|
Ameer Hamza
ahamza@ixsystems.com |
|
|
|
|||||||||||||||
|
zed: unclean disk attachment faults the vdev If the attached disk already contains a vdev GUID, it means the disk is not clean. In such a scenario, the physical path would be a match that makes the disk faulted when trying to online it. So, we would only want to proceed if either GUID matches with the last attached disk or the disk is in a clean state. Signed-off-by: Ameer Hamza <ahamza@ixsystems.com> Pull-request: #14181 part 1/1 |
||||||||||||||||||
|
szubersk
szuberskidamian@gmail.com |
|
|
|
|||||||||||||||
|
Fix Clang 15 compilation errors - Clang 15 doesn't support `-fno-ipa-sra` anymore. Do a separate check for `-fno-ipa-sra` support by $KERNEL_CC. - Don't enable `-mgeneral-regs-only` for certain module files. Fix #13260 - Scope `GCC diagnostic ignored` statements to GCC only. Clang doesn't need them to compile the code. Signed-off-by: szubersk <szuberskidamian@gmail.com> Pull-request: #14150 part 2/2 |
||||||||||||||||||
|
szubersk
szuberskidamian@gmail.com |
|
|
|
|||||||||||||||
|
Fix GCC 12 compilation errors Squelch false positives reported by GCC 12 with UBSan. Signed-off-by: szubersk <szuberskidamian@gmail.com> Pull-request: #14150 part 1/2 |
||||||||||||||||||
|
Brian Atkinson
batkinson@lanl.gov |
|
|
|
|||||||||||||||
|
Cleaning up dmu_write_direct_done() Instead of redirtying the dirty record in the event their is an IO error with a direct IO write, we should just do like we do on success. This means just waiting for the other dirty records to sync out so we are never in an inconsistent state for the TXG's and the dirty records. This change also allows for further cleanup in the function as well. Signed-off-by: Brian Atkinson <batkinson@lanl.gov> Pull-request: #10018 part 7/7 |
||||||||||||||||||
|
Brian Atkinson
batkinson@lanl.gov |
|
|
|
|||||||||||||||
|
Additional DEBUGGING Removing the -r (runtime) parameter to manipulate_user_buffer. We instead will always only write up to numblocks and manipulate the buffer. The reason for this is we don't want to limit ourselves to only 8 blocks constantly being overwritten. Also added in that we should never do reexecution of a ZIO that we have flagged to have a direct write verify checksum error. Signed-off-by: Brian Atkinson <batkinson@lanl.gov> Pull-request: #10018 part 6/6 |
||||||||||||||||||
|
Brian Atkinson
batkinson@lanl.gov |
|
|
|
|||||||||||||||
|
Additional DEBUGGING Removing the -r (runtime) parameter to manipulate_user_buffer. We instead will always only write up to numblocks and manipulate the buffer. The reason for this is we don't want to limit ourselves to only 8 blocks constantly being overwritten. Also added in that we should never do reexecution of a ZIO that we have flagged to have a direct write verify checksum error. Signed-off-by: Brian Atkinson <batkinson@lanl.gov> Pull-request: #10018 part 6/6 |
||||||||||||||||||