Hi,
I just said zfs destroy pool/fs, but meant to say zfs destroy
pool/junk. Is ''fs'' really gone?
thx
jake
bdebelius at intelesyscorp.com
2009-Jan-28 22:11 UTC
[zfs-discuss] destroy means destroy, right?
Recovering Destroyed ZFS Storage Pools. You can use the zpool import -D command to recover a storage pool that has been destroyed. http://docs.sun.com/app/docs/doc/819-5461/gcfhw?a=view -- This message posted from opensolaris.org
On Wed, Jan 28, 2009 at 02:11:54PM -0800, bdebelius at intelesyscorp.com wrote:> Recovering Destroyed ZFS Storage Pools. > You can use the zpool import -D command to recover a storage pool that has been destroyed. > http://docs.sun.com/app/docs/doc/819-5461/gcfhw?a=viewBut the OP destroyed a dataset, not a pool. I don''t think there''s a way to undo dataset destruction.
I''m no authority, but I believe it''s gone. Some of the others on the list might have some funky thoughts, but I would suggest that if you have already done any other I/O''s to the disk that you have likely rolled past the point of no return. Anyone else care to comment? As a side note, I had a look for anything that looked like a CR for zfs destroy / undestroy and could not find one. Anyone interested in me submitting an RFE to have something like a zfs undestroy pool/fs capability? Clearly, there would be limitations in how long you would have to get the command to work, but it would have it''s merits... Cheers! Nathan. Jacob Ritorto wrote:> Hi, > I just said zfs destroy pool/fs, but meant to say zfs destroy > pool/junk. Is ''fs'' really gone? > > thx > jake > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss-- ////////////////////////////////////////////////////////////////// // Nathan Kroenert nathan.kroenert at sun.com // // Systems Engineer Phone: +61 3 9869-6255 // // Sun Microsystems Fax: +61 3 9869-6288 // // Level 7, 476 St. Kilda Road Mobile: 0419 305 456 // // Melbourne 3004 Victoria Australia // //////////////////////////////////////////////////////////////////
He''s not trying to recover a pool - Just a filesystem... :) bdebelius at intelesyscorp.com wrote:> Recovering Destroyed ZFS Storage Pools. > You can use the zpool import -D command to recover a storage pool that has been destroyed. > http://docs.sun.com/app/docs/doc/819-5461/gcfhw?a=view-- ////////////////////////////////////////////////////////////////// // Nathan Kroenert nathan.kroenert at sun.com // // Systems Engineer Phone: +61 3 9869-6255 // // Sun Microsystems Fax: +61 3 9869-6288 // // Level 7, 476 St. Kilda Road Mobile: 0419 305 456 // // Melbourne 3004 Victoria Australia // //////////////////////////////////////////////////////////////////
On Wed, Jan 28, 2009 at 5:18 PM, Nathan Kroenert <Nathan.Kroenert at sun.com> wrote:> As a side note, I had a look for anything that looked like a CR for zfs > destroy / undestroy and could not find one. > > Anyone interested in me submitting an RFE to have something like a > > zfs undestroy pool/fsHeh, this question came up a long long time ago regarding pools and I think the most succinct answer was "ZFS was designed to be easy, to err the other way would make it too hard." I think this problem would not need a fix if the admin realizes the magnitude of what he''s going to do and not just zip thru and hit [RETURN]. I mean, what would be the time window in which pool/fs could be preserved? 5 minutes? 24 hours? forever? OK, so everybody has fat-fingered something catastrophic. Take a good backup, and watch what you''re typing. Everybody respects rm -f *. CT
On Wed, 28 Jan 2009 20:16:37 -0500 Christine Tran <christine.tran at gmail.com> wrote:> Everybody respects rm -f *.+1 -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D + http://nagual.nl/ | SunOS sxce snv105 ++ + All that''s really worth doing is what we do for others (Lewis Carrol)
I hear that. Had it been a prod box, I''d have been a lot more paranoid and careful. This was a new vdev with a fresh zone installed on it, so I only lost a half hour of effort (whew). The seriousness of the zfs destroy command, though, really hit home during this process, and I wanted to find out if the command was really that serious, hence my original post. Could have been a really bad deal. zfs undestroy certainly would be a lifesaver for people who have to learn this the hard way. Maybe it could be implemented with an algorithm to the effect of ''keep a pointer somewhere to the old fs bits and don''t touch destroyed blocks until we run out of unused/virgin blocks, then go ahead and use them up without hesitation.'' Kind of a free block pool with priority. thx for your input, everyone. jake On Thu, Jan 29, 2009 at 11:43 AM, dick hoogendijk <dick at nagual.nl> wrote:> On Wed, 28 Jan 2009 20:16:37 -0500 > Christine Tran <christine.tran at gmail.com> wrote: > >> Everybody respects rm -f *. > +1 > > -- > Dick Hoogendijk -- PGP/GnuPG key: 01D2433D > + http://nagual.nl/ | SunOS sxce snv105 ++ > + All that''s really worth doing is what we do for others (Lewis Carrol) > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
Hello Jacob,
Thursday, January 29, 2009, 5:09:41 PM, you wrote:
JR> zfs undestroy certainly would be a lifesaver for people who have to
JR> learn this the hard way. Maybe it could be implemented with an
JR> algorithm to the effect of ''keep a pointer somewhere to the old
fs
JR> bits and don''t touch destroyed blocks until we run out of
JR> unused/virgin blocks, then go ahead and use them up without
JR> hesitation.'' Kind of a free block pool with priority.
I''m not saying it is a bad idea but it would cause data to be less
localized and more fragmented for many workloads...
--
Best regards,
Robert Milkowski mailto:milek at task.gda.pl
http://milek.blogspot.com
Maybe add a timer or something? When doing a "destroy", ZFS will keep everything for 1 minute or so, before overwriting. This way the disk won''t get as fragmented. And if you had fat fingers and typed wrong, you have up to one minute to undo. That will catch 80% of the mistakes? -- This message posted from opensolaris.org
I like that, although it''s a bit of an intelligence insulter. Reminds
me of the old pdp11 install (
http://charles.the-haleys.org/papers/setting_up_unix_V7.pdf ) --
This step makes an empty file system.
6. The next thing to do is to restore the data onto the new empty
file system. To do this you respond
to the '':'' printed in the last step with
(bring in the program restor)
: tm(0,4) (''ht(0,4)'' for TU16/TE16)
tape? tm(0,5) (use ''ht(0,5)'' for
TU16/TE16)
disk? rp(0,0) (use ''hp(0,0)''
for RP04/5/6)
Last chance before scribbling on disk. (you type return)
(the tape moves, perhaps 5-10 minutes pass)
end of tape
Boot
:
You now have a UNIX root file system.
On Thu, Jan 29, 2009 at 3:42 PM, Orvar Korvar
<knatte_fnatte_tjatte at yahoo.com> wrote:> Maybe add a timer or something? When doing a "destroy", ZFS will
keep everything for 1 minute or so, before overwriting. This way the disk
won''t get as fragmented. And if you had fat fingers and typed wrong,
you have up to one minute to undo. That will catch 80% of the mistakes?
For years, we resisted stopping rm -r / because people should know better, until *finally* someone said - you know what - that''s just dumb. Then, just like that, it was fixed. Yes - This is Unix. Yes - Provide the gun and allow the user to point it. Just don''t let it go off in their groin or when pointed at their foot, or provide at least some protection when they do. Having even limited amount of restore capability will provide the user with steel capped boots and a codpiece. It won''t protect them from herpes or fungus but it might deflect the bullet. On 01/30/09 08:19, Jacob Ritorto wrote:> I like that, although it''s a bit of an intelligence insulter. Reminds > me of the old pdp11 install ( > http://charles.the-haleys.org/papers/setting_up_unix_V7.pdf ) -- > > This step makes an empty file system. > 6. The next thing to do is to restore the data onto the new empty > file system. To do this you respond > to the '':'' printed in the last step with > (bring in the program restor) > : tm(0,4) (''ht(0,4)'' for TU16/TE16) > tape? tm(0,5) (use ''ht(0,5)'' for TU16/TE16) > disk? rp(0,0) (use ''hp(0,0)'' for RP04/5/6) > Last chance before scribbling on disk. (you type return) > (the tape moves, perhaps 5-10 minutes pass) > end of tape > Boot > : > You now have a UNIX root file system. > > > > > On Thu, Jan 29, 2009 at 3:42 PM, Orvar Korvar > <knatte_fnatte_tjatte at yahoo.com> wrote: >> Maybe add a timer or something? When doing a "destroy", ZFS will keep everything for 1 minute or so, before overwriting. This way the disk won''t get as fragmented. And if you had fat fingers and typed wrong, you have up to one minute to undo. That will catch 80% of the mistakes? > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss-- ////////////////////////////////////////////////////////////////// // Nathan Kroenert nathan.kroenert at sun.com // // Senior Systems Engineer Phone: +61 3 9869 6255 // // Global Systems Engineering Fax: +61 3 9869 6288 // // Level 7, 476 St. Kilda Road // // Melbourne 3004 Victoria Australia // //////////////////////////////////////////////////////////////////