Re: [zfs-discuss] Making 'zfs destroy' safer
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 [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org signature.asc Description: OpenPGP digital signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Making 'zfs destroy' safer
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 [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org signature.asc Description: OpenPGP digital signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Making 'zfs destroy' safer
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/[EMAIL PROTECTED]? 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 [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org signature.asc Description: OpenPGP digital signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Making 'zfs destroy' safer
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/[EMAIL PROTECTED] Where the use of snapshot: would guarantee that non-snapshots are not affected. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org signature.asc Description: OpenPGP digital signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Making 'zfs destroy' safer
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/[EMAIL PROTECTED]? 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 [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Making 'zfs destroy' safer
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/[EMAIL PROTECTED]? 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@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Making 'zfs destroy' safer
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 [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Making 'zfs destroy' safer
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
