zfs discuss - Nov 2005 - Recovery from stupidity possible?

Hello ZFS''ers...

Firstly, I am incredibly proud to be part of the ZFS community. Jeff B and
everyone have made an outstanding contribution to filesystem technology.

Well in my keenness, having just installed b27, I dived in with both feet, and
created a ZFS pool. zpool duly warned me that I would have to use the -f option
to overwrite an existing filesystem; which I did. And on it went... Then I
realised that I had suffered finger-trouble in my haste, and splatted all over a
working filesystem :-( I destroyed the pool, and attempted to remount the biffed
filesystem. The directory structure survived, but the inodes of the files were
indeed blatted.

I tried fsck, but that left me with a whole pile of zip.

Thank the lord I archived the files to CD, otherwise the wife would have toasted
me. Phew!

Any thoughts? I am sure that someone will do this without having backups sooner
or later.....

Thanks... Sean.
This message posted from opensolaris.org

> Well in my keenness, having just installed b27, I dived in with both feet,
> and created a ZFS pool. zpool duly warned me that I would have to use the
> -f option to overwrite an existing filesystem; which I did. And on it
> went...
So - what else do you think we could do but tell you "if you insist on
shooting yourself in the (-f)oot, you can ..." ?
> Then I realised that I had suffered finger-trouble in my haste, and
> splatted all over a working filesystem :-( I destroyed the pool, and
> attempted to remount the biffed filesystem. The directory structure
> survived, but the inodes of the files were indeed blatted.
> 
> I tried fsck, but that left me with a whole pile of zip.
> 
> Thank the lord I archived the files to CD, otherwise the wife would have 
toasted me. Phew!
> 
> Any thoughts? I am sure that someone will do this without having backups 
> sooner or later.....
Not even Solaris 10 protects you from that. Recent Solaris Express
(OpenSolaris build 25+ if I remember right) got device-in-use checking
(libdiskmgt) that implements these checks.
That''s why the ZFS utils tell you "only if you give the
''-f''...".

But since there are legitimate reasons why an admin may want to force
"overwrite", it''s still allowed - if you insist ...

Again, as said - what else *could* we do, outright of denying the
admin his/her god-given right to mess with the system in whatever
way seen fit ? Not document ''-f'' ?

FrankH.
> 
> Thanks... Sean.
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/zfs-discuss

Frank! Thanks for the reply (I think ;-) )
>>Well in my keenness, having just installed b27, I dived in with both
feet,
>>and created a ZFS pool. zpool duly warned me that I would have to use
the
>>-f option to overwrite an existing filesystem; which I did. And on it
>>went...
> 
> 
> So - what else do you think we could do but tell you "if you insist on
> shooting yourself in the (-f)oot, you can ..." ?
And you end up rightfully (-f)*cked, I know... ;-)
> Not even Solaris 10 protects you from that. Recent Solaris Express
> (OpenSolaris build 25+ if I remember right) got device-in-use checking
> (libdiskmgt) that implements these checks.
> That''s why the ZFS utils tell you "only if you give the
''-f''...".
Good to know. Thanks.
> But since there are legitimate reasons why an admin may want to force
> "overwrite", it''s still allowed - if you insist ...
> 
> Again, as said - what else *could* we do, outright of denying the
> admin his/her god-given right to mess with the system in whatever
> way seen fit ? Not document ''-f'' ?
All I was looking for was the vaguest possibility of a way 
"back" - not trying to mitigate the foulup whatsoever. After 
all, it was caused by enthusiasm running away with my 
fingers.....

Thanks and regards... Sean.

> Frank! Thanks for the reply (I think ;-) )
I might have overshot a bit, sorry ...
> 
> >>Well in my keenness, having just installed b27, I dived in with
both feet,
> >>and created a ZFS pool. zpool duly warned me that I would have to
use the
> >>-f option to overwrite an existing filesystem; which I did. And on
it
> >>went...
> > 
> > 
> > So - what else do you think we could do but tell you "if you
insist on
> > shooting yourself in the (-f)oot, you can ..." ?
> 
> And you end up rightfully (-f)*cked, I know... ;-)
> 
> > Not even Solaris 10 protects you from that. Recent Solaris Express
> > (OpenSolaris build 25+ if I remember right) got device-in-use checking
> > (libdiskmgt) that implements these checks.
> > That''s why the ZFS utils tell you "only if you give the
''-f''...".
> 
> Good to know. Thanks.
I mean, the fact that recently, the disk management utilities (whether
mkfs, newfs, metainit, format, zfs/zpool, ...) warn if a device is in
use by someone else and tell you "not unless you -f(orce) me" is new.

Try "newfs"-ing a subdisk of a mirrored mounted root filesystem.

In S10 and below, you''ll just be let go ahead without even being told
that you''re about to shoot yourself. The recent OpenSolaris builds do
stop you - unless you decide to use ''-f''.

Maybe we should change the utilities so that they don''t
"suggest" the
use of ''-f'' ? I mean, you''re right that if someone
tells me "you can''t
but if you do ''-f'' you suddenly can ...", it''s
suggestive ...
> 
> > But since there are legitimate reasons why an admin may want to force
> > "overwrite", it''s still allowed - if you insist ...
> > 
> > Again, as said - what else *could* we do, outright of denying the
> > admin his/her god-given right to mess with the system in whatever
> > way seen fit ? Not document ''-f'' ?
> 
> All I was looking for was the vaguest possibility of a way 
> "back" - not trying to mitigate the foulup whatsoever. After 
> all, it was caused by enthusiasm running away with my 
> fingers.....
You''re welcome. We''ve learned something about the power of
suggestive
messages, I guess.

