Richard, with respect to: "This has been answered several times in this thread already. set checksum=sha256 filesystem copy your files -- all newly written data will have the sha256 checksums."
I understand that. I understood it before the thread started. I did not ask this. It is a fact that there is no feature to convert checksums as a part of resilver or some such. I started what utility to use, but quickly zeroed in on zfs send/receive as being the native and presumably best method, but had questions as to how to get the properly set when it was automatically created. etc. Note that my focus in recent portions of the thread has changed to the underlying zpool. Simply changing the checksum=sha356 and copying my data is analogous to hanging my data from a hierarchy of 0.256" welded steel chain, with the top of the hierarchy hanging it all from an 0.001" steel thread. Well, that is not quite fair because there are probabilities involved. Someone is going to pick a link randomly and go after it with a fingernail clipper. If they pick a thick one, I have very little to worry about to say the least. If they pick one of the few dozen? hundred? thousand? (I don't know how many) that contain the structure and services of the underlying zpool, then the nailclipper will not be stopped by the 0.001" thread. I do have 8,000,000,000 links in the chain, and only a a very small fraction are 0.001" thick, and that is strongly in my favor, but I would expect the heads to also spend a disproportionate amount of time over the intent log. It is hard to know how it comes out. I just don't want and 0.001" steel threads protecting my data from the gremlins. I moved to ZFS to avoid gambles. If I wanted gambles I would use linux raid and lvm2. They work well enough if there are no errors. I should have enumerated the knowns and unknowns in my list last night, then I would not have annoyed you with my apparent deafness. (Hopefully I am not still being deaf). I will clarify below, as I should have last night: Given that I only have 1.6TB of data in a 4TB pool, what can I do to change those blocks to sha256 or Fletcher4: (1) Without destroying and recreating the zpool under U4 I know how to fix the user data (just change checksum property on the pool using zfs specifying the pool vs. a zfs file system, then copy the data). I don't know (am ignorant of) blocks comprising the underlying zpool, and how to fix them without recreating the pool. It makes sense to me that at least some would be rewritten in the course of using the system, but (1) I have had no confirmation or denial that this is the case, (2) I don't know if this is all of them or some of them, (3) I don't know if the checksum= parameter would effect these (relling's Oct 2 at 3:26 post implies that it does not by lack of reference to checksum property). So I don't know yet how much exposure will remain. I would think that if the user specified a stronger checksum for their data that the system would abandon its use of weaker ones in the underlying structure, but Richard's list seems to imply otherwise. (2) With destroying and recreating the zpool under U4 (Which I don't really have the resources to pull off) Due to some of the non-technical factors in the situation, I cannot actually execute an experimental valid zpool command, but "zpool create -o garbage" gives me a usage that does not include any -o or -O. So it appears that under U4 I cannot do this. I wish there were someone who could confirm that I can or cannot do this before I arrange for and propose that we dive into this massive undertaking. Also, from Richard's Oct 2 3:26 note, I infer that this will not change the checksum used by the underlying zpool anyway, so this might be fruitless. But I am infering... Richard gave a quick list, his attitude was not that of providing all level of precise detail so I really don't know. Many of the answers I have received have turned out to recommend features that are not available in U4 but in later versions, even unreleased versions. I have no way of sorting this out without the information being qualified with a version. (3) With upgrading to U7 (Perhaps in a few months) Not clear what this will support on zpool, or if it would be effective (similar to U4 above) (4) With upgrading to U8 Not sure when it will come out, what it will support, or if it will be effective (similar to U7, U4 above). So I can enable robust protection on my user data, but perhaps not the infrastructure needed to get at that user data, and perhaps not the intent log. The answer may be that I cannot be helped. That is not the desired answer, but if that is the case, so be it. Let's lay out the facts and the best way to move on from here, for me and everybody else. Why leave us thrashing in the dark? Am I a Mac user? I personally will still believe ZFS is the way to go in the short term because it is still a vastly better gamble, and in the long term because this too will pass as file systems are rebuilt. I would question why anything but the best would be used for the underlying zpool, any why there is absolutely zero presentation of the tradeoffs between the three algorithms in the admin guide, but that is another story. I know that someone out there, and probably people reading this thread know the answers to these questions. I hate to stop without that simple knowledge being communicated. I do greatly appreciate the attempts to work with me, I don't understand how I could be clearer. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
