your suggestion worked just fine -- I did the dd on the target disk, then was
able to do the 'zpool replace'.
requested files coming shortly (I'm attaching them after I've already
successfully run
'zpool replace', btw).
thanks
This message posted from opensolaris.org
Is there some benefit to me (err, the administrator) to maintaining the
parent/child relationship between a snap and its clone?
To my twisted little mind, by virtue of the fact that I created a clone
I have severed the relationship between a snap and a clone. They are
immediately at least one
Hey All,
So, just to get this idea out of my brain, and on to the screen, I've
got a prototype of a mechanism that takes automatic snapshots.
More info (and a tarball!) from my blog at
http://blogs.sun.com/roller/page/timf?entry=zfs_automatic_snapshots_prototype_1
cheers,
For example, today you can do:
# zfs snapshot data/[EMAIL PROTECTED]
# find .zfs/snapshot -name daily-* -ctime +7d
Does the actual snapshot creation time appear as one of the stat() times
of the snap directory? When I tried it, they all reflected the actual
times of the original
One question that has come up a number of times when I've been
speaking with people (read: evangelizing :) ) about ZFS is about
database storage. In conventional use storage has separated redo logs
from table space, on a spindle basis.
I'm not a database expert but I believe the reasons
I've seen this question asked in a number of forums but I haven't
seen an answer. (May just have not looked hard enough)
Copy-on-write means that most writes are sequential, which is good
for write performance, but won't it mean that random writes to a file
will put bits of the file
