Bug 1201769

What kind of collision are you actually referring to? This isn't simple "parity" (0x1) we are talking about, but mighty CRC32C. It's perfectly suitable for the purpose of protecting against the expected failures on storage, with hardware acceleration and parallel execution. Lack of cryptographic strength, but strong for it's purpose. If you are talking about cryptographic collision resistance, that is almost orthogonal. And for that you are looking for authenticated encryption.

(In reply to Andreas Stieger from comment #1)
> What kind of collision are you actually referring to? This isn't simple
> "parity" (0x1) we are talking about, but mighty CRC32C. It's perfectly
> suitable for the purpose of protecting against the expected failures on
> storage, with hardware acceleration and parallel execution. Lack of
> cryptographic strength, but strong for it's purpose. If you are talking
> about cryptographic collision resistance, that is almost orthogonal. And for
> that you are looking for authenticated encryption.

the collisions i was referring to is the same crc32c check sums for different files?  i guess we are storing a lot more data than we used to, billions or trillions of files in some cases.

authenticated encryption sounds interesting, but don't want to be entering passwords to load a system.

what about enabling crc64c as we are now using 64bit computers and servers.

I think we may have a confusion of what the checksum actually performs here. Non-content addressable file systems (as the ones in question) will happily store files with identical name and content. Collisions are of no consequence in this application since they do not lead to any incorrect de-duplication - as opposed to e.g. sha-1 collisions concerning git/svn, or hash maps/tables.

Changing the default has consequences for both performance and compatibility when exchanging data. There is no upstream support for a 64 bit CRC in btrfs I am aware of that could be enabled. The fastest cryptographic hash supported in btrfs is reported as still 10x slower than crc32c, the fastest non-cryptographic 64 bit one is x1.44.

I think your request boils free-form mkfs options to be passed along from YaST. YaST supports free-form options for mount but not mkfs. But since this is the blueprint for a footgun, would the recommended way not be to call mkfs with the desired options manually?

Is there a real-life use case behind this, or isn't this just a thought experiment?

(In reply to Stefan Hundhammer from comment #4)
> Is there a real-life use case behind this, or isn't this just a thought
> experiment?

at this point there isn't a real life use.  just thought it would be a good idea to have options.

(In reply to John Shand from comment #5)
> (In reply to Stefan Hundhammer from comment #4)
> > Is there a real-life use case behind this, or isn't this just a thought
> > experiment?
> 
> at this point there isn't a real life use.  just thought it would be a good
> idea to have options.

I see. However, it does not make too much sense to just add an extra option without a real use case, specially now that we're trying to simplify the installer. Sorry.

Hope you don't mind closing it as a WONTFIX.

Thank you!.