Alexander Motin comments

Results 260 comments of


                                            Alexander Motin

ZFS panic in ddt_object_remove(): VERIFY(...) failed during pool operation and boot import on FreeBSD 14.1 with dedup=on

@robn It seems DDT code could be more careful about ZAP read errors handling. In both the old version and the new versions `ddt_lookup()` ignores ZAP read errors, which may...

ZFS panic in ddt_object_remove(): VERIFY(...) failed during pool operation and boot import on FreeBSD 14.1 with dedup=on

`97` means `ECKSUM`, so it really can't read some record from DDT ZAP. We definitely should somehow improve error handling there, but it does not explain how we got into...

ZFS panic in ddt_object_remove(): VERIFY(...) failed during pool operation and boot import on FreeBSD 14.1 with dedup=on

Scrub does not work on read-only imported pool. See https://github.com/openzfs/zfs/issues/14481 and https://github.com/openzfs/zfs/issues/17527 .

Performance degradation above 90% capacity and zpool import failure after power loss above 90%

While very high pool utilization may lead to higher fragmentation and so lower performance, what you describe is not a general case. It might be even a combination of many...

Performance degradation above 90% capacity and zpool import failure after power loss above 90%

Would you have a screenshot of the panic, may be we could have something to talk about.

Scrub makes noticeable impact on normal workloads

Despite 2.1.7 is pretty old and by now out of support, it seems to already include my scrub and I/O scheduler optimizations work to reduce chance of I/O starvation. What...

Scrub makes noticeable impact on normal workloads

I can't say anything without deeper stats. Have you looked on disk, CPU and memory stats during those times? Is the NAS responsive in general and stats itself, for example,...

Scrub makes noticeable impact on normal workloads

Conservative? It seems you've turned everything available "up to 11". And "async" knobs are not about scrub -- one is about read-ahead, another about write-back, that I would not do...

Scrub makes noticeable impact on normal workloads

I just meant that you've done as much as possible within the current design, IIRC. Not that it is bad.

Support recordsize that's a multiple of 4k but not a power of two.

I am not saying it is completely impossible, but it may be quite a messy change. On the other side, I am not sure it is really productive to go...