Re: Summary: [zfs-discuss] Poor man's backup by attaching/detaching mirror drives on a _striped_ pool?
Constantin Gonzalez wrote: - The supported alternative would be zfs snapshot, then zfs send/receive, but this introduces the complexity of snapshot management which makes it less simple, thus less appealing to the clone-addicted admin. ... IMHO, we should investigate if something like zpool clone would be useful. It could be implemented as a script that recursively snapshots the source pool, then zfs send/receives it to the destination pool, then copies all properties, but the actual reason why people do mirror splitting in the first place is because of its simplicity. A zpool clone or a zpool send/receive command would be even simpler and less error-prone than the tradition of splitting mirrors, plus it could be implemented more efficiently and more reliably than a script, thus bringing real additional value to administrators. I agree that this is the best solution. I am working on zfs send -r (RFE filed but id not handy), which will provide the features you describe above. --matt ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Summary: [zfs-discuss] Poor man's backup by attaching/detaching mirror drives on a _striped_ pool?
Hi, here's a quick summary of the answers I've seen so far: - Splitting mirrors is a current practice with traditional volume management. The goal is to quickly and effortlessly create a clone of a storage volume/pool. - Splitting mirrors with ZFS can be done, but it has to be done the hard way by resilvering, then unplugging the disk, then trying to import it somewhere else. zpool detach would render the detached disk unimportable. - Another, cleaner way of splitting a mirror would be to export the pool, then disconnect one drive, then re-import again. After that, the disconnected drive needs to be zpool detach'ed from the mother, while the clone can then be imported and its missing mirrors detached as well. But this involves unmounting the pool so it can't be done without downtime. - The supported alternative would be zfs snapshot, then zfs send/receive, but this introduces the complexity of snapshot management which makes it less simple, thus less appealing to the clone-addicted admin. - There's an RFE for supporting splitting mirrors: 5097228 http://bugs.opensolaris.org/view_bug.do?bug_id=5097228 IMHO, we should investigate if something like zpool clone would be useful. It could be implemented as a script that recursively snapshots the source pool, then zfs send/receives it to the destination pool, then copies all properties, but the actual reason why people do mirror splitting in the first place is because of its simplicity. A zpool clone or a zpool send/receive command would be even simpler and less error-prone than the tradition of splitting mirrors, plus it could be implemented more efficiently and more reliably than a script, thus bringing real additional value to administrators. Maybe zpool clone or zpool send/receive would be the better way of implementing 5097228 in the first place? Best regards, Constantin -- Constantin GonzalezSun Microsystems GmbH, Germany Platform Technology Group, Global Systems Engineering http://www.sun.de/ Tel.: +49 89/4 60 08-25 91 http://blogs.sun.com/constantin/ Sitz d. Ges.: Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering ___ zfs-discuss mailing list [EMAIL PROTECTED] http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Poor man's backup by attaching/detaching mirror drives on a _striped_ pool?
Hi Mark,
Mark J Musante wrote:
On Tue, 10 Apr 2007, Constantin Gonzalez wrote:
Has anybody tried it yet with a striped mirror? What if the pool is
composed out of two mirrors? Can I attach devices to both mirrors, let
them resilver, then detach them and import the pool from those?
You'd want to export them, not detach them. Detaching will overwrite the
vdev labels and make it un-importable.
thank you for the export/import idea, it does sound cleaner from a ZFS
perspective, but comes at the expense of temporarily unmounting the filesystems.
So, instead of detaching, would unplugging, then detaching work?
I'm thinking something like this:
- zpool create tank mirror dev1 dev2 dev3
- {physically move dev3 to new box}
- zpool detach tank dev3
On the new box:
- zpool import tank
- zpool detach tank dev1
- zpool detach tank dev2
This should work for one disk, and I assume this would also work for multiple
disks?
Thinking along similar lines, would it be a useful RFE to allow asynchronous
mirroring like this:
- dev1, dev2 are both 250GB, dev3 is 500GB
- zpool create tank mirror dev1,dev2 dev3
This means that half of dev3 would mirror dev1, the other half would mirror dev2
and dev1,dev2 is a regular stripe.
The utility of this would be for cases where customer have set up mirrors, then
need to replace disks or upgrade the mirror after a long time, when bigger disks
are easier to get than smaller ones and while reusing older disks.
Best regards,
Constantin
--
Constantin GonzalezSun Microsystems GmbH, Germany
Platform Technology Group, Global Systems Engineering http://www.sun.de/
Tel.: +49 89/4 60 08-25 91 http://blogs.sun.com/constantin/
Sitz d. Ges.: Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Poor man's backup by attaching/detaching mirror drives on a _striped_ pool?
On April 11, 2007 11:54:38 AM +0200 Constantin Gonzalez Schmitz
[EMAIL PROTECTED] wrote:
Hi Mark,
Mark J Musante wrote:
On Tue, 10 Apr 2007, Constantin Gonzalez wrote:
Has anybody tried it yet with a striped mirror? What if the pool is
composed out of two mirrors? Can I attach devices to both mirrors, let
them resilver, then detach them and import the pool from those?
You'd want to export them, not detach them. Detaching will overwrite the
vdev labels and make it un-importable.
thank you for the export/import idea, it does sound cleaner from a ZFS
perspective, but comes at the expense of temporarily unmounting the
filesystems.
So, instead of detaching, would unplugging, then detaching work?
I'm thinking something like this:
- zpool create tank mirror dev1 dev2 dev3
- {physically move dev3 to new box}
- zpool detach tank dev3
If we're talking about a 3rd device, added in order to migrate the data,
why not just zfs send | zfs recv?
-frank
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Poor man's backup by attaching/detaching mirror drives on a _striped_ pool?
Frank Cusack wrote:
On April 11, 2007 11:54:38 AM +0200 Constantin Gonzalez Schmitz
[EMAIL PROTECTED] wrote:
Hi Mark,
Mark J Musante wrote:
On Tue, 10 Apr 2007, Constantin Gonzalez wrote:
Has anybody tried it yet with a striped mirror? What if the pool is
composed out of two mirrors? Can I attach devices to both mirrors, let
them resilver, then detach them and import the pool from those?
You'd want to export them, not detach them. Detaching will
overwrite the
vdev labels and make it un-importable.
thank you for the export/import idea, it does sound cleaner from a ZFS
perspective, but comes at the expense of temporarily unmounting the
filesystems.
So, instead of detaching, would unplugging, then detaching work?
I'm thinking something like this:
- zpool create tank mirror dev1 dev2 dev3
- {physically move dev3 to new box}
- zpool detach tank dev3
If we're talking about a 3rd device, added in order to migrate the data,
why not just zfs send | zfs recv?
Time? The reason people go the split mirror route, at least in block
land, is because once you split the volume you can export it someplace
else and start using it. Same goes for constant replication where you
suspend the replication, take a copy, go start working on it, restart
the replication. (Lots of ways people do that one.)
I think the requirement could be voiced as, I want an independent copy
of my data on a secondary system in a quick fashion. I want to avoid
using resources from the primary system. The fun part is that people
will think in terms of current technologies so you'll see split
mirror, or volume copy or Truecopy mixed in for flavor.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Poor man's backup by attaching/detaching mirror drives on a _striped_ pool?
On Tue, 10 Apr 2007, Constantin Gonzalez wrote:
Has anybody tried it yet with a striped mirror? What if the pool is
composed out of two mirrors? Can I attach devices to both mirrors, let
them resilver, then detach them and import the pool from those?
You'd want to export them, not detach them. Detaching will overwrite the
vdev labels and make it un-importable.
Off the top of my head (i.e. untested):
- zpool create tank mirror dev1 dev2 dev3
- zpool export tank
- {physically move dev3 to new box}
- zpool import tank
- zpool detach tank dev3
On the new box:
- zpool import tank
- zpool detach tank dev1
- zpool detach tank dev2
Regards,
markm
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
