Pool Creation doesn't do parity checking?

[boedzals]

Hi

Finally i have finished creating my first TrueNAS system. I have following the getting start guide and successfully creating my first storage pool with RAIDZ2. But then i'm wondering why in TrueNAS system, storage pool creation is not followed by parity checking, is that always the case ? Or maybe i missing something ? Because in my Synology NAS system, Volume creation is always followed by parity checking

 

[jgreco]

ZFS doesn't do parity as a function of the pool. It does parity per written block. This means that when you write a 1MB block on a 5-drive RAIDZ1, it will write four sectors of data, one sector of parity, four more sectors of data, one sector of parity, etc., until 1MB of data has been written.

 

[boedzals]

I see. It's because file system difference. So I'm not missing somethings. Thanks for confirming

 

[sretalla]

A scrub should be scheduled (Under Tasks | Scrub Tasks) as part of your process to set up a pool for long-term health.

That is probably the equivalent of the process on Synology (although I have no idea why they would want to do that immediately on volume creation as there's no parity there to check).

A scrub looks at each block, reading the data and parity parts and checking if all bits are as they should be and can (in the case of RAIDZ or mirrors, but not stripes*) correct any errors (so-called bit-rot) found.

* you can actually get this even on stripes by setting the zfs parameter of copies to a number greater than 1 (of course suffering the natural capacity consequence of that), meaning that if one of the copies of the block is bad, there's another that might be OK.

 

[boedzals]

A scrub should be scheduled (Under Tasks | Scrub Tasks) as part of your process to set up a pool for long-term health.

I will do that, thanks.

That is probably the equivalent of the process on Synology (although I have no idea why they would want to do that immediately on volume creation as there's no parity there to check).

A scrub looks at each block, reading the data and parity parts and checking if all bits are as they should be and can (in the case of RAIDZ or mirrors, but not stripes*) correct any errors (so-called bit-rot) found.

* you can actually get this even on stripes by setting the zfs parameter of copies to a number greater than 1 (of course suffering the natural capacity consequence of that), meaning that if one of the copies of the block is bad, there's another that might be OK.

Thanks for the info

 

[Arwen]

...
But then i'm wondering why in TrueNAS system, storage pool creation is not followed by parity checking, is that always the case ? Or maybe i missing something ? Because in my Synology NAS system, Volume creation is always followed by parity checking

I think you mean parity creation, not checking.

A scrub should be scheduled (Under Tasks | Scrub Tasks) as part of your process to set up a pool for long-term health.

That is probably the equivalent of the process on Synology (although I have no idea why they would want to do that immediately on volume creation as there's no parity there to check).
...

On a "normal" RAID-5/6, the initial creation causes the RAID parity to be populated. (Or mirror device to be written from it's partner.) So, every single RAID stripe is parity calculated and then parity written. (Or it's possible that a simple zeroing out of the data blocks with appropriate parity is done. That would be 100% writes verses data reads, calculate parity, then write parity.) Otherwise, it would be chaos.

ZFS acts different enough that I sometimes forget that the old RAID-5/6 method required heavy I/O on creation. ZFS pool creation of a 100TB pool takes seconds. (Of course populating a 100TB pool will take LOTS of time...)

 

[boedzals]

I think you mean parity creation, not checking.

Yeah you might be right. Well the status is always say "checking parity consistency..." whether when we create a new volume or adding a new disk to the volume to increase the volume size.

On a "normal" RAID-5/6, the initial creation causes the RAID parity to be populated. (Or mirror device to be written from it's partner.) So, every single RAID stripe is parity calculated and then parity written. (Or it's possible that a simple zeroing out of the data blocks with appropriate parity is done. That would be 100% writes verses data reads, calculate parity, then write parity.) Otherwise, it would be chaos.

ZFS acts different enough that I sometimes forget that the old RAID-5/6 method required heavy I/O on creation. ZFS pool creation of a 100TB pool takes seconds. (Of course populating a 100TB pool will take LOTS of time...)

That's why i was questioning whether i'm doing this right or not since it take a while in my synology NAS to create a volume, but this is only take a second and then all drives online. Thanks for the info

 

[Arwen]

@boedzals - Understood. Keep asking questions as you need to. ZFS is different enough, (and still changing), that it takes time to learn enough to effectively manage and use a ZFS NAS both well and properly.

For example, I was reminded quite recently that I may want to use a L2ARC on my new NAS. Not because I read the same data over and over, but L2ARC devices can be set for Metadata only. Thus, if I am careful, I might just get good Rsync performance for client backups with a L2ARC set for Metadata only. Rsync has to scan metadata to help determine what files to transfer. Meaning if a file's date & time is the same between source and destination, it will skip sending that file.