From owner-freebsd-current@FreeBSD.ORG Fri Jun 5 13:09:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96162106566B for ; Fri, 5 Jun 2009 13:09:42 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 52D0A8FC15 for ; Fri, 5 Jun 2009 13:09:42 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:35779 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MCZAj-0001wl-5u for freebsd-current@freebsd.org; Fri, 05 Jun 2009 15:09:27 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 23C19335DA for ; Fri, 5 Jun 2009 15:09:24 +0200 (CEST) Message-Id: <1F0CF2D2-D53D-4C3D-9936-8F429525D89F@exscape.org> From: Thomas Backman To: FreeBSD Current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 5 Jun 2009 15:09:21 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MCZAj-0001wl-5u. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MCZAj-0001wl-5u 4a3db4a7bf358e32072bee33106a9a77 Subject: ZFS send/recv and overwriting of existing mounts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 13:09:42 -0000 Hey all, I was wondering if there could (should?) be some kind of protection of over-mounting/shadowing (whatever the term is; overriding an existing mount) in ZFS. Take this as an example (from my memory, as the shell history is gone due to the forceful shutdown): zfs create tank/test zfs snapshot tank/root@now zfs send -R tank/root@now | zfs recv -vf tank/test ... bam, you now have two filesystems mounted on /, an empty /dev directory unless you double-mount devfs as well, etc. Reboot, and the same thing happens - it mounts root from /boot/ loader.conf, then rc.conf executes and mounts the tank/test root copy over /, again hiding /dev and making your system non-bootable. The only solution I've found so far is to reboot to livefs and destroy the copy... Ugh. I was just gonna test to see if send -R worked on vanilla sources now (I've had to use a patch previously), which it did, but I didn't expect it to override my root! (Single-user might have worked, now that I think about it; still, that too requires downtime to fix something that shouldn't really happen.) I guess you COULD file this under the "feature, not a bug" section, but in cases like this, I'd say "bug". Regards, Thomas