FrankH.
> 
> Thanks and regards... Sean.
>

Frank Hofmann - Solaris Sustaining wrote:
>>Well in my keenness, having just installed b27, I dived in with both
feet,
>>and created a ZFS pool. zpool duly warned me that I would have to use
the
>>-f option to overwrite an existing filesystem; which I did. And on it
>>went...
>>    
>>
>
>So - what else do you think we could do but tell you "if you insist on
>shooting yourself in the (-f)oot, you can ..." ?
>
>  
>
>>Then I realised that I had suffered finger-trouble in my haste, and
>>splatted all over a working filesystem :-( I destroyed the pool, and
>>attempted to remount the biffed filesystem. The directory structure
>>survived, but the inodes of the files were indeed blatted.
>>
>>I tried fsck, but that left me with a whole pile of zip.
>>
>>Thank the lord I archived the files to CD, otherwise the wife would have
>>    
>>
>toasted me. Phew!
>  
>
>>Any thoughts? I am sure that someone will do this without having backups
>>sooner or later.....
>>    
>>
>
>Not even Solaris 10 protects you from that. Recent Solaris Express
>(OpenSolaris build 25+ if I remember right) got device-in-use checking
>(libdiskmgt) that implements these checks.
>That''s why the ZFS utils tell you "only if you give the
''-f''...".
>
>But since there are legitimate reasons why an admin may want to force
>"overwrite", it''s still allowed - if you insist ...
>
>Again, as said - what else *could* we do, outright of denying the
>admin his/her god-given right to mess with the system in whatever
>way seen fit ? Not document ''-f'' ?
>  
>
Is there any way that a sample of the top-level dirs 
about-to-be-destroyed could be displayed?

Bill Ross
>FrankH.
>
>  
>
>>Thanks... Sean.
>>This message posted from opensolaris.org
>>_______________________________________________
>>zfs-discuss mailing list
>>zfs-discuss at opensolaris.org
>>http://opensolaris.org/mailman/listinfo/zfs-discuss
>>    
>>
>
>_______________________________________________
>zfs-discuss mailing list
>zfs-discuss at opensolaris.org
>http://opensolaris.org/mailman/listinfo/zfs-discuss
>  
>

Hi All,

A few comments/clarifications about the device in use checking inline...
>
>>
>>    
>>
>>>> > Not even Solaris 10 protects you from that. Recent Solaris
Express
>>>> > (OpenSolaris build 25+ if I remember right) got
device-in-use checking
>>>> > (libdiskmgt) that implements these checks.
>>>> > That''s why the ZFS utils tell you "only if
you give the ''-f''...".
>>>      
>>>
>>> 
>>> Good to know. Thanks.
>>    
>>
This was introduced withe ZFS in build 27.
>
>I mean, the fact that recently, the disk management utilities (whether
>mkfs, newfs, metainit, format, zfs/zpool, ...) warn if a device is in
>use by someone else and tell you "not unless you -f(orce) me" is
new.
>
>Try "newfs"-ing a subdisk of a mirrored mounted root filesystem.
>
>In S10 and below, you''ll just be let go ahead without even being
told
>that you''re about to shoot yourself. The recent OpenSolaris builds
do
>stop you - unless you decide to use ''-f''.
>
>Maybe we should change the utilities so that they don''t
"suggest" the
>use of ''-f'' ? I mean, you''re right that if
someone tells me "you can''t
>but if you do ''-f'' you suddenly can ...",
it''s suggestive ...
>
>  
>
The utilities that were modified to include the device in use checking 
in build 27 are:

newfs
mkfs
dumpadm
swap
format

There is actually no -f for these utilities. ZFS is the only one that 
currently lets you force the use of a device that is found to be in use. 
As Frank mentions, the use of -f can be suggestive so we opted not to 
include it for the first release of this feature, and actually no real 
decision has been made on whether -f is appropriate for these 
utilities.  When you use these utilities now, it will succeed or fail, 
and will force the user to ''fix'' the in use state prior to
proceeding,
should they choose to do so.

thanks,
sarah
*****
>>> 
>>    
>>
>>>> > But since there are legitimate reasons why an admin may
want to force
>>>> > "overwrite", it''s still allowed - if
you insist ...
>>>> > 
>>>> > Again, as said - what else *could* we do, outright of
denying the
>>>> > admin his/her god-given right to mess with the system in
whatever
>>>> > way seen fit ? Not document ''-f'' ?
>>>      
>>>
>>> 
>>> All I was looking for was the vaguest possibility of a way 
>>> "back" - not trying to mitigate the foulup whatsoever.
After
>>> all, it was caused by enthusiasm running away with my 
>>> fingers.....
>>    
>>
>
>You''re welcome. We''ve learned something about the power of
suggestive
>messages, I guess.
>
>FrankH.
>
>  
>
>>> 
>>> Thanks and regards... Sean.
>>> 
>>    
>>
>
>_______________________________________________
>zfs-discuss mailing list
>zfs-discuss at opensolaris.org
>http://opensolaris.org/mailman/listinfo/zfs-discuss
>  
>

On Thu, Nov 17, 2005 at 08:29:49AM -0800, Sean Sprague
wrote:
> Well in my keenness, having just installed b27, I dived in with both
> feet, and created a ZFS pool. zpool duly warned me that I would have
> to use the -f option to overwrite an existing filesystem; which I did.
> And on it went... Then I realised that I had suffered finger-trouble
> in my haste, and splatted all over a working filesystem :-( I
> destroyed the pool, and attempted to remount the biffed filesystem.
> The directory structure survived, but the inodes of the files were
> indeed blatted.
As others have mentioned, you get what you ask for... :)

But one point worth mentioning is that if the filesystem you destroyed
had been mounted at the time, we would have denied the operation, even
with the -f flag given.  It is a principle of Unix to allow
administrators to do things that might not be safe, but overwriting a
mounted filesystem will simply cause the machine to panic (eventually),
and that is never OK.


--Bill

On Thu, Nov 17, 2005 at 09:34:00AM -0800, Bill Ross
wrote:
> >Again, as said - what else *could* we do, outright of denying the
> >admin his/her god-given right to mess with the system in whatever
> >way seen fit ? Not document ''-f'' ?
> >
> Is there any way that a sample of the top-level dirs 
> about-to-be-destroyed could be displayed?
Not without implementing a user-land filesystem reader inside the "zpool
create" command (or in a library) for every possible filesystem type
that we detect as part of our device-in-use checking.

Like I said earlier, if the filesystem is mounted, you don''t get to use
that disk, no matter how many -f flags you give us.  If it''s not
mounted, then it''s up to you not to give the -f flag unless you know
you
want it destroyed.


--Bill

Bill Moore wrote:
>On Thu, Nov 17, 2005 at 09:34:00AM -0800, Bill Ross wrote:
>  
>
>>>Again, as said - what else *could* we do, outright of denying the
>>>admin his/her god-given right to mess with the system in whatever
>>>way seen fit ? Not document ''-f'' ?
>>>
>>>      
>>>
>>Is there any way that a sample of the top-level dirs 
>>about-to-be-destroyed could be displayed?
>>    
>>
>
>Not without implementing a user-land filesystem reader inside the
"zpool
>create" command (or in a library) for every possible filesystem type
>that we detect as part of our device-in-use checking.
>  
>
I think it would have to be added to filesystems in general as part of a 
broader effort. Zpool might lead by example, by defining an interface 
for other fs''s to query to get such info.
>Like I said earlier, if the filesystem is mounted, you don''t get to
use
>that disk, no matter how many -f flags you give us.  If it''s not
>mounted, then it''s up to you not to give the -f flag unless you
know you
>want it destroyed.
>
>
>--Bill
>  
>

On Thu, Nov 17, 2005 at 12:53:30PM -0800, Bill Ross
wrote:
> I think it would have to be added to filesystems in general as part of a 
> broader effort. Zpool might lead by example, by defining an interface 
> for other fs''s to query to get such info.
This would be a rather large effort.  What significant problem are we
trying to solve?  We already tell you the filesystem is in use.  Do
you think that by showing some filenames (what if the root directory has
200K entries?), that it would improve usability?  I seriously doubt it.


--Bill

Bill Moore wrote:
>On Thu, Nov 17, 2005 at 12:53:30PM -0800, Bill Ross wrote:
>  
>
>>I think it would have to be added to filesystems in general as part of a
>>broader effort. Zpool might lead by example, by defining an interface 
>>for other fs''s to query to get such info.
>>    
>>
>
>This would be a rather large effort.  What significant problem are we
>trying to solve?  We already tell you the filesystem is in use.  Do
>you think that by showing some filenames (what if the root directory has
>200K entries?), that it would improve usability?  I seriously doubt it.
>  
>
Sorry, I meant for filesystems not in use. It would probably be a lot of 
effort for a marginal case, so I''m not advocating that it makes sense 
for Sun to spend money on it. There would have to be an arbitrary 
selection. Another version would be to allow a comment at creation time, 
which would be embedded in every disk in the filesystem.

Bill
>
>--Bill
>  
>

Hmm - one could ask "would you like to back up the file system first?"
Bev.

Sean Sprague wrote:
> Frank! Thanks for the reply (I think ;-) )
> 
>>> Well in my keenness, having just installed b27, I dived in with
both
>>> feet,
>>> and created a ZFS pool. zpool duly warned me that I would have to
use
>>> the
>>> -f option to overwrite an existing filesystem; which I did. And on
it
>>> went...
>>
>>
>>
>> So - what else do you think we could do but tell you "if you
insist on
>> shooting yourself in the (-f)oot, you can ..." ?
> 
> 
> And you end up rightfully (-f)*cked, I know... ;-)
> 
>> Not even Solaris 10 protects you from that. Recent Solaris Express
>> (OpenSolaris build 25+ if I remember right) got device-in-use checking
>> (libdiskmgt) that implements these checks.
>> That''s why the ZFS utils tell you "only if you give the
''-f''...".
> 
> 
> Good to know. Thanks.
> 
>> But since there are legitimate reasons why an admin may want to force
>> "overwrite", it''s still allowed - if you insist ...
>>
>> Again, as said - what else *could* we do, outright of denying the
>> admin his/her god-given right to mess with the system in whatever
>> way seen fit ? Not document ''-f'' ?
> 
> 
> All I was looking for was the vaguest possibility of a way "back"
- not
> trying to mitigate the foulup whatsoever. After all, it was caused by 
> enthusiasm running away with my fingers.....
> 
> Thanks and regards... Sean.
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/zfs-discuss

