Asynchronus drive activity of same pool

[BillyElliot]

Hello dear forum,
Im new here, so if I made any mistakes by posting into the wrong subthread pls be kind:)
My hardware is in my signature.
The current OS Version is: TrueNAS-SCALE-22.12.1

My issue is, that my Pool1 consisting of 3x Seagate ironwolf drives does have a strange IO behavior. As in: only 2 of the 3 drives are repeatedly written to with like 2-8kbit at idle. My containers and VMs are running on the SSD and my System Datapool is on my SSD aswell(at least I think so, as my bootSSD has even more activity). No Container or VM has been given access to this pool. Only SMB shares are configured, but even when disabling the SMB Service, the writes continue.
Why this is bothering me, is because at least right now i have to sleep in the same room with this server, and therefore i have configured the drives to spin down after a certain time, so at night this server is completly silent. The 1 drive of this pool which does not get IO activity is also spinning down, but the other two do not. The question is, how can this even be, if this is ONE ZFS POOL? Is it not supposed to be written to simulaneosly?
See attached image for reference.

Thank you for your time and effort,
Best regards
BillyElliot

 

[NugentS]

"zpool status" - and post it in tags please - the formatting is important

 

[BillyElliot]

Hi, @NugentS,
thank you for your response.
here is the output. The Pool in Question is „Pool-1“.
thank you for your time!

Code:

admin@truenas[~]$ sudo zpool status
[sudo] password for admin:
  pool: MyBook External Backup
 state: ONLINE
  scan: scrub repaired 0B in 08:17:47 with 0 errors on Sun Feb 26 20:17:49 2023
config:

        NAME                                    STATE     READ WRITE CKSUM
        MyBook External Backup                  ONLINE       0     0     0
          87cc3216-b208-4e91-910b-922236700e01  ONLINE       0     0     0

errors: No known data errors

  pool: Pool-1
 state: ONLINE
  scan: scrub repaired 0B in 03:15:19 with 0 errors on Sun Feb 19 15:15:21 2023
config:

        NAME                                      STATE     READ WRITE CKSUM
        Pool-1                                    ONLINE       0     0     0
          raidz1-0                                ONLINE       0     0     0
            513ebbb0-3caa-45a7-a544-be94cbb608fb  ONLINE       0     0     0
            d4a20afd-8e3d-457b-9a44-76d0864f46c5  ONLINE       0     0     0
            cf3f8334-792f-4bdf-bdc7-f37960a3e0f3  ONLINE       0     0     0

errors: No known data errors

  pool: boot-pool
 state: ONLINE
status: Some supported and requested features are not enabled on the pool.
        The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
  scan: scrub repaired 0B in 00:00:06 with 0 errors on Sat Feb 25 03:45:07 2023
config:

        NAME         STATE     READ WRITE CKSUM
        boot-pool    ONLINE       0     0     0
          nvme0n1p3  ONLINE       0     0     0

errors: No known data errors

  pool: ssd-storage
 state: ONLINE
  scan: scrub repaired 0B in 00:00:43 with 0 errors on Sun Feb 19 12:00:45 2023
config:

        NAME                                    STATE     READ WRITE CKSUM
        ssd-storage                             ONLINE       0     0     0
          ccecfb65-16c3-4063-ad1a-0bdb6d47715c  ONLINE       0     0     0

errors: No known data errors

  pool: ssd2
 state: ONLINE
  scan: scrub repaired 0B in 00:04:04 with 0 errors on Sun Feb 26 00:04:05 2023
config:

        NAME                                    STATE     READ WRITE CKSUM
        ssd2                                    ONLINE       0     0     0
          ad59ae1e-6b57-4c1f-ace8-bd5e8fbc1566  ONLINE       0     0     0

errors: No known data errors

 

[AlexGG]

If the write is small (single block), then only two disks are involved in the write (in RAIDZ1), regardless of how many disks are in the vdev. This is how RAIDZ layout works. In general, for a single-block write in RAIDZn, (n+1) different disks will be involved.

 

[BillyElliot]

Thank you for your insight, @AlexGG! In hindsight that seems logical.
Therefore this Topic is solved, I guess.
The remaining question is now, what is accessing the pool, if it is not SMB, nor containers or VMs. Do you have any idea on that front too, by any chance? :)
Thank you either way for your help and your time.
BillyElliot

 

[AlexGG]

Do you have any idea on that front too, by any chance? :)

Unfortunately, no.

 

[NugentS]

I would confirm the location of your system dataset - make sure its not on the HDD's

 

[BillyElliot]

Alright everyone.
I found out what the issue was. It was the SWAP, which was automaticly created at Pool creation. Therefore 3x2GB Swap was on my HDD Pool and frequently used.
Thank you everyone for taking time answering.
BillyElliot