Is the ZFS copies property retroactive?

[Eric Sproul]

Hi,
I've been searching for the answer to this question but can't find a definitive
answer. If I set "copies=2" on a dataset after I've written some files, will
those older files get multiple copies after a scrub operation?

The main reason I ask is that I'd like to set multiple copies on my root
filesystems, which generally get installed via Jumpstart. Jumpstart has no
provision for setting ZFS properties when it creates pools, so things like
compression just aren't useful yet. However, for systems where there is only
one physical drive for the OS, being able to activate multiple copies of user
data in a finish script would be really nice. Then I could just kick off a
scrub before the server goes into production, and be assured that my root
dataset has ditto blocks throughout.

If that is indeed the case and I can start using ditto blocks, the next question
becomes, "what happens when I use Live Upgrade?" Will the "copies=2" property
be preserved during the snapshot/clone process?

Thanks,
Eric

[Eric Sproul]

Post by Eric Sproul
Hi,
I've been searching for the answer to this question but can't find a definitive
answer. If I set "copies=2" on a dataset after I've written some files, will
those older files get multiple copies after a scrub operation?

Doh, RTFM. In zfs(1M): "Changing this property only affects newly-written
data." Sorry for the noise.

Eric

[Nicolas Williams]

Post by Eric Sproul

Post by Eric Sproul
Hi,
I've been searching for the answer to this question but can't find a definitive
answer. If I set "copies=2" on a dataset after I've written some files, will
those older files get multiple copies after a scrub operation?

Doh, RTFM. In zfs(1M): "Changing this property only affects newly-written
data." Sorry for the noise.

It's possible, I suppose, that when the block pointer rewrite feature is
complete then you'll be able to kick off a rewrite of your pool that
causes some of these options (e.g., compression) to be applied to old
data. Matt Ahrens wrote about the block rewrite feature in his blog:

http://blogs.sun.com/ahrens/entry/new_scrub_code

I could a bright future for block pointer rewrite.

[Eric Sproul]

Post by Nicolas Williams
It's possible, I suppose, that when the block pointer rewrite feature is
complete then you'll be able to kick off a rewrite of your pool that
causes some of these options (e.g., compression) to be applied to old
http://blogs.sun.com/ahrens/entry/new_scrub_code
I could a bright future for block pointer rewrite.

Oh wow, I hadn't thought of that connection. I'd read that post when it came
out, but now I see what you mean. This could be very exciting if it turns out
to be true (applying new settings to old data).

Thanks!
Eric

[Nicolas Williams]

Post by Eric Sproul

Post by Nicolas Williams
It's possible, I suppose, that when the block pointer rewrite feature is
complete then you'll be able to kick off a rewrite of your pool that
causes some of these options (e.g., compression) to be applied to old
http://blogs.sun.com/ahrens/entry/new_scrub_code
I could a bright future for block pointer rewrite.

Oh wow, I hadn't thought of that connection. I'd read that post when it came
out, but now I see what you mean. This could be very exciting if it turns out
to be true (applying new settings to old data).

Yes, the possibilities are great. Clearly better scrubbing (done) and
vdev evacuation (from Matt's post I'd say it's in progress) are big
ones. There's also: ZFS crypto re-key, application of some property
changes to old blocks (e.g., compression, but recordsize would probably
be tougher).

Nico
--