Bev Crair wrote:
> Hmm - one could ask "would you like to back up the file system
first?"
But the rational expectation after answering Y to such a question woulf 
be for it to perform tha backup.

alan.
-- 
Alan Hargreaves - http://blogs.sun.com/tpenta
Staff Engineer (Kernel/VOSJEC/Performance)
Product Technical Support (APAC)
Sun Microsystems

yes, and....

Alan Hargreaves wrote:
> Bev Crair wrote:
> 
>> Hmm - one could ask "would you like to back up the file system
first?"
> 
> 
> But the rational expectation after answering Y to such a question woulf 
> be for it to perform tha backup.
> 
> alan.

On Thu 17 Nov 2005 at 04:49PM, Bev Crair wrote:
> yes, and....
I think the point is that if it says, "there seems to be something
here"
and that something happens to be some section of a RAID volume from
another OS, or a foobarfs filesystem, Solaris can''t know what it is,
and can''t back it up.

        -dp

-- 
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp

> Hmm - one could ask "would you like to back up the file system
first?"
> Bev.
The devil''s advocate within me asks:

	"Do you want to convert it to ZFS ?"

Heck, if even Windows can do that :)

FrankH.
> 
> Sean Sprague wrote:
> > Frank! Thanks for the reply (I think ;-) )
> > 
> >>> Well in my keenness, having just installed b27, I dived in
with both
> >>> feet,
> >>> and created a ZFS pool. zpool duly warned me that I would have
to use
> >>> the
> >>> -f option to overwrite an existing filesystem; which I did.
And on it
> >>> went...
> >>
> >>
> >>
> >> So - what else do you think we could do but tell you "if you
insist on
> >> shooting yourself in the (-f)oot, you can ..." ?
> > 
> > 
> > And you end up rightfully (-f)*cked, I know... ;-)
> > 
> >> Not even Solaris 10 protects you from that. Recent Solaris Express
> >> (OpenSolaris build 25+ if I remember right) got device-in-use
checking
> >> (libdiskmgt) that implements these checks.
> >> That''s why the ZFS utils tell you "only if you give
the ''-f''...".
> > 
> > 
> > Good to know. Thanks.
> > 
> >> But since there are legitimate reasons why an admin may want to
force
> >> "overwrite", it''s still allowed - if you insist
...
> >>
> >> Again, as said - what else *could* we do, outright of denying the
> >> admin his/her god-given right to mess with the system in whatever
> >> way seen fit ? Not document ''-f'' ?
> > 
> > 
> > All I was looking for was the vaguest possibility of a way
"back" - not
> > trying to mitigate the foulup whatsoever. After all, it was caused by 
> > enthusiasm running away with my fingers.....
> > 
> > Thanks and regards... Sean.
> > 
> > _______________________________________________
> > zfs-discuss mailing list
> > zfs-discuss at opensolaris.org
> > http://opensolaris.org/mailman/listinfo/zfs-discuss
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/zfs-discuss

