Yes, @ahrens - I was incorrectly thinking of use case associated with initializing physical blocks when disk is either TCG/SED drive, or God-forbid, using some sort of RAID device in where there is already some sort of logical/physical mapping.
* I did mention some parts of disk never getting written to, certainly there must be parts, especially if the pool has a heck of a lot of free space. The more free space you have, the more writes that get done needlessly, which means unnecessary write overhead. * In cases of the initialization required with TCG/SED drives, then each physical block of data (whatever the internal size is) has approximately a 50% penalty on first write or read per the SEAGATE and HGST product manuals. That is because once the bands are configured and the 256-bit "password" is set, then a full write pass is required to compute ECC for the bits on the disk that are not addressable via the vanilla READ/WRITE CDBs * To get the total number of bits you need to look at the specs of a drive where it talks about how error rate ie, 1 x 10E15 or whatever. But these numbers are nothing you have to worry about as those ECC bits are maintained inside the SSD or HDD firmware. * There are corner cases where physical data that was never written to using this mechanism would end up being read. From a SCSI engineer perspective, read-ahead,pre-fetch settings in mode pages could cause disks to read data that never had ECC data written. * In the TCG/SED initialization use case, this mechanism as described is unsuitable, because still a user could always just do a dd at the /dev/rdsk level and read uninitialized blocks. But as you said, the use case I am thinking of is different then the one you are designing for, so all the inherent problems you would get with a partially initialized target are moot. So basically outside of making sure the dump and potentially looking at whether some application is doing raw I/O at physical device then just warning people about appropriate use cases should be sufficient. (Well, maybe just consider a thought experiment with a freshly built RAIDZ2 pool using 8TB disks for a large data repository that only has a few filesystems to start) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/586#issuecomment-374747699 ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T6777d2c2033b2134-Mbb1dc2f2c508d9cba02ce30e Delivery options: https://openzfs.topicbox.com/groups
