Hi all,
A while back, I posted here about the issues ZFS has with USB hotplugging
of ZFS formatted media when we were trying to plan an external media backup
solution for time-slider:
http://www.opensolaris.org/jive/thread.jspa?messageID=299501
As well as the USB issues in the subject we became aware of some serious issues
with the ZFS send/recv stream format's backwards and forwards compatibility.
This was enough incentive to make us think about other potential solutions. One
of my colleagues in Xdesign (Frank Ludolph) came up with the suggestion of using
a ZFS mirror of the root pool as the mechanism to backup to an external device.
This seemed like a very nice idea. It made use of existing functionality that
already
exists in ZFS and works reliably, allows time-slider to expose yet another
great feature
of ZFS to the desktop/laptop user:
* It provides a full, reliable backup that is maintained in sync with the
main storage device
* No user interaction required. Just plug the disk in and pull it out when
you like. ZFS will
resynchronize it ASAP
* Provides a bootable backup mechanism. The mirror is bootable and the main
disk can be
fully replaced and/or recovered from it.
* Errors on the main disk can be corrected from the external device and vice
versa.
* Simplified UI - user doesn't have to configure backup schedules etc.
* Resynchronisation is always optimal because zfs handles it directly rather
than some
external program that can't optimise as effectively
* It would permit network backwork configurations if the mirror device were
an iSCSI target.
And the recent putback of:
PSARC/2008/427 iSCSI Boot
PSARC/2008/640 iSCSI With DHCP
should enable booting over the network
So I set off about testing this out and the initial results have been very
promising.
To configure the mirror I added a new device as described here:
http://darkstar-solaris.blogspot.com/2008/09/zfs-root-mirror.html
After a couple of weeks testing and trying to break the mirroring it has
continued to
work reliably despite leaving my USB mirror device detached for days on end,
adding
gigabytes of files and deleting hundreds of snapshots while detached. ZFS took
it
all in it's stride and resynced the mirror device when I reattached it. It also
withstood
my attempts to break it by disconnecting the USB mirror in the middle of a
resilver.
There are a few minor issues however which I'd love to get some feedback on in
addition
to the overall direction of this proposal:
1. When the external device is disconnected, the zpool status output reports
that the
pool is in a degraded state and displays a status message that indicates
that there
was an unrecoverable error. While this is all technically correct, and is
appropriate
in the context of a setup where it is assumed that the mirrored device is
always
connected, it might lead a user to be unnecessarily alarmed when his
"backup" mirror
disk is not connected. We're trying to use a mirror configuration here in a
manner that
is a bit different than the conventional manner, but not in any way that
it's not designed
to cope with.
2. When reattaching the external mirror device, hald and the removable media
manager try
to mount the mirror device and pop up an error message when it fails to
mount the pool.
This is an annoyance that needs a bug logged against hald I believe. ZFS
does the right thing
and starts resivering to bring the 2 mirror devices in sync.
3. The zpool status outut is not very good about estimating resilver completion
times. Resilvers
that were estimated to take 23 hours by zpool status have completed in 8
hours. At least it
wasn't the other way around :-)
So I'd like to ask if this is an appropriate use of ZFS mirror functionality?
It has many benefits
that we really should take advantage of. It would seem a real shame not to.
Secondly, i'd like
to address issue 1 above. There doesn't appear to be any fundamental,
underlying problem here.
It's just that the messages reported by zpool status might cause unnecessary
alarm to the user.
In the context that we plan to use a mirror there is nothing actually wrong
because we expect the
mirror device to get detached and reattached frequently which is not the normal
situation for a
mirror pool.
How about defining a new subtype of mirror device, such as a "backup-mirror" or
"removable-mirror"?
All the mirror functionality remains the same, but the status messages are a
bit less panicy when
the mirror device is disconnected since it's expected to happen frequently.
Time-slider is getting a lot of coverage and positive feedback from reviewers
and bloggers because it
allows ordinary users to take advantage of ZFS features in a very simple and
beneficial way. I
think this proposal presents another opportunity to bring the benefits of ZFS
to the desktop.
Remember that we're aiming at single user desktop and laptop type systems here,
nothing
huge and fancy :-)
Thanks,
Niall.
--
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