> On Thu, Nov 17, 2005 at 08:29:49AM -0800, Sean
> Sprague wrote:
> > Well in my keenness, having just installed b27, I
> dived in with both
> > feet, and created a ZFS pool. zpool duly warned me
> that I would have
> > to use the -f option to overwrite an existing
> filesystem; which I did.
> > And on it went... Then I realised that I had
> suffered finger-trouble
> > in my haste, and splatted all over a working
> filesystem :-( I
> > destroyed the pool, and attempted to remount the
> biffed filesystem.
> > The directory structure survived, but the inodes of
> the files were
> > indeed blatted.
> 
> As others have mentioned, you get what you ask for...
> :)
> 
> But one point worth mentioning is that if the
> filesystem you destroyed
> had been mounted at the time, we would have denied
> the operation, even
> with the -f flag given.  It is a principle of Unix to
> allow
> administrators to do things that might not be safe,
> but overwriting a
> mounted filesystem will simply cause the machine to
> panic (eventually),
> and that is never OK.
I notice that "destroy" with both zpool and zfs will happily oblige
without a confirmation even if filesystems are mounted.
This message posted from opensolaris.org

On Fri, Nov 18, 2005 at 05:32:31AM -0800, Keith Chan
wrote:
> I notice that "destroy" with both zpool and zfs will happily
oblige
> without a confirmation even if filesystems are mounted.
That''s right.  Just like "rm" will remove a file, even if an
application
has it open.  The goal is to honor the requests of the administrator.
Unlike "rm", it''s hard to imagine how "zfs destroy
<something>" just slips
off your fingers by accident.  And if we make you type "-f" for every
operation, why bother having "-f" at all?  If you have a better
suggestion for the way things should work, please let us know.


--Bill

On Fri, Nov 18, 2005 at 09:27:03AM -0800, Bill Moore
wrote:
> 
> That''s right.  Just like "rm" will remove a file, even
if an application
> has it open.  The goal is to honor the requests of the administrator.
> Unlike "rm", it''s hard to imagine how "zfs destroy
<something>" just slips
> off your fingers by accident.  And if we make you type "-f" for
every
> operation, why bother having "-f" at all?  If you have a better
> suggestion for the way things should work, please let us know.
> 
It''s also important to note that ''zfs destroy'' (or
''zpool destroy'') will
not unmount a filesystem that''s _in use_ (i.e. an application has a
file
open).  You must specify the ''-f'' flag to do a force unmount.

