I even vaguely think I''ve done it before, but maybe it was against some other component. Anyway, the obvious place I find is <http://www.opensolaris.org/bug/report.jspa>, but the categories don''t include either "zfs" or "filesystems" or anything that it makes sense to me that ZFS might be under. I''ve got this pretty definite problem with zfs receive -d; I''ve posted examples before, but here''s the cleanest one so far. This shows carefully what''s where, and shows that zfs receive -d first refuses to receive because the filesystem *doesn''t* exist, and then because it *does* (and that it didn''t come into existence in between). One of those should have worked! (The one where it does exist should have worked, based on the docs and some other experiments.) Note that this has nothing to do with root pools; the root pool on this system is rpool, which is not involved in this transaction at all. # zpool import -R /backups/bup-ruin bup-ruin # zfs list -r bup-ruin NAME USED AVAIL REFER MOUNTPOINT bup-ruin 35.5M 913G 22K /backups/bup-ruin bup-ruin/fsfs 35.2M 913G 19K /backups/bup-ruin/fsfs bup-ruin/fsfs/rpool 35.2M 913G 19K /backups/bup-ruin/fsfs/rpool bup-ruin/fsfs/rpool/export 35.2M 913G 19K /backups/bup-ruin/fsfs/rpool/export bup-ruin/fsfs/rpool/export/home 35.2M 913G 19K /backups/bup-ruin/fsfs/rpool/export/home bup-ruin/fsfs/rpool/export/home/export 35.1M 913G 18K /backups/bup-ruin/fsfs/rpool/export/home/export bup-ruin/fsfs/rpool/export/home/export/home 35.1M 913G 19K /backups/bup-ruin/export/home bup-ruin/fsfs/rpool/export/home/export/home/localddb 35.1M 913G 27.8M /backups/bup-ruin/export/home/localddb # # zfs list -t snapshot -r zp1 NAME USED AVAIL REFER MOUNTPOINT zp1 at bup-20090223-033745UTC 0 - 33.8M - zp1/ddb at bup-20090223-033745UTC 0 - 326G - zp1/jmf at bup-20090223-033745UTC 0 - 33.2G - zp1/lydy at bup-20090223-033745UTC 0 - 31.1G - zp1/music at bup-20090223-033745UTC 37K - 24.3G - zp1/pddb at bup-20090223-033745UTC 0 - 2.05G - zp1/public at bup-20090223-033745UTC 0 - 33.8G - zp1/raphael at bup-20090223-033745UTC 0 - 18K - # zfs send -R zp1 at bup-20090223-033745UTC | zfs recv -d bup-ruin/fsfs/zp1 cannot receive: specified fs (bup-ruin/fsfs/zp1) does not exist # zfs list -r bup-ruin NAME USED AVAIL REFER MOUNTPOINT bup-ruin 35.5M 913G 22K /backups/bup-ruin bup-ruin/fsfs 35.2M 913G 19K /backups/bup-ruin/fsfs bup-ruin/fsfs/rpool 35.2M 913G 19K /backups/bup-ruin/fsfs/rpool bup-ruin/fsfs/rpool/export 35.2M 913G 19K /backups/bup-ruin/fsfs/rpool/export bup-ruin/fsfs/rpool/export/home 35.2M 913G 19K /backups/bup-ruin/fsfs/rpool/export/home bup-ruin/fsfs/rpool/export/home/export 35.1M 913G 18K /backups/bup-ruin/fsfs/rpool/export/home/export bup-ruin/fsfs/rpool/export/home/export/home 35.1M 913G 19K /backups/bup-ruin/export/home bup-ruin/fsfs/rpool/export/home/export/home/localddb 35.1M 913G 27.8M /backups/bup-ruin/export/home/localddb # zfs create -p bup-ruin/fsfs/zp1 # zfs list -r bup-ruin NAME USED AVAIL REFER MOUNTPOINT bup-ruin 35.5M 913G 22K /backups/bup-ruin bup-ruin/fsfs 35.2M 913G 19K /backups/bup-ruin/fsfs bup-ruin/fsfs/rpool 35.2M 913G 19K /backups/bup-ruin/fsfs/rpool bup-ruin/fsfs/rpool/export 35.2M 913G 19K /backups/bup-ruin/fsfs/rpool/export bup-ruin/fsfs/rpool/export/home 35.2M 913G 19K /backups/bup-ruin/fsfs/rpool/export/home bup-ruin/fsfs/rpool/export/home/export 35.1M 913G 18K /backups/bup-ruin/fsfs/rpool/export/home/export bup-ruin/fsfs/rpool/export/home/export/home 35.1M 913G 19K /backups/bup-ruin/export/home bup-ruin/fsfs/rpool/export/home/export/home/localddb 35.1M 913G 27.8M /backups/bup-ruin/export/home/localddb bup-ruin/fsfs/zp1 18K 913G 18K /backups/bup-ruin/fsfs/zp1 # zfs send -R zp1 at bup-20090223-033745UTC | zfs recv -d bup-ruin/fsfs/zp1 cannot receive new filesystem stream: destination ''bup-ruin/fsfs/zp1'' exists must specify -F to overwrite it -- David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info
On Sun, 22 Feb 2009 22:05:57 -0600 (CST) David Dyer-Bennet <dd-b at dd-b.net> wrote:> > I even vaguely think I''ve done it before, but maybe it was against some > other component. > > Anyway, the obvious place I find is > <http://www.opensolaris.org/bug/report.jspa>, but the categories don''t > include either "zfs" or "filesystems" or anything that it makes sense to > me that ZFS might be under.bugs.opensolaris.org choose (OpenSolaris/Solaris) / kernel / zfs James -- Senior Kernel Software Engineer, Solaris Sun Microsystems http://blogs.sun.com/jmcp http://www.jmcp.homeunix.com/blog
On February 22, 2009 10:05:57 PM -0600 David Dyer-Bennet <dd-b at dd-b.net> wrote:> I''ve got this pretty definite problem with zfs receive -d; I''ve posted > examples before, but here''s the cleanest one so far. This shows carefully > what''s where, and shows that zfs receive -d first refuses to receive > because the filesystem *doesn''t* exist, and then because it *does* (and > that it didn''t come into existence in between). One of those should have > worked! (The one where it does exist should have worked, based on the > docs and some other experiments.)It does sound like a bug, but in practice is this actually a problem for you? Just use -F. -frank
On Sun, February 22, 2009 23:38, Frank Cusack wrote:> On February 22, 2009 10:05:57 PM -0600 David Dyer-Bennet <dd-b at dd-b.net> > wrote: >> I''ve got this pretty definite problem with zfs receive -d; I''ve posted >> examples before, but here''s the cleanest one so far. This shows >> carefully >> what''s where, and shows that zfs receive -d first refuses to receive >> because the filesystem *doesn''t* exist, and then because it *does* (and >> that it didn''t come into existence in between). One of those should >> have >> worked! (The one where it does exist should have worked, based on the >> docs and some other experiments.) > > It does sound like a bug, but in practice is this actually a problem > for you? Just use -F.I left a test of that running last night, but didn''t have a chance to check this morning. However, the problem I was having before hits immediately, and with -F it ran for hours, so I''m at least not having the same problem. I was planning to list -F as a workaround in the bug report, in fact. I view using -F with some concern, though, because if I point it at the wrong backup volume with -F it will happily overwrite the previous backups and all the snapshots that are already there for this filesystem. -- David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info
On Sun, February 22, 2009 23:06, James C. McPherson wrote:> On Sun, 22 Feb 2009 22:05:57 -0600 (CST) > David Dyer-Bennet <dd-b at dd-b.net> wrote: > >> >> I even vaguely think I''ve done it before, but maybe it was against some >> other component. >> >> Anyway, the obvious place I find is >> <http://www.opensolaris.org/bug/report.jspa>, but the categories don''t >> include either "zfs" or "filesystems" or anything that it makes sense to >> me that ZFS might be under. > > bugs.opensolaris.org > choose (OpenSolaris/Solaris) / kernel / zfsYep, works. Thanks. The bug I was looking to file is 6808712. -- David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info