Hello zfs-discuss,
I made simple changes so this is possible to import destroyed pool.
http://milek.blogspot.com/2006/02/zfs-recovering-destroyed-pools.html
However in vdev.c there''s a comment:
1188 /*
1189 * If we find a vdev with a matching pool guid and vdev
guid,
1190 * but the pool state is not active, it indicates that
the user
1191 * exported or destroyed the pool without affecting the
config
1192 * cache (if / was mounted readonly, for example). In
this
1193 * case, immediately return EBADF so the caller can
remove it
1194 * from the config.
1195 */
I''m not completly sure if I haven''t overlooked somthing
changing
here.
???
--
Best regards,
Robert mailto:rmilkowski at task.gda.pl
http://milek.blogspot.com
Yep, this is pretty much: 6276934 ability import destroyed pools I would rather see an option to zpool import, since it could potentially very confusing to have ''zpool import'' list all the destroyed pools. I was thinking of ''zpool import -D'' to display destroyed pools. Do other folks agree? If you want to submit it as a patch to request-sponsor I''m sure we can get it integrated. You handled the comment correctly. Basically, the idea behind it is that if you are in a state where /etc/zfs/zpool.cache isn''t writable, you can destroy a pool but the system will still "think" it exists. Hence we remove it from the cache. This is only important during open - for import you can let destroyed pools through. Thanks for looking into this, - Eric On Wed, Feb 01, 2006 at 05:17:57PM +0100, Robert Milkowski wrote:> Hello zfs-discuss, > > I made simple changes so this is possible to import destroyed pool. > > http://milek.blogspot.com/2006/02/zfs-recovering-destroyed-pools.html > > > However in vdev.c there''s a comment: > > 1188 /* > 1189 * If we find a vdev with a matching pool guid and vdev guid, > 1190 * but the pool state is not active, it indicates that the user > 1191 * exported or destroyed the pool without affecting the config > 1192 * cache (if / was mounted readonly, for example). In this > 1193 * case, immediately return EBADF so the caller can remove it > 1194 * from the config. > 1195 */ > > I''m not completly sure if I haven''t overlooked somthing changing > here. > > ??? > > > > -- > Best regards, > Robert mailto:rmilkowski at task.gda.pl > http://milek.blogspot.com > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss-- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
Hello Eric,
Wednesday, February 1, 2006, 7:00:37 PM, you wrote:
ES> Yep, this is pretty much:
ES> 6276934 ability import destroyed pools
ES> I would rather see an option to zpool import, since it could potentially
ES> very confusing to have ''zpool import'' list all the
destroyed pools. I
ES> was thinking of ''zpool import -D'' to display destroyed
pools. Do other
ES> folks agree? If you want to submit it as a patch to request-sponsor
I''m
ES> sure we can get it integrated.
You''re right - it would be better idea to add -D option.
Sure I want to get it integrated :)
Do I have to send separate email to request-sponsor list?
ES> You handled the comment correctly. Basically, the idea behind it is
ES> that if you are in a state where /etc/zfs/zpool.cache isn''t
writable,
ES> you can destroy a pool but the system will still "think" it
exists.
ES> Hence we remove it from the cache. This is only important during open -
ES> for import you can let destroyed pools through.
ES> Thanks for looking into this,
While I was driving home and after I sent this email I realized that
it depends on if there''s import or not and it should be ok that way I
did it. Anyway hanks for clarifying.
--
Best regards,
Robert mailto:rmilkowski at task.gda.pl
http://milek.blogspot.com
On Wed, 2006-02-01 at 18:00, Eric Schrock wrote:> Yep, this is pretty much: > > 6276934 ability import destroyed pools > > I would rather see an option to zpool import, since it could potentially > very confusing to have ''zpool import'' list all the destroyed pools. I > was thinking of ''zpool import -D'' to display destroyed pools. Do other > folks agree? If you want to submit it as a patch to request-sponsor I''m > sure we can get it integrated.Is it really necessary to add a new -D option ? I suspect the number of pools on most systems won''t be that huge and the number of destroyed pools should be even smaller. Particularly since zpool import without any other options doesn''t actually import anything, if it did then I''d say a -D option was necessary. -- Darren J Moffat
On Thu, Feb 02, 2006 at 09:05:53AM +0000, Darren J Moffat wrote:> > Is it really necessary to add a new -D option ? I suspect the > number of pools on most systems won''t be that huge and the number of > destroyed pools should be even smaller. > > Particularly since zpool import without any other options doesn''t > actually import anything, if it did then I''d say a -D option was > necessary.Personally, I find the idea of "zpool destroy" and then seeing the same pool with "zpool import" as rather counter-intuitive. Regardless of how many pools you have, wouldn''t it seem odd to see old destroyed pools, especially partial versions, by default? But I''m not set on this idea - no options would be fine if that''s what people found intuitive. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
On Wed, Feb 01, 2006 at 08:07:05PM +0100, Robert Milkowski wrote:> Hello Eric, > > Wednesday, February 1, 2006, 7:00:37 PM, you wrote: > > ES> Yep, this is pretty much: > > ES> 6276934 ability import destroyed pools > > ES> I would rather see an option to zpool import, since it could potentially > ES> very confusing to have ''zpool import'' list all the destroyed pools. I > ES> was thinking of ''zpool import -D'' to display destroyed pools. Do other > ES> folks agree? If you want to submit it as a patch to request-sponsor I''m > ES> sure we can get it integrated. > > You''re right - it would be better idea to add -D option. > > Sure I want to get it integrated :) > Do I have to send separate email to request-sponsor list?Yes, you should send a separate email to request-sponsor with a set of diffs. You''ll need a signed contributor agreement if this is your first submission: http://www.opensolaris.org/os/about/sun_contributor_agreement/ I''ll sponsor the fix if you send it ;-) Hopefully by then we will have come to some consensus about whether a "-D" option is necessary. One other thing that would be nice is for the export and destroy case to have some success message that tells the user how to get it back: # zpool export foo Pool ''foo'' exported. Use ''zpool import'' to recover. # zpool destroy foo Pool ''foo'' destroyed. Use ''zpool import -D'' to recover. This might help the admin who accidentally destroys a pool they didn''t intend to. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
Hello Eric, Thursday, February 2, 2006, 7:00:49 PM, you wrote: ES> On Wed, Feb 01, 2006 at 08:07:05PM +0100, Robert Milkowski wrote:>> Hello Eric, >> >> Wednesday, February 1, 2006, 7:00:37 PM, you wrote: >> >> ES> Yep, this is pretty much: >> >> ES> 6276934 ability import destroyed pools >> >> ES> I would rather see an option to zpool import, since it could potentially >> ES> very confusing to have ''zpool import'' list all the destroyed pools. I >> ES> was thinking of ''zpool import -D'' to display destroyed pools. Do other >> ES> folks agree? If you want to submit it as a patch to request-sponsor I''m >> ES> sure we can get it integrated. >> >> You''re right - it would be better idea to add -D option. >> >> Sure I want to get it integrated :) >> Do I have to send separate email to request-sponsor list?ES> Yes, you should send a separate email to request-sponsor with a set of ES> diffs. You''ll need a signed contributor agreement if this is your first ES> submission: ES> http://www.opensolaris.org/os/about/sun_contributor_agreement/ ok, done it. My # is OS0016 :) ES> I''ll sponsor the fix if you send it ;-) Hopefully by then we will have ES> come to some consensus about whether a "-D" option is necessary. One ES> other thing that would be nice is for the export and destroy case to ES> have some success message that tells the user how to get it back: ES> # zpool export foo ES> Pool ''foo'' exported. Use ''zpool import'' to recover. ES> # zpool destroy foo ES> Pool ''foo'' destroyed. Use ''zpool import -D'' to recover. ES> This might help the admin who accidentally destroys a pool they didn''t ES> intend to. After giving it some thought and after some tries I belive that adding -D option for destroyed pools is much better approach. For example: zpool create web mirror disk1 disk2 zpool destroy web zpool create web mirror disk3 disk4 zpool export web zpool import web And one would hit a problem here and would be forced to use numerical id. In SAN environments such cases could me more common and frankly really annoying. The same goes with ''zpool import -af'' etc. And when you''ve got more disks and were doing some tests with ZFS then normally you are not expecting to see all these tests pools. So I agree with Eric that adding -D option for destroyed pools is a much better solution. Additionally supporting -D with ''-a'' would be beneficial (import all destroyed pools). When importing destroyed pool I left -f as also obligatory - it''s more consistent what way I belive. I''ll send diffs to sponsor list. Below some examples. # zpool list no pools available # zpool import no pools available to import # zpool import -D pool: test-1 id: 3820947526729627800 state: ONLINE (DESTROYED) action: The pool can be imported using its name or numeric identifier. The pool was destroyed, but can be imported using the ''-Df'' flags. config: test-1 ONLINE c5t0d0s2 ONLINE pool: homes id: 8593280699763843451 state: ONLINE (DESTROYED) action: The pool can be imported using its name or numeric identifier. The pool was destroyed, but can be imported using the ''-Df'' flags. config: homes ONLINE mirror ONLINE c5t0d0s0 ONLINE c5t0d0s1 ONLINE # zpool import -Dfa # zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT homes 9.9G 5.41M 9.9G 0% ONLINE - test-1 1.98G 358K 1.98G 0% ONLINE - # zpool export homes # zpool destroy test-1 # zpool list no pools available # zpool import pool: homes id: 8593280699763843451 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: homes ONLINE mirror ONLINE c5t0d0s0 ONLINE c5t0d0s1 ONLINE # zpool import -D pool: test-1 id: 3820947526729627800 state: ONLINE (DESTROYED) action: The pool can be imported using its name or numeric identifier. The pool was destroyed, but can be imported using the ''-Df'' flags. config: test-1 ONLINE c5t0d0s2 ONLINE # zpool import -a # zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT homes 9.9G 5.45M 9.9G 0% ONLINE - # zpool import -Df test-1 # zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT homes 9.9G 5.45M 9.9G 0% ONLINE - test-1 1.98G 407K 1.98G 0% ONLINE - # -- Best regards, Robert mailto:rmilkowski at task.gda.pl https://milek.blogspot.com
Daft question, but with the new options being proposed here in mind, at what point once the pool has been destroyed would it not be possible to import it??? If one or more of the disks within the destroyed pool is re-used does that mean it would no longer be possible to import it??? This message posted from opensolaris.org
On Fri, Feb 17, 2006 at 07:51:32AM -0800, Phil Coleman wrote:> Daft question, but with the new options being proposed here in mind, > at what point once the pool has been destroyed would it not be > possible to import it??? If one or more of the disks within the > destroyed pool is re-used does that mean it would no longer be > possible to import it???It depends. If you have a replicated pool, you could completely scrog a single disk out of your raidz/mirror and be fine. In a non-replicated pool, your mileage may vary. With upcoming features (metadata replication, hardened error handling) you could end up with just corrupted user data, or you could have destroyed enough pool metadata such that the pool cannot be opened. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
Hello Eric, Friday, February 17, 2006, 5:02:36 PM, you wrote: ES> On Fri, Feb 17, 2006 at 07:51:32AM -0800, Phil Coleman wrote:>> Daft question, but with the new options being proposed here in mind, >> at what point once the pool has been destroyed would it not be >> possible to import it??? If one or more of the disks within the >> destroyed pool is re-used does that mean it would no longer be >> possible to import it???ES> It depends. If you have a replicated pool, you could completely scrog ES> a single disk out of your raidz/mirror and be fine. In a non-replicated ES> pool, your mileage may vary. With upcoming features (metadata ES> replication, hardened error handling) you could end up with just ES> corrupted user data, or you could have destroyed enough pool metadata ES> such that the pool cannot be opened. And it depends on how you reuse these disks. If for example you used slices s1 starting from the beginning of a disk, then destroyed that pool and created another one on s3 starting at some other cylinder, you will see both pools to import (one as destroyed with -D and one with normal import). Now if you try to import destroyed pool... well, without metadata replication you could probably even panic. If not it could still probably be dangerous with such overlaping slices as the old pool after import can possible overwrite some data of this new pool. So you should be careful what you are doing. IMHO we need something as ''zpool wipe ...'' which depending on option will destroy only zpool label (that way such a pool will not show up on import list even with -D option) or both zpool label and data (random bits? nulls?). -- Best regards, Robert mailto:rmilkowski at task.gda.pl http://milek.blogpsot.com