zfs discuss - Nov 2005 - occasionally connected mirror component

How will ZFS cope with a mirror where one component is only connected
for (say) one hour each day?

I was wondering about a "backup" strategy that involved creating a
three way mirror where one of the elements is a removable device
(probably USB2 connected).  The removable device would be connected to
the system in question for some period each day to allow
synchronisation.

Would this work?

dme.
-- 
David Edmondson, Solaris Engineering, Sun Microsystems.

On Thu, 24 Nov 2005 David.Edmondson at Sun.COM wrote:
> How will ZFS cope with a mirror where one component is only connected
> for (say) one hour each day?
>
> I was wondering about a "backup" strategy that involved creating
a
> three way mirror where one of the elements is a removable device
> (probably USB2 connected).  The removable device would be connected to
> the system in question for some period each day to allow
> synchronisation.
>
> Would this work?
Snag a couple of disk drives and do it!
Let us know how well it works!

Al Hopper  Logical Approach Inc, Plano, TX.  al at logical-approach.com
           Voice: 972.379.2133 Fax: 972.379.2134  Timezone: US CDT
OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005

On Thu, Nov 24, 2005 at 02:53:09PM +0000, David.Edmondson at sun.com
wrote:
> How will ZFS cope with a mirror where one component is only connected
> for (say) one hour each day?
> 
> I was wondering about a "backup" strategy that involved creating
a
> three way mirror where one of the elements is a removable device
> (probably USB2 connected).  The removable device would be connected to
> the system in question for some period each day to allow
> synchronisation.
> 
> Would this work?
It should work just fine.  The best results would be achieved by doing
something like this:

    # ...
    # zpool offline mypool <external_device>
    # ... let a day go by ...
    # zpool online mypool <external_device>
    # ... wait for an hour, or until the resync is done ...
    # ... goto top

You can check on the resync status by using "zpool status -v".  There
will be a message up at the top letting you know how far the resync has
progressed, along with an estimated time for completion.

Using online/offline lets ZFS know that it''s the same disk and
we''ll
keep a DTL (dirty time log) for the device while it''s offline.  When
it''s put back online, we''ll only resync the data
that''s changed while
the device was gone.  It should be pretty snappy.

If you end up trying this out, I''d be really curious how long the
resync
takes.  We''ve tested a bunch of stuff like this, but real-world numbers
are always interesting.

If you find problems, please let us know so we can fix them.


--Bill

* bill.moore at sun.com [20051125T061512]:
> It should work just fine.  The best results would be achieved by doing
> something like this:
> 
>     # ...
>     # zpool offline mypool <external_device>
>     # ... let a day go by ...
>     # zpool online mypool <external_device>
>     # ... wait for an hour, or until the resync is done ...
>     # ... goto top
I''m playing with this a little, using two USB connected drives as the
components of a mirror.  It seems to work.

An irritation arises should I connect a device to a different USB
port, as it ends up with a different /dev/dsk name.  How do I persuade
ZFS that c4t0d0p1 is "the partition formerly known as c5t0d0p1"?

"zpool replace ..." didn''t seem right (and refused to do
anything,
claiming that the new name was busy).

Maybe this has something to do with the on-disk format for these
devices?  When creating the initial pool I tried using vdev names of
the form "c4t0d0", only to be told something about it not being
possible to install EFI labels and that I should use fdisk.

dme.
-- 
David Edmondson, Solaris Engineering, Sun Microsystems.

On Fri, Nov 25, 2005 at 06:09:49PM +0000, David.Edmondson at sun.com
wrote:
> 
> I''m playing with this a little, using two USB connected drives as
the
> components of a mirror.  It seems to work.
> 
> An irritation arises should I connect a device to a different USB
> port, as it ends up with a different /dev/dsk name.  How do I persuade
> ZFS that c4t0d0p1 is "the partition formerly known as c5t0d0p1"?
> 
> "zpool replace ..." didn''t seem right (and refused to do
anything,
> claiming that the new name was busy).
> 
> Maybe this has something to do with the on-disk format for these
> devices?  When creating the initial pool I tried using vdev names of
> the form "c4t0d0", only to be told something about it not being
> possible to install EFI labels and that I should use fdisk.
Hmmm, there definitely seems to be a bug here.  Each vdev is identified
by a (pool,vdev) GUID pair that is written to disk as part of the label.

In the future, we would like to subscribe to such hotplug events and
re-scan the new device to determine if it corresponds to an active pool.
Or just try to re-open by devid, as that has probably not changed.

Since that is a ways off, we should probabably have a way of replacing
the old device name with the new one.  What is currently happening is
that we are noticing that the (pool,vdev) pair is active in the system,
and therefore refuse to use the ''replacement'' disk.  If we are
able to
identify the device as such, and the original one is in the CANT_OPEN
state, then we should just update the config and re-open the device
under the new name.  Please file a bug.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

* eric.schrock at sun.com [20051126T192203]:
> Please file a bug.
6355687.  The workaround I''ve used (Bugster won''t let me enter
a
workaround - presumably until the bug is accepted) is to detach the
original device name and then attach the new name.  In the case of a
mirror this is somewhat okay, though it does cause the entire content
to be resilvered.

dme.
-- 
David Edmondson, Solaris Engineering, Sun Microsystems.