Also, for ''zpool destroy'', we are planning to have an option
to ''zpool
import'' to import destroyed pools (it''s really just a bit
flipped on the
devices).  That way, if you really type it by accident, you can recover
by running ''zpool import''.

- Eric

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

> On Fri, Nov 18, 2005 at 05:32:31AM -0800, Keith Chan
> wrote:
> > I notice that "destroy" with both zpool and zfs
> will happily oblige
> > without a confirmation even if filesystems are
> mounted.
> 
> That''s right.  Just like "rm" will remove a file,
> even if an application
> has it open.  The goal is to honor the requests of
> the administrator.
> Unlike "rm", it''s hard to imagine how "zfs destroy
> <something>" just slips
> off your fingers by accident.  And if we make you
> type "-f" for every
> operation, why bother having "-f" at all?  If you
> have a better
> suggestion for the way things should work, please let
> us know.
Isn''t that why rm is quite often aliased to rm -i?

It just seems the potential for damage with the "destroy" commands
seems much greater but maybe a confirm with how much data was about to be
destroyed?

In an ideal world, we would never type the wrong things but this is a thread
about stupidity after all :)
This message posted from opensolaris.org

Bill Moore wrote:
>On Fri, Nov 18, 2005 at 05:32:31AM -0800, Keith Chan wrote:
>  
>
>>I notice that "destroy" with both zpool and zfs will happily
oblige
>>without a confirmation even if filesystems are mounted.
>>    
>>
>
>That''s right.  Just like "rm" will remove a file, even if
an application
>has it open.  The goal is to honor the requests of the administrator.
>Unlike "rm", it''s hard to imagine how "zfs destroy
<something>" just slips
>off your fingers by accident.  
>
The wrong argument might - something21 vs. something12.

Bill Ross

On Fri, 2005-11-18 at 18:02, Keith Chan wrote:
> Isn''t that why rm is quite often aliased to rm -i?
Which is a complete and utter waste of time.

It doesn''t help if you hit the delete key in a GUI,
It doesn''t help with redirection over the file from the CLI.
It doesn''t help if some other application calls unlink(2).
> It just seems the potential for damage with the "destroy"
commands seems much greater but maybe a confirm with how much data was about to
be destroyed?
Which is exactly why as others have pointed out several times
there are several layers of protection here.  Unlike rm zfs destroy is
pretty hard type accidentally.  Whats more the word "destroy" should
give you a hint much stronger than "delete" - they don''t have
the same
meaning.
> In an ideal world, we would never type the wrong things but this is a
thread about stupidity after all :)
Intelligent people only make stupid mistakes like that once, the others
find jobs else where (often in management for some reason :-)).


-- 
Darren J Moffat

On Mon, 21 Nov 2005, Darren J Moffat wrote:
> On Fri, 2005-11-18 at 18:02, Keith Chan wrote:
> > Isn''t that why rm is quite often aliased to rm -i?
>
> Which is a complete and utter waste of time.
>
> It doesn''t help if you hit the delete key in a GUI,
> It doesn''t help with redirection over the file from the CLI.
> It doesn''t help if some other application calls unlink(2).
>
> > It just seems the potential for damage with the "destroy"
commands seems much greater but maybe a confirm with how much data was about to
be destroyed?
>
> Which is exactly why as others have pointed out several times
> there are several layers of protection here.  Unlike rm zfs destroy is
> pretty hard type accidentally.  Whats more the word "destroy"
should
> give you a hint much stronger than "delete" - they don''t
have the same
> meaning.
>
> > In an ideal world, we would never type the wrong things but this is a
thread about stupidity after all :)
>
> Intelligent people only make stupid mistakes like that once, the others
> find jobs else where (often in management for some reason :-)).
Actually we''ve got a policy that covers that: You''re allowed 2
mistakes per
calendar year.  And look ... its November and I''ve still got one
mistake
left!  :)

And if you believe that one .. I''ve got a used bridge to sell you...

Regards,

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

> > It just seems the potential for damage with the
> "destroy" commands seems much greater but maybe a
> confirm with how much data was about to be destroyed?
> 
> Which is exactly why as others have pointed out
> several times
> there are several layers of protection here.  Unlike
> rm zfs destroy is
> pretty hard type accidentally.  Whats more the word
> "destroy" should
> give you a hint much stronger than "delete" - they
> don''t have the same
> meaning.
You might not type "zfs destroy" accidentally, but the arguments are
different matter - a miscommunicated message from colleague, a misguided
cut-and-paste in an xterm, etc..

I would prefer to see something like:

# zfs destroy tank
Do you really mean to destroy 23.4 ZB of data (yes/No)?

Anyway, I promise not to keep banging on about this.  I''m sure a
wrapper will get written which one day may prevent an unsuspecting sysadmin from
falling on their own sword.
This message posted from opensolaris.org

