similar to: Undo "zfs destroy -r"

OK I have a very large zfs snapshot I want to destroy. When I do this, the system nearly freezes during the zfs destroy. This is a Sun Fire X4600 with 128GB of memory. Now this may be more of a function of the IO device, but let''s say I don''t care that this zfs destroy finishes quickly. I actually don''t care, as long as it finishes before I run out of disk space. So a

I would like to request an additional flag for the command line zfs tools. Specifically, I''d like to have a -t flag for "zfs destroy", as shown below. Suppose I have a pool "home" with child filesystem "will", and a snapshot "home/will at yesterday". Then I run the following commands: # zfs destroy -t volume home/will at yesterday zfs: not

We have a pair of opensolaris systems running snv_124. Our main zpool ''z'' is running ZFS pool version 18. Problem: #zfs destroy -f z/Users/harrison at zfs-auto-snap:daily-2010-04-09-00:00 cannot destroy ''z/Users/harrison at zfs-auto-snap:daily-2010-04-09-00:00'': dataset is busy I have tried: Unable to destroy numerous datasets even with a -f option.

Hi, Is there a simple way of rolling back to a specific TXG of a volume to recover from such a situation? Many thanks, Przem -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20110627/9b1c5a85/attachment.html>

Hello, I am having a problem destroying zfs snapshots. The machine is almost not responding for more than 4 hours, after I started the command and I can''t run anything else during that time - I get (bash): fork: Resource temporarily unavailable - errors. The machine is still responding somewhat, but very, very slow. It is: P4, 2.4 GHz with 512 MB RAM, 8 x 750 GB disks as raidZ,

Formerly, if you interrupted a zfs receive, it would leave a clone with a % in its name, and you could find it via "zdb -d" and then you could destroy the clone, and then you could destroy the filesystem you had interrupted receiving. That was considered a bug, and it was fixed, I think by Sun. If the lingering clone was discovered laying around, zfs would automatically destroy it.

Hello zfs-discuss, I''m writing a script to do automatically snapshots and destroy old one. I think it would be great to add to zfs destroy another option so only snapshots can be destroyed. Something like: zfs destroy -s SNAPSHOT so if something other than snapshot is provided as an argument zfs destroy wouldn''t actually destroy it. That way it would

Saw this while writing a script today -- while debugging the script, I was ctrl-c-ing it a lot rather than wait for the zfs create / zfs set commands to complete. After doing so, my cleanup script failed to zfs destroy the new filesystem: root at kronos:/ # zfs destroy -f raid/www/user-testuser cannot unshare ''raid/www/user-testuser'': /raid/www/user-testuser: not shared root

Hello, I''ve got auto-snapshots enabled in global zone for home directories of all users. Users log in to their individual zones and home directory loads from global zone. All works fine, except that new auto-snapshot have no properties and therefore can''t be accessed in zones. example from zone: [~/.zfs/snapshot]:$ ls -Alh ls: cannot access

Hi all, I have a RAID-Z zpool made up of 4 x SATA drives running on Nexenta 1.0.1 (OpenSolaris b85 kernel). It has on it some ZFS filesystems and few volumes that are shared to various windows boxes over iSCSI. On one particular iSCSI volume, I discovered that I had mistakenly deleted some files from the FAT32 partition that is on it. The files were still in a ZFS snapshot that was made earlier

Hi all, I installed another OpenSolaris (snv_129) in VirtualBox 3.1.0 on Windows because snv_130 doesn''t boot anymore after installation of VirtualBox guest additions. Older builds before snv_129 were running fine too. I like some features of this OS, but now I end with something funny. I installed default snv_129, installed guest additions -> reboot, set

Hi, I was suffering for weeks from the following problem: a zfs dataset contained an automatic snapshot (monthly) that used 2.8 TB of data. The dataset was deprecated, so I chose to destroy it after I had deleted some files; eventually it was completely blank besides the snapshot that still locked 2.8 TB on the pool. ''zfs destroy -r pool/dataset'' hung the machine within seconds

I was asked by a coworker about recovering destroyed datasets on ZFS - and whether it is possible at all? As a related question, if a filesystem dataset was recursively destroyed along with all its snapshots, is there some means to at least find some pointers whether it existed at all? I remember "zpool import -D" can be used to import whole destroyed pools. But crawling around the

Hi, I''m trying to let zfs users to create and destroy snapshots in their zfs filesystems. So rpool/vm has the permissions: osol137 19:07 ~: zfs allow rpool/vm ---- Permissions on rpool/vm ----------------------------------------- Permission sets: @virtual clone,create,destroy,mount,promote,readonly,receive,rename,rollback,send,share,snapshot,userprop Create time permissions:

I got this in the file system-filesystem-zfs-auto-snapshot:daily.log: ... [ Dez 28 23:13:44 Enabled. ] [ Dez 28 23:13:53 Executing start method ("/lib/svc/method/zfs-auto-snapshot start"). ] Checking for non-recursive missed // snapshots rpool Checking for recursive missed // snapshots home rpool/firefox rpool/ROOT Last snapshot for svc:/system/filesystem/zfs/auto-snapshot:daily taken

Hi guys, after reading the mailings yesterday i noticed someone was after upgrading to zfs v21 (deduplication) i''m after the same, i installed osol-dev-127 earlier which comes with v19 and then followed the instructions on http://pkg.opensolaris.org/dev/en/index.shtml to bring my system up to date, however, the system is reporting no updates are available and stays at zfs v19, any ideas?

Hi everyone I am currently testing Solaris 11 Express. I currently have a root pool on a mirrored pair of small disks, and a data pool consisting of 2 mirrored pairs of 1.5TB drives. I have enabled auto snapshots on my root pool, and plan to archive the daily snapshots onto my data pool. I was wondering how easy it would be, in the case of a root pool failure (i.e. both disks giving up the

On Sun, Dec 27, 2009 at 12:55 AM, Stephan Budach <stephan.budach at jvm.de> wrote: > Brent, > > I had known about that bug a couple of weeks ago, but that bug has been files against v111 and we''re at v130. I have also seached the ZFS part of this forum and really couldn''t find much about this issue. > > The other issue I noticed is that, as opposed to the

http://defect.opensolaris.org/bz/show_bug.cgi?id=1986 Summary: ''zfs destroy'' hangs on encrypted dataset Classification: Development Product: zfs-crypto Version: unspecified Platform: Other OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: other

Hi, I recently upgraded from 2009.06 to b131 (mainly to get dedup support). The upgrade to b131 went fairly smoothly, but then I ran into an issue trying to get the old datasets snapshotted and send/recv''d to dedup the existing data. Here''s the steps I ran: zfs snapshot -r data/media at prereplicate zfs create -o mountpoint=none data/media.new zfs send -R data/media at