With respect to relling's Oct 3 2009 7:46 AM Post: > I think you are missing the concept of pools. Pools contain datasets. > One form of dataset is a file system. Pools do not contain data per se, > datasets contain data. Reviewing the checksums used with this > heirarchy in mind:
> Pool > Label [SHA-256] > Uberblock [SHA-256] > Metadata [fletcher4] > Gang block [SHA-256] > ZIL log [fletcher2] > Dataset (file system or volume) > Metadata [fletcher4] > Data [fletcher2 (default, today), fletcher4, or SHA-256] > Send stream [fletcher4] > With this in mind, I don't understand your steel analogy. I am assuming based on the context of our presentation that the above list of "pool stuff" is exhaustive, that this is everything not in a dataset. My "steel analogy" is based on the assumption that the pool-level stuff that you list above is needed to gain access to the dataset. If the dataset can be accessed with all of the pool stuff trashed, then my steel thread does not exist. But it also means that the pool stuff is extraneous, so I doubt that this is the case. Given that all of the pool stuff is either sha256 or fletcher4 except for the ZIL, I have new understanding that suggests (though I don't understand the details of the system) that I am not depending on Fletcher2 protected data, and my steel thread is actually pretty thick, not 0.001". Based on your comments regarding the ZIL, I am infering that stuff is written there and never used except for a restart after a messy shutdown. I might be exposed to whatever weakness the Fletcher2 has as implemented, but only in these rare circumstances. Normal transactions and data would not be impacted by corruption in the ZIL blocks since they would never be used. So a large layer of probability protects me: I would have to have a crash at the same instance of corruption in the ZIL that hits on a Fletcher2 weakness. Based on all of this I believe I am relatively happy simply copying my data, not recreating my zpool. As Darren Moffat taught me, I can "zfs set checksum=sha256 zfs01" where zfs01 is the zpool, then "zfs send zfs01/h...@snapshot | zfs receive zfs01/home.new" and the new file system will all be sha256 as long as I don't specify the -R option on the zfs send, and all of this is supported in U4. I believe it has to be supported due to the presence of files with properties in the (odd?) zfs file system that exists at the zfs01 zpool level before creation of zfs file systems. So assuming the above process works, this thread is done as far as I am concerned right now. Thank you all for your help, not to snub anyone, but Darren, Richard, and Cindy especially come to mind. Thanks for sparring with me until we understood each other. --Ray -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
