@dlethe I think you're thinking about a different use case than we are. We want to avoid the first-write penalty on virtualized storage (e.g. ESX VMFS, AWS EBS, etc). But perhaps your use case would also benefit from initialization! Let me address a few of your specific points:
> The logic insures that a pool will do unnecessary write I/Os on parts of the > pool that certainly will never get written to ... ever. How do you know that? It's highly likely that all parts of the pool will be eventually written to, even if the pool never gets close to being "full", due to copy-on-write. > This will also not insure that all physical blocks even get initialized in > the first place. (you must not skip over all areas of disk used for > housekeeping, dumps, swap, metadata, etc ...) Swap [zvols] and [ZFS] metadata are normal parts of the pool so there's nothing special there - since they've been written, there's no need to write them again to initialize. Reservations for zvols are just an accounting trick, so that unallocated space will be initialized. Dump [zvols] are a special case and I think you're right that they won't be initialized, since we pre-allocate them and then write in place. You could get around this by doing the initialize before creating the dump zvol. Or (as in our case) by having different pools for root and production data (and not worrying too much about performance of the root pool, and dump in particular). I'm not sure what you mean by "housekeeping". > Initialization requires 100% of them in order to calculate ECC Data. The > penalty is approximately 50% hit on first write, and reading a block that has > not been initialized can be much, much worse as it can result in ECC > recovery. So if you even do this, you had better get 100% of all physical > blocks on all disks, and leave nothing to chance. What if you have to > resilver?? This is definitely a different use case than we had in mind. At what granularity is the ECC generated? Surely it isn't one ECC value for the entire disk? It seems like the ECC must be per "chunk", and if that "chunk" has been entirely written then you get this benefit. So if we can get 99.99% of the chunks, that seems worthwhile, since the vast majority of future writes will get the benefit of initialization. > So bottom line, unless EVERY LBA of the disk drive that could ever be read > from, even slices not used for ZFS, are initialized, Can you expand on your thought process as to why every single block needs to be written? Why doesn't initializing 99% of the blocks result in 99% of the benefit? > then perhaps this entire project should be suspended until performance is > modeled on uninitialized storage We did model performance on uninitialized [EBS and VMFS] storage. I don't see that mentioned here so I'll try to find the results. > before doing any more development. We aren't doing any more development either way - this project is complete and ready to integrate. -- 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-374725202 ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T6777d2c2033b2134-M22150a4d988925ecd52531cd Delivery options: https://openzfs.topicbox.com/groups