On Mon, Nov 21, 2005 at 05:50:48AM -0800, Keith Chan
wrote:
> > > It just seems the potential for damage with the
> > "destroy" commands seems much greater but maybe a
> > confirm with how much data was about to be destroyed?
> > 
> > Which is exactly why as others have pointed out
> > several times
> > there are several layers of protection here.  Unlike
> > rm zfs destroy is
> > pretty hard type accidentally.  Whats more the word
> > "destroy" should
> > give you a hint much stronger than "delete" - they
> > don''t have the same
> > meaning.
That argument can be flipped around:  do we really need to optimize the
"I want to destroy all my data" path?  Why _not_ ask for confirmation,
adding a "force" option to override?  ("zfs destroy -f"
definitely says
"I know what I''m doing; get the hell out of my way.") 
Personally, I was a
little shocked when I ran "zpool destroy" for the first time and it
simply
(silently, unquestioningly) nuked my data.  At the risk of an
extraordinarily insensitive analogy, it felt a little like saying "what
a crappy day; I feel like blowing my brains out" -- and having someone
suddenly oblige by blowing your brains out.
> You might not type "zfs destroy" accidentally, but the arguments
are different matter - a miscommunicated message from colleague, a misguided
cut-and-paste in an xterm, etc..
> 
> I would prefer to see something like:
> 
> # zfs destroy tank
> Do you really mean to destroy 23.4 ZB of data (yes/No)?
This is a great message.  Again, if this kind of message rankles, a
force option should be added to override it...

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

On 11/21/05, Keith Chan <keith_chan at msn.com>
wrote:
>
>
> You might not type "zfs destroy" accidentally, but the arguments
are
> different matter - a miscommunicated message from colleague, a misguided
> cut-and-paste in an xterm, etc..
>
>
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20051121/2caa827a/attachment.html>

On Mon, Nov 21, 2005 at 09:53:52AM -0800, Bryan Cantrill
wrote:
> 
> On Mon, Nov 21, 2005 at 05:50:48AM -0800, Keith Chan wrote:
> > > > It just seems the potential for damage with the
> > > "destroy" commands seems much greater but maybe a
> > > confirm with how much data was about to be destroyed?
> > > 
> > > Which is exactly why as others have pointed out
> > > several times
> > > there are several layers of protection here.  Unlike
> > > rm zfs destroy is
> > > pretty hard type accidentally.  Whats more the word
> > > "destroy" should
> > > give you a hint much stronger than "delete" - they
> > > don''t have the same
> > > meaning.
> 
> That argument can be flipped around:  do we really need to optimize the
> "I want to destroy all my data" path?  Why _not_ ask for
confirmation,
> adding a "force" option to override?  ("zfs destroy -f"
definitely says
> "I know what I''m doing; get the hell out of my way.") 
Personally, I was a
> little shocked when I ran "zpool destroy" for the first time and
it simply
> (silently, unquestioningly) nuked my data.  At the risk of an
> extraordinarily insensitive analogy, it felt a little like saying
"what
> a crappy day; I feel like blowing my brains out" -- and having someone
> suddenly oblige by blowing your brains out.
What if you could immediately undo the action, by way of "zpool
import",
without losing any data?

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development

> > That argument can be flipped around:  do we really need to optimize
the
> > "I want to destroy all my data" path?  Why _not_ ask for
confirmation,
> > adding a "force" option to override?  ("zfs destroy
-f" definitely says
> > "I know what I''m doing; get the hell out of my
way.")  Personally, I was a
> > little shocked when I ran "zpool destroy" for the first time
and it simply
> > (silently, unquestioningly) nuked my data.  At the risk of an
> > extraordinarily insensitive analogy, it felt a little like saying
"what
> > a crappy day; I feel like blowing my brains out" -- and having
someone
> > suddenly oblige by blowing your brains out.
> 
> What if you could immediately undo the action, by way of "zpool
import",
> without losing any data?
Fine, but then the message needs to be something like:

  # zpool destroy foo
  zpool: destroyed ''foo''; "zpool import foo" to
undestroy.
  #

Also, does there need to be a way to nuke the data such that it can''t
be undone?  "zpool nuke foo"?

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

On Mon, Nov 21, 2005 at 03:52:11PM -0800, Bryan Cantrill
wrote:
> 
> Fine, but then the message needs to be something like:
> 
>   # zpool destroy foo
>   zpool: destroyed ''foo''; "zpool import foo" to
undestroy.
>   #
Yes, this will be covered.
> Also, does there need to be a way to nuke the data such that it
can''t
> be undone?  "zpool nuke foo"?
Does this need to be something separate from secure deletion?  We
already plan to support this in the future.  A hybrid solution
(accomplished by either completely scrogging the label or recursively
destroying all the datasets) would make it un-importable, but still
leave the majority of your data intact (albeit difficult to parse).

- Eric

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

>
>> > That argument can be flipped around:  do we really need to
optimize the
>> > "I want to destroy all my data" path?  Why _not_ ask for
confirmation,
>> > adding a "force" option to override?  ("zfs destroy
-f" definitely says
>> > "I know what I''m doing; get the hell out of my
way.")  Personally, I was a
>> > little shocked when I ran "zpool destroy" for the first
time and it simply
>> > (silently, unquestioningly) nuked my data.  At the risk of an
>> > extraordinarily insensitive analogy, it felt a little like saying
"what
>> > a crappy day; I feel like blowing my brains out" -- and
having someone
>> > suddenly oblige by blowing your brains out.
>> 
>> What if you could immediately undo the action, by way of "zpool
import",
>> without losing any data?
>
>Fine, but then the message needs to be something like:
>
>  # zpool destroy foo
>  zpool: destroyed ''foo''; "zpool import foo" to
undestroy.
>  #
>
>Also, does there need to be a way to nuke the data such that it
can''t
>be undone?  "zpool nuke foo"?
Surely you mean "zpool nuke -f foo"? :-)

You''d need to scrub the disks yourself, for now.  With encryption,
it''s just a matter of destroying key material.

Casper

On Mon, Nov 21, 2005 at 04:00:57PM -0800, Eric Schrock
wrote:
> On Mon, Nov 21, 2005 at 03:52:11PM -0800, Bryan Cantrill wrote:
> > 
> > Fine, but then the message needs to be something like:
> > 
> >   # zpool destroy foo
> >   zpool: destroyed ''foo''; "zpool import
foo" to undestroy.
> >   #
> 
> Yes, this will be covered.
> 
> > Also, does there need to be a way to nuke the data such that it
can''t
> > be undone?  "zpool nuke foo"?
> 
> Does this need to be something separate from secure deletion?  We
> already plan to support this in the future.  A hybrid solution
> (accomplished by either completely scrogging the label or recursively
> destroying all the datasets) would make it un-importable, but still
> leave the majority of your data intact (albeit difficult to parse).
So what''s to prevent this same thread from cropping up once we fix
"zpool destroy" to be like Bryan suggested, and make "zpool
nuke"
permanently destroy your data?

Our original like of thinking was that, as others have mentioned, it is
hard to type "zfs destroy" by mistake.  When doing scripting (where
destroying snapshots would be a common thing to do), we don''t want the
command to go interactive.  And forcing the use of "-f" when scripting
is not really polite, either (if you always require "-f", why bother
having the option at all?).

As with many arguments, this boils down to a question of taste.  I
personally love it the way it is now.  My fingers and brain have been
trained by 15 years of doing sysadmin work to always be *extremely*
careful about what I type when I''m about to destroy something -- you
don''t get to be an experienced sysadmin without this, you get fired
instead.  I really don''t like tools that get in my way.  I agree with
Darren here.  I don''t see how a message like "You''re
about to destroy
XXXGB of data" will help.  Presumably, if I mis-type the name of a
filesystem, chances are still good that it will contain about the same
amount of data, so the message does nothing.

Any administrator that feels uncomfortable with this level of
destructive ability at their fingertips should probably go through the
GUI, where an "are you sure?" type of message would be far more
appropriate.

That said, it would be nice to support an "undo" sort of
functionality.
For pools, this is relatively easy, and I think we''ve said before that
this is planned.  For filesystems, not so much.  Presumably, you''re
deleting a filesystem because you want the space back.  If you don''t
need the space, why not keep it around?  If you do need the space, then
we can''t really hang on to it wondering if the user will want to undo.

It''s a crappy problem.  I don''t see how asking "are you
sure?" helps
anything - it just gets the user used to typing "zfs destroy
oog/bla^My^M".
If you have a filesystem you consider "precious", consider making a
snapshot early in its life (so it won''t pin much disk space).  Then,
"zfs destroy" won''t let you do the destroy since the
filesystem has
children.  If this seems useful enough to folks, we might even consider
adding a "nodestroy" property, which you would have to remove by hand
before being able to destroy a filesystem.

To sum things up, I haven''t seen a compelling argument for making
"zfs destroy" interactive.  I don''t see a way, technically,
to make it
undo-albe.  And for "zpool destroy", we plan on adding the undo
feature.


--Bill

On Tue, 22 Nov 2005, Bill Moore wrote:
> On Mon, Nov 21, 2005 at 04:00:57PM -0800, Eric Schrock wrote:
> > On Mon, Nov 21, 2005 at 03:52:11PM -0800, Bryan Cantrill wrote:
> > >
> > > Fine, but then the message needs to be something like:
> > >
> > >   # zpool destroy foo
> > >   zpool: destroyed ''foo''; "zpool import
foo" to undestroy.
> > >   #
> >
> > Yes, this will be covered.
> >
> > > Also, does there need to be a way to nuke the data such that it
can''t
> > > be undone?  "zpool nuke foo"?
> >
> > Does this need to be something separate from secure deletion?  We
> > already plan to support this in the future.  A hybrid solution
> > (accomplished by either completely scrogging the label or recursively
> > destroying all the datasets) would make it un-importable, but still
> > leave the majority of your data intact (albeit difficult to parse).
>
> So what''s to prevent this same thread from cropping up once we fix
> "zpool destroy" to be like Bryan suggested, and make "zpool
nuke"
> permanently destroy your data?
>
> Our original like of thinking was that, as others have mentioned, it is
> hard to type "zfs destroy" by mistake.  When doing scripting
(where
> destroying snapshots would be a common thing to do), we don''t want
the
> command to go interactive.  And forcing the use of "-f" when
scripting
> is not really polite, either (if you always require "-f", why
bother
> having the option at all?).
>
> As with many arguments, this boils down to a question of taste.  I
> personally love it the way it is now.  My fingers and brain have been
> trained by 15 years of doing sysadmin work to always be *extremely*
> careful about what I type when I''m about to destroy something --
you
> don''t get to be an experienced sysadmin without this, you get
fired
> instead.  I really don''t like tools that get in my way.  I agree
with
> Darren here.  I don''t see how a message like "You''re
about to destroy
> XXXGB of data" will help.  Presumably, if I mis-type the name of a
> filesystem, chances are still good that it will contain about the same
> amount of data, so the message does nothing.
>
> Any administrator that feels uncomfortable with this level of
> destructive ability at their fingertips should probably go through the
> GUI, where an "are you sure?" type of message would be far more
> appropriate.
>
> That said, it would be nice to support an "undo" sort of
functionality.
> For pools, this is relatively easy, and I think we''ve said before
that
> this is planned.  For filesystems, not so much.  Presumably,
you''re
> deleting a filesystem because you want the space back.  If you
don''t
> need the space, why not keep it around?  If you do need the space, then
> we can''t really hang on to it wondering if the user will want to
undo.
>
> It''s a crappy problem.  I don''t see how asking "are
you sure?" helps
> anything - it just gets the user used to typing "zfs destroy
oog/bla^My^M".
> If you have a filesystem you consider "precious", consider making
a
> snapshot early in its life (so it won''t pin much disk space). 
Then,
> "zfs destroy" won''t let you do the destroy since the
filesystem has
> children.  If this seems useful enough to folks, we might even consider
> adding a "nodestroy" property, which you would have to remove by
hand
> before being able to destroy a filesystem.
+1 for the property.

Perhaps you could allow the user to specify it at create time, since the
''='' char is not valid in a filesystem or volume name:

zfs create mpool/charlie nodestroy=on

Whoops.  I may have opened a can of worms here.  Because if you can say
''nodestroy=on'', then you should also be able to say
compression=on on the
same command line (comma separated).  But you don''t support setting
multiple properties with a single ''zfs set'' command.

Comment on the CLI: I really like the way zfs does what you tell it to.
Immediately and quickly - while hiding all the details whenever possible.
A default "do you really blah..." would really get in the way and
spoil the
current "flavor" of the (excellent) CLI.
> To sum things up, I haven''t seen a compelling argument for making
> "zfs destroy" interactive.  I don''t see a way,
technically, to make it
> undo-albe.  And for "zpool destroy", we plan on adding the undo
feature.
>
>
> --Bill
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

Bill Moore wrote:
>So what''s to prevent this same thread from cropping up once we fix
>"zpool destroy" to be like Bryan suggested, and make "zpool
nuke"
>permanently destroy your data?
>  
>
My take is that "zfs nuke" would still have the same confirmation 
process, however it would delete the data in an unrecoverable way. Maybe 
"nuke zero" "nuke secure" type options for how
you''d liek the data
nuked. Or perhaps the originator of the nuke request meant something 
entirely different.

--barry

Bill Moore wrote:
> 
> Our original like of thinking was that, as others have mentioned, it is
> hard to type "zfs destroy" by mistake.  When doing scripting
(where
> destroying snapshots would be a common thing to do), we don''t want
the
> command to go interactive.  And forcing the use of "-f" when
scripting
> is not really polite, either (if you always require "-f", why
bother
> having the option at all?).
> 
For my taste and level of paranoia I would like to be able to do:

zfs destroy -t snapshot pool/home at spam

that way if I where to hit return before typing the @spam zfs destroy 
could say "hey  pool/home is not a snapshot" and then not delete my
file
system.

Of course one way to protect yourself from you self is to always have a 
snapshot around. That way to delete the real filesystem requires the -r 
option.


-- 
Chris Gerhard.                               __o __o __o
PTS in Europe                               _`\<,`\<,`\<,_
Sun Microsystems Limited                   (*)/---/---/ (*)
Phone: +44 (0) 1252 426033 (ext 26033)
-----------------------------------------------------------
http://blogs.sun.com/chrisg
-----------------------------------------------------------
NOTICE: This email message is for the sole use of the
intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited.
If you are not the intended recipient, please contact
the sender by reply email and destroy all copies of the
original message.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3186 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20051123/4f5673df/attachment.bin>

Bill Moore wrote:
>[...]
> 
> It''s a crappy problem.  I don''t see how asking "are
you sure?" helps
> anything - it just gets the user used to typing "zfs destroy
oog/bla^My^M".
Requiring a confirmation that''s as easy to type as this is indeed
self-defeating. It''s a similar situation with rm on those systems (any
Linux?) that add -i for you... and if you don''t take up the habit of
making it explicit again by always typing -i yourself on those systems (even
without its designated function of letting the user see the results of wildcard
expansion so that he can make individual decisions during the enumeration), thus
avoiding to train yourself to expect a chance to reconsider, you''re
setting yourself up for a nasty surprise on a Unix that assumes you do know what
you''re doing.
>[...]
> If this seems useful enough to folks, we might even consider
> adding a "nodestroy" property, which you would have to remove by
hand
> before being able to destroy a filesystem.
Guess how many will have it set? :-)
>[...]
Here''s a tip for anyone concerned about accidentally destroying
anything valuable... The problem recurs often, as when doing a SQL delete, and
the details may look different, but there''s one common solution: type
your arguments first, verify them, and then go back and type the command.
It''s not a foolproof method (you have to know when any kind of deleting
is involved, and maybe examine the target first), but I see no shame in doing
this to protect myself against accidents, and I think it should be suggested in
the documentation. For extra safety, you can even examine the target, go one
step up in the shell''s history, and change only the command.

No nanny in my command shell (I''ll be my own, thank you)! Anyone
who''s not sure about a command and doesn''t expect to use it
often should be using a GUI anyway (they''re great for avoiding wasting
time RTFM''ing!), or be appropriately careful, especially using powerful
privileges.
This message posted from opensolaris.org