ZFS zpool freezes

mro

mro

when e.g. scrubbing a readonly zpool, that scrub process hangs unkillable and even prevents shutdown and others, e.g. btop.

I expect an error message, not a freeze.

Reproduce:

Bash: 
$ truncate -s 100M /tmp/100m
$ doas zpool create -o compatibility=openzfs-2.0-linux demo-freeze /tmp/100m
$ doas zfs set mountpoint=/mnt/demo-freeze demo-freeze
$ doas zpool export demo-freeze
$ doas zpool import -o readonly=on -d /tmp/100m demo-freeze
$ doas zpool scrub demo-freeze

Bash: 
$freebsd-version -kru ; uname -aKU
14.3-RELEASE-p5
14.3-RELEASE-p5
14.3-RELEASE-p5
FreeBSD mx250.local 14.3-RELEASE-p5 FreeBSD 14.3-RELEASE-p5 GENERIC amd64 1403000 1403000
$ zpool --version
zfs-2.2.7-FreeBSD_ge269af1b3
zfs-kmod-2.2.7-FreeBSD_ge269af1b3

Who is interested in such a report?
 
I'm not a zfs expert but I think the check for errors is done automatically (somehow). zpool-scrub(8) repair stuff, so it doesn't make sense to import in read-only mode.

EDIT: It also probably wants to write metadata to the pool...
 
W.hâ/t said:
I'm not a zfs expert but I think the check for errors is done automatically (somehow). zpool-scrub(8) repair stuff, so it doesn't make sense to import in read-only mode.
Click to expand...
My thoughts too.

Is ZFS a good filesystem for a SD card, those tend to aged quick and not very well?
If compatibility is what you seek, FAT can be a good choice, not modern though but it works for both FreeBSD and Linux.
 
This here is not about SD-cards.

Please stay on topic and open a new topic if you feel like.
 
I was able to reproduce the issue. No way to stop it as it is in an uninterruptible state.

No matter what I tried, it wouldn't die:
Code: 
root@skulltrail:~ # rm -f -r /tmp/100m
root@skulltrail:~ # ls -l /tmp/100m
ls: /tmp/100m: No such file or directory
root@skulltrail:~ # ps -aux | grep 1198
root       1198   0.0  0.0 20672  8360  0  D+   10:55     0:00.01 zpool scrub d
root       1294   0.0  0.0 13836  2408  1  S+   11:28     0:00.00 grep 1198
root@skulltrail:~ # kill -9 1198
root@skulltrail:~ # kill -6 1198
root@skulltrail:~ # ps -aux | grep 1198
root       1198   0.0  0.0 20672  8360  0  D+   10:55     0:00.01 zpool scrub d
root       1296   0.0  0.0 13836  2396  1  S+   11:29     0:00.00 grep 1198
root@skulltrail:~ # date
Wed Oct 29 11:29:19 CDT 2025

shutdown -r now worked fine.
 
  • Like
Reactions: mro
a fix would probably be to modify /sys/contrib/openzfs/module/zfs/zfs_ioctl.c and add POOL_CHECK_SUSPENDED | POOL_CHECK_READONLY
as the pool_check arg instead of POOL_CHECK_NONE
C: 
        zfs_ioctl_register("scrub", ZFS_IOC_POOL_SCRUB,
            zfs_ioc_pool_scrub, zfs_secpolicy_config, POOL_NAME,
            POOL_CHECK_NONE, B_TRUE, B_TRUE,
            zfs_keys_pool_scrub, ARRAY_SIZE(zfs_keys_pool_scrub));

but the intention seems to be to allow scrub with such a pool so probably needs a deeper investigation
 
I wonder if running the the final scrub command under truss would give any indication as to where it's hanging. Any indications in syslog?
 
Code: 
[root@freebsd ~]# procstat -kk 49559
  PID    TID COMM                TDNAME              KSTACK
49559 100195 zpool               -                   mi_switch+0x108 _cv_wait+0x104 txg_wait_synced_impl+0xa4 txg_wait_synced+0xc dsl_sync_task_common+0x15c dsl_scan+0x164 zfs_ioc_pool_scrub+0x114 zfsdev_ioctl_common+0x45c zfsdev_ioctl+0x10c devfs_ioctl+0xf0 vn_ioctl+0xcc devfs_ioctl_f+0x20 kern_ioctl+0x2f8 sys_ioctl+0x13c do_el0_sync+0x658 handle_el0_sync+0x48
 
mro said:
This here is not about SD-cards.

Please stay on topic and open a new topic if you feel like.
Click to expand...
Alright, I was only reacting to on your own post, next time don't bring any link then you will be just fine, but fair enough I 'll focus :)

I am not an expert but for me your issue is like asking why fsck cannot work properly on a mounted file-system, the answer seems obvious: it is just not designed to work this way and if you do problems are expected.
Can you explain why you want to run "scrub" on a read-only file-system? is there any purpose or is it an experiment?
 
mro said:
I expect an error message, not a freeze.
Click to expand...
Probably something like:
cannot scrub 'demo-freeze': pool is read-only

Can't cancel a scrub on a readonly pool #1999, Brian Behlendorf on Oct 30, 2014:
This sounds like a bug to me. We should not allow a scrub to be started if the pool is imported read-only. A patch to handle this case should be fairly straight forward.
Click to expand...

So, a bug.
A FreeBSD PR or an OpenZFS issue, perhaps both.
 
The patch is pretty straightforward:
github.com

Prevent scrubbing a read-only pool by behlendorf · Pull Request #17717 · openzfs/zfs

Motivation and Context Issue #17527 Description While it would be nice to be able to scrub a pool imported read-only this will currently trip an ASSERT. Additionally, while it would be nice to sup...
github.com github.com

Looks like 2.2.x is still supported. It just had a release in August. No MFHs to any branches yet, except in a developer's fork:
github.com

Prevent scrubbing a read-only pool · behlendorf/zfs@3dc3458

While it would be nice to be able to scrub a pool imported read-only this will currently trip an ASSERT. Before we can support this there are some designs challenges which need to be thought throu...
github.com github.com
 
You must log in or register to reply here.
Back
Top