Does ARC or L2ARC contribute to redundancy?

[Lady-Galadriel]

Background:
Recently I built my next generation NAS, with only 1 x 10TB HDD in the pool. The AI apocalypse caused me to delay buying the Mirror HDD. But, backups are available, so that should be good in the short term.

To speed up access, I added a 500GB NVMe Cache / L2ARC device I had bought before the costs went up.

All seems to be fine, including the RSync backups being sped up.

The question:
Does the Cache / L2ARC device(s) act as additional redundancy for regular pool devices?

Obviously restricted to blocks that actually exist in the Cache / L2ARC...

Discussion:
Reading manual page for zpoolconcepts, section Cache Devices, does not list if checksums are used on the entries. Reading elsewhere, there appear to be no checksums on Cache / L2ARC blocks. This reference does not mention checksums or redundancy:

Open ZFS Docs - L2ARC (cache vdev)

Yet, if there are no checksums on Cache / L2ARC entries, then why would ZFS trust the data?
If a block read did not return a read error, could ZFS mistake bit-rotted data for real data?

Persistent Cache / L2ARC means that a Cache / L2ARC entry could live for years without being evicted. And if Cache / L2ARC entries are not scrubbed for bit-rot, then we have a potential source of corruption.

Additional questions:
These thoughts lead me to these additional questions:

• During a scrub, does ZFS scrub any Cache / L2ARC device?

[no-usernames-left]

Does the Cache / L2ARC device(s) act as additional redundancy for regular pool devices?

No.

[Lady-Galadriel]

Does the Cache / L2ARC device(s) act as additional redundancy for regular pool devices?

No.

Okay.

Do the data blocks in the Cache / L2ARC contain checksums?

[no-usernames-left]

Do the data blocks in the Cache / L2ARC contain checksums?

I have not read the code, but I cannot imagine that they would not, as this would render the integrity guarantees worthless.

[Lady-Galadriel]

Checking with a search engine, I get the following. However, the 2 references, (at the bottom), don't mention checksumming. So I don't trust the information... (AI hallucination...)

OpenZFS and L2ARC Checksum Functionality

Checksum Overview
OpenZFS does not perform checksumming on blocks stored in L2ARC devices. The primary function of L2ARC is to cache data blocks that have been evicted from the ARC (Adaptive Replacement Cache) for potential future reads.

Implications of No Checksum

• Data Integrity: Since L2ARC is not used for data integrity checks, it does not ensure the correctness of the data stored in this cache
• Caching Purpose: The L2ARC is designed to improve read performance by storing evicted data blocks, rather than maintaining data integrity.

Summary
In summary, while L2ARC enhances performance by caching data, it does not include checksumming, which is crucial for verifying data integrity in other storage contexts.
truenas.com
klarasystems.com

[no-usernames-left]

Garbage in, garbage out.

[Lady-Galadriel]

AI = Artificial Information, (aka made up, projections of desires not facts, or out right lies).

[amotin]

L2ARC now stores exactly the same bit-identical data as main storage, so it is verified using the same checksums/MACs. If read or checksum fail, the read is redirected to the main storage. So in a sense it is a form of redundancy. The problem is that it is unpredictable to rely on it. Also I am not sure ZFS can repair corruptions on a main pool with data from L2ARC, but it could be investigated.

[Lady-Galadriel]

L2ARC now stores exactly the same bit-identical data as main storage, so it is verified using the same checksums/MACs.

Great. Thank you.

Now the question is:
    Does a scrub process the Cache / L2ARC devices?

Because if a scrub does not, it probably should. With persistent Cache / L2ARC it is more than theory that a block could exist for many months without being read. (A read should check the checksum, and if bad, invalidate it. Then go to the main data pool vDevs...)

[no-usernames-left]

Does a scrub process the Cache / L2ARC devices?

Almost certainly not.

Because if a scrub does not, it probably should. With persistent Cache / L2ARC it is more than theory that a block could exist for many months without being read.

As described by @amotin above, any cache (L2ARC is also cache, that's the C) corruption would be treated simply as a cache miss, and the data would thus be fetched from the data VDEVs as though it had not been in cache.

And if it's not being read for months, it has no business being in cache...

[amotin]

I don't think scrub touches L2ARC. It makes no sense if all it do is invalidate found corrupted blocks without recovering them. That is better do on demand. The only thing that would make sense is to recover found main pool corruptions with data from L2ARC.

[Lady-Galadriel]

@no-usernames-left

And if it's not being read for months, it has no business being in cache...

In most, (if not almost all), use cases that would be true. In my case, the NAS is a long term dumping ground, media backup and backup target for 4 computers. The backups occur generally every 2 weeks, but could be longer. With the Cache / L2ARC entries, especially Metadata, RSync backups run faster.

@amotin

It makes no sense if all it do is invalidate found corrupted blocks without recovering them.

Actually it does make a little sense in that if you see problems with the Cache / L2ARC device, you can start considering replacement.

The only thing that would make sense is to recover found main pool corruptions with data from L2ARC.

Yes, that was more or less my original question / idea. My new NAS had a single HDD drive pool, with Cache / L2ARC. So, any data corruption that existed on the HDD, but a copy was in the Cache / L2ARC could in theory be recovered.

Note: I am not trying to argue, just putting forth another view point.

[gmelikov]

fyi #19255