On Oct 3, 2009, at 7:46 AM, Ray Clark wrote:
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.
There is no such feature. There is a long-awaited RFE for block
pointer rewriting (checksums are stored in the block pointer)
which would add the underlying capabilities for this.
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.
Say for example I have a pool called zwimming with some stuff in it
and compression=on. To create a copy of the data using send/recv
in the same pool but with compression=sha256 do:
zfs snapshot zwimm...@now
zfs send zwimm...@now | zfs receive zwimming/new
You will now have a new file system called "zwimming/new" with
the same data as zwimming, but with compression=sha256.
If you then want to get back to the original directory structure
you can the mountpoint properties, as desired. There are dozens
of other ways to accomplish the copy.
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 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.
wrt the ZIL, it is rarely used for normal file system access. ZIL
blocks
are allocated from the pool as needed and freed no more than 30
seconds later, unless there is a sudden halt. If the system is halted
then the ZIL is used to roll forward transactions. The heads do not
"spend a disproportionate amount of time over the intent log."
-- richard
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
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
