Hello, with the advent of clones and snapshots, one will of course start creating them. Which also means destroying them. Am I the only one who is *extremely* nervous about doing "zfs destroy some/path at whenever"? This goes bot manually and automatically in a script. I am very paranoid about this; especially because the @ sign might conceivably be incorrectly interpreted by some layer of scripting, being a non-alphanumeric character and highly atypical for filenames/paths. What about having dedicated commands "destroysnapshot", "destroyclone", or "remove" (less dangerous variant of "destroy") that will never do anything but remove snapshots or clones? Alternatively having something along the lines of "zfs destroy --nofs" or "zfs destroy --safe". I realize this is borderline being in the same territory as special casing "rm -rf /" and similar, which is generally not considered a good idea. But somehow the snapshot situation feels a lot more risky. -- / Peter Schuller PGP userID: 0xE9758B7D or ''Peter Schuller <peter.schuller at infidyne.com>'' Key retrieval: Send an E-Mail to getpgpkey at scode.org E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070518/407f0ac2/attachment.bin>
> What about having dedicated commands "destroysnapshot", "destroyclone", > or "remove" (less dangerous variant of "destroy") that will never do > anything but remove snapshots or clones? Alternatively having something > along the lines of "zfs destroy --nofs" or "zfs destroy --safe".Another option is to allow something along the lines of: zfs destroy snapshot:/path/to/fs at snaptime Where the use of "snapshot:" would guarantee that non-snapshots are not affected. -- / Peter Schuller PGP userID: 0xE9758B7D or ''Peter Schuller <peter.schuller at infidyne.com>'' Key retrieval: Send an E-Mail to getpgpkey at scode.org E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070518/8bf85a9b/attachment.bin>
> with the advent of clones and snapshots, one will of course start > creating them. Which also means destroying them. > > Am I the only one who is *extremely* nervous about doing "zfs destroy > some/path at whenever"? > > This goes bot manually and automatically in a script. I am very paranoid > about this; especially because the @ sign might conceivably be > incorrectly interpreted by some layer of scripting, being a > non-alphanumeric character and highly atypical for filenames/paths. > > What about having dedicated commands "destroysnapshot", "destroyclone", > or "remove" (less dangerous variant of "destroy") that will never do > anything but remove snapshots or clones? Alternatively having something > along the lines of "zfs destroy --nofs" or "zfs destroy --safe".Apparently (and I''m not sure where this is documented), you can ''rmdir'' a snapshot to remove it (in some cases). A normal (populated) directory wouldn''t be removable with a single rmdir, so in some sense it''s safer. Personally, I would prefer that file operations (like mv and rmdir) couldn''t affect snapshots.> I realize this is borderline being in the same territory as special > casing "rm -rf /" and similar, which is generally not considered a good > idea. > > But somehow the snapshot situation feels a lot more risky.Agreed. I''m somewhat used to the VxVM command set which requires the type of object be passed in in some cases (even though the name is necessarily unique and would be enough to define the object). vxassist -g <diskgroup> remove volume <volumename> vxassist -g <diskgroup> remove mirror <mirrorname> It doesn''t feel unnatural to me to specify things this way. -- Darren Dunham ddunham at taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >
Rather than rehash this, again, from scratch. Refer to a previous rehashing. http://www.opensolaris.org/jive/thread.jspa?messageID=15363& -- richard Peter Schuller wrote:> Hello, > > with the advent of clones and snapshots, one will of course start > creating them. Which also means destroying them. > > Am I the only one who is *extremely* nervous about doing "zfs destroy > some/path at whenever"? > > This goes bot manually and automatically in a script. I am very paranoid > about this; especially because the @ sign might conceivably be > incorrectly interpreted by some layer of scripting, being a > non-alphanumeric character and highly atypical for filenames/paths. > > What about having dedicated commands "destroysnapshot", "destroyclone", > or "remove" (less dangerous variant of "destroy") that will never do > anything but remove snapshots or clones? Alternatively having something > along the lines of "zfs destroy --nofs" or "zfs destroy --safe". > > I realize this is borderline being in the same territory as special > casing "rm -rf /" and similar, which is generally not considered a good > idea. > > But somehow the snapshot situation feels a lot more risky. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> Rather than rehash this, again, from scratch. Refer to a previous rehashing. > http://www.opensolaris.org/jive/thread.jspa?messageID=15363&That thread really did quickly move to arguments about confirmations and their usefulness or annoyance. I think the idea presented of adding something like a filter is slightly different. It wouldn''t require confirmation or modification of the existing behavior (and it wouldn''t be relevant to the original issue in that other thread). destroy <obj> # destroys any existing <obj> if possible destroy snapshot <obj> # destroys <obj> only if it is a snapshot -- Darren Dunham ddunham at taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >
Hey, that''s nothing, I had one zfs file system, then I cloned it, so I thought that I had two separate file systems. then I was making snaps of both of them. Then later on I decided I did not need original file system with its snaps. So I did recursively remove it, all of a sudden I got a message that this clone file system is mounted and cannot be removed, my heart did stop for a second as that clone was a file system that I was using. I suspect that I did not promote zfs file system to be completely stand alone so ehh, I did not have idea that was the case... but it did scare me how easy I could just loose file system by removing wrong thing. Chris
Peter Schuller wrote:> Hello, > > with the advent of clones and snapshots, one will of course start > creating them. Which also means destroying them. > > Am I the only one who is *extremely* nervous about doing "zfs destroy > some/path at whenever"? > > This goes bot manually and automatically in a script. I am very paranoid > about this; especially because the @ sign might conceivably be > incorrectly interpreted by some layer of scripting, being a > non-alphanumeric character and highly atypical for filenames/paths. > > What about having dedicated commands "destroysnapshot", "destroyclone", > or "remove" (less dangerous variant of "destroy") that will never do > anything but remove snapshots or clones? Alternatively having something > along the lines of "zfs destroy --nofs" or "zfs destroy --safe". > > I realize this is borderline being in the same territory as special > casing "rm -rf /" and similar, which is generally not considered a good > idea. > > But somehow the snapshot situation feels a lot more risky. >This isn''t the first time this subject has come up. You are definitely NOT alone. The problem is only compounded when doing recursive actions. The general request has been for a confirmation "Are you sure?" which could be over-ridden with a -f. The general response is "if run from a script everyone will use -f and defeat the purpose". The suggestions you''ve come up with above are very good ones. I think the addition of "destroysnap" or "destroyclone" are particularly good because they could be added without conflicting with or changing the existing interfaces. benr.
> Rather than rehash this, again, from scratch. Refer to a previous > rehashing. > http://www.opensolaris.org/jive/thread.jspa?messageID=15363&I agree that adding a -f requirement and/or an interactive prompt is not a good solution. As has already been pointed out, my suggestion is different. "zfs destroy" is very general. Often, generality is good (e.g. in programming languages). But when dealing with something this dangerous and by it''s very nature likely to be used on live production data either manually or in scripts (that are not subject to a release engineering process), I think it is useful to make it possible to be more specific, such that the possible repercussions of a misstake are limited. As an analogy - would you want "rm" to automatically do "rm -rf" if invoked on a directory? Most probably would not. The general solution would be for "rm" to just do what you tell it to - remove whatever you are pointing it to. But I think most would agree that things are safer the way they work now. However that said I am not suggesting removing existing functionality of "destroy", but to provide a way be more specific about your intended actions in cases where you want to destroy snapshots or clones. -- / Peter Schuller PGP userID: 0xE9758B7D or ''Peter Schuller <peter.schuller at infidyne.com>'' Key retrieval: Send an E-Mail to getpgpkey at scode.org E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070519/c49c9e73/attachment.bin>
> Apparently (and I''m not sure where this is documented), you can ''rmdir'' > a snapshot to remove it (in some cases).Ok. That would be useful, though I also don''t like that it breaks standard rmdir semantics. In any case it does not work in my case - but that was on FreeBSD. -- / Peter Schuller PGP userID: 0xE9758B7D or ''Peter Schuller <peter.schuller at infidyne.com>'' Key retrieval: Send an E-Mail to getpgpkey at scode.org E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070519/b16a7149/attachment.bin>
You are not alone. My preference would be for an optional -t option to zfs destroy: zfs destroy -t snapshot tank/fs at one or zfs destroy -t snapshot -r tank/fs would delete all the snapshots below tank/fs This message posted from opensolaris.org
ZFS can make for complicated environments. Your dog wants management tools. :) Seriously - We''re adding all of these options to ZFS. Where are the tools that let someone make an informed decision concerning what their actions are going to do to the system? Where is the option that lets someone see what actions would occur without actually doing it? (Like "gmake -n") Does the GUI show me a relationship between all of my filesystems, clones, and snapshots? (I''m going to admit I haven''t looked at the GUI for a while so if its there forgive me.)
Chris Gerhard wrote:> You are not alone. > > My preference would be for an optional -t option to zfs destroy: > > zfs destroy -t snapshot tank/fs at one > > or > > zfs destroy -t snapshot -r tank/fs > > would delete all the snapshots below tank/fsI agree since that would fit nicely with the existing CLI model. This is much nicer than the proposal of separate destroy verbs for each object type. It is is important to use this style because otherwise we restrict new object types and needlessly complicate the cli over time. On the other hand personally I just don''t see the need for this since the @ char isn''t special to the shell so I don''t see where the original problem came from. One thing that might help here, when not running as root or as a user with "ZFS File System Management" RBAC profile, is user delegation. This will allow you to run the script as user that can only do certain operations to filesystems that they own or have been delegated specific access to operate on. -- Darren J Moffat
> > On the other hand personally I just don''t see the > need for this since > the @ char isn''t special to the shell so I don''t see > where the original > problem came from.It is the combination of the fear of doing something bad and the the consequence of doing that something bad that make people worry about this. Especially when writing scripts. I would much prefer to do for snap in $(zfs list -t snapshot -r foo/bar ) do zfs destroy -t snapshot $snap do the not have the -t. Especially the further away the destroy is from the generation of the list. The extra -t would be belt and braces but that is how I like my data protected. Yes you can add that in using a shell function: zfs_destroy_snapshot { zfs destroy ${1%%@*}@${1##*@} } but that is more hassle than a nice admin model should require from the nervous user. On the same basis that we don''t need the -t option to destroy we don''t really need a separate snapshot sub command. It would be implied by: zfs create tank/demo at snapshot Yet this is not allowed and we have to have a special command to create a snapshot but a generic one to destroy it. --chris This message posted from opensolaris.org
> On the other hand personally I just don''t see the need for this since > the @ char isn''t special to the shell so I don''t see where the original > problem came from.I never actually *had* a problem, I am just nervous about it. And yes, @ is not special for classical shells, but it''s still more special than alphanumerics or ''/'', and probably more likely to *be* special in some languages/alternate shells. Then there is the seemingly trivial issue of the physical keyboard layout. The most common layout will tend to make you use the right shift key in order to type the @, in a particular sequence such that a slight slip of the finger there and *kaboom*, you have lost your (and/or everybody else''s) data by accidentally hitting enter instead of shift. One can of course protect against this by writing commands backwards and such, which is what I do for cases like this along with SQL DELETE statements, but to me it just feels unnecessarily dangerous.> One thing that might help here, when not running as root or as a user > with "ZFS File System Management" RBAC profile, is user delegation. This > will allow you to run the script as user that can only do certain > operations to filesystems that they own or have been delegated specific > access to operate on.On the other than a very minor modification to the command line tool gets you a pretty significant payoff without complicating things. It will affect the safety of the out-of-the-box tool, regardless of the local policy for privilege delegation. -- / Peter Schuller PGP userID: 0xE9758B7D or ''Peter Schuller <peter.schuller at infidyne.com>'' Key retrieval: Send an E-Mail to getpgpkey at scode.org E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070521/3a4a2e49/attachment.bin>
> I would much prefer to do > > for snap in $(zfs list -t snapshot -r foo/bar ) > do > zfs destroy -t snapshot $snap > do > > the not have the -t. Especially the further away the destroy is from the generation of the list. The extra -t would be belt and braces but that is how I like my data protected.Especially if we imagine that someone further down the line decides to slightly modify the format of the "zfs list -t snapshot" output - such as by having it give a hierarchal view with the roots being the filesystem path... This is of course a normal problem with shell scripting (unless the zfs command is documented to guarantee backward compatible output?), but in cases like this it really really becomes critical. -- / Peter Schuller PGP userID: 0xE9758B7D or ''Peter Schuller <peter.schuller at infidyne.com>'' Key retrieval: Send an E-Mail to getpgpkey at scode.org E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070521/3eb2b9b0/attachment.bin>
Actually, if your zfs filesystem has snapshots zfs will complain that the fs can''t be destroyed (or that you have to use the -f switch to force it). So the first thing I do when making a new filesystem is create a snapshot to protect me from destroying a filesystem :) On 5/21/07, Peter Schuller <peter.schuller at infidyne.com> wrote:> > > On the other hand personally I just don''t see the need for this since > > the @ char isn''t special to the shell so I don''t see where the original > > problem came from. > > I never actually *had* a problem, I am just nervous about it. And yes, @ > is not special for classical shells, but it''s still more special than > alphanumerics or ''/'', and probably more likely to *be* special in some > languages/alternate shells. > > Then there is the seemingly trivial issue of the physical keyboard > layout. The most common layout will tend to make you use the right shift > key in order to type the @, in a particular sequence such that a slight > slip of the finger there and *kaboom*, you have lost your (and/or > everybody else''s) data by accidentally hitting enter instead of shift. > > One can of course protect against this by writing commands backwards and > such, which is what I do for cases like this along with SQL DELETE > statements, but to me it just feels unnecessarily dangerous. > > > One thing that might help here, when not running as root or as a user > > with "ZFS File System Management" RBAC profile, is user delegation. This > > will allow you to run the script as user that can only do certain > > operations to filesystems that they own or have been delegated specific > > access to operate on. > > On the other than a very minor modification to the command line tool > gets you a pretty significant payoff without complicating things. It > will affect the safety of the out-of-the-box tool, regardless of the > local policy for privilege delegation. > > -- > / Peter Schuller > > PGP userID: 0xE9758B7D or ''Peter Schuller <peter.schuller at infidyne.com>'' > Key retrieval: Send an E-Mail to getpgpkey at scode.org > E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org > > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070521/84535380/attachment.html>