zfs discuss - Dec 2005 - One incorrect and another unhelpful error message from zfs

# mkfile 64m blah
# zpool create b /blah
# zfs snapshot b at first
# zfs rollback b at first
# zfs snapshot b at first
cannot create ''b at first'': snapshot exists
# touch b/f
# zfs rollback b at first
# zfs create b/f
# zfs rollback b at first
cannot rollback to ''b at first'': more recent snapshots exist
use ''-r'' to force deletion of the following snapshots:
b/f
# zfs list -o name,mountpoint
NAME                  MOUNTPOINT
b                     /b
b at first               -
b/f                   /b/f
# zfs snapshot b/f at first
# zfs snapshot b at second
# touch b/f/t
# zfs rollback b at second
cannot unmount ''/b'': Device busy


The "cannot rollback" error message is correct that the rollback
can''t be done without using the "-r" option, but
it''s incorrect about the reason; b/f is a filesystem, not a snapshot.

And the "cannot unmount ''/b'': Device busy" error
message is correct, but fails to provide a suggestion for how to solve the
problem.
This message posted from opensolaris.org

On Wed, Dec 14, 2005 at 04:12:50PM -0800, Andrew wrote:
> # mkfile 64m blah
> # zpool create b /blah
> # zfs snapshot b at first
> # zfs rollback b at first
> # zfs snapshot b at first
> cannot create ''b at first'': snapshot exists
> # touch b/f
> # zfs rollback b at first
> # zfs create b/f
> # zfs rollback b at first
> cannot rollback to ''b at first'': more recent snapshots
exist
> use ''-r'' to force deletion of the following snapshots:
> b/f
> # zfs list -o name,mountpoint
> NAME                  MOUNTPOINT
> b                     /b
> b at first               -
> b/f                   /b/f
> # zfs snapshot b/f at first
> # zfs snapshot b at second
> # touch b/f/t
> # zfs rollback b at second
> cannot unmount ''/b'': Device busy
> 
> 
> The "cannot rollback" error message is correct that the rollback
can''t
> be done without using the "-r" option, but it''s
incorrect about the
> reason; b/f is a filesystem, not a snapshot.
Actually, it should be able to rollback to the previous snapshot.  The
fact that it complains is a bug.
> And the "cannot unmount ''/b'': Device busy"
error message is correct,
> but fails to provide a suggestion for how to solve the problem.
Yep, this is another bug.  We need to unmount any child datasets before
doing the rollback.

Both of these bugs look like holdovers from the days of
''containers'',
when filesystems couldn''t be nested.  We''ll file bugs shortly
and try to
get the fixed.  Thanks for the report.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

Eric Schrock wrote:
> Actually, it should be able to rollback to the
> previous snapshot.  The
> fact that it complains is a bug.
> 
> > And the "cannot unmount ''/b'': Device busy"
error
> message is correct,
> > but fails to provide a suggestion for how to solve
> the problem.
> 
> Yep, this is another bug.  We need to unmount any
> child datasets before
> doing the rollback.
> 
> Both of these bugs look like holdovers from the days
> of ''containers'',
> when filesystems couldn''t be nested.  We''ll file
> bugs shortly and try to
> get the fixed.
What''s supposed to happen to the child datasets after the rollback?
For example, suppose I do:

zfs create tank/foo
touch /tank/foo/bar
zfs snapshot foo at first
rm /tank/foo/bar
touch /tank/foo/baz
zfs rollback foo at first

tank/foo ought to be the same immediately after the rollback as it was when the
snapshot was taken. Therefore the file /tank/foo/baz gets destroyed, and the
file /tank/foo/bar gets restored. No controversy there.
But then consider this:

zfs create tank/foo
touch /tank/foo/bar
zfs snapshot foo at first
rm /tank/foo/bar
zfs create tank/foo/bar
touch /tank/foo/bar/baz
zfs snapshot tank/foo/bar at first
touch /tank/foo/bar/biz
zfs rollback foo at first

Now there''s a child filesystem tank/foo/bar, it has stuff in it, and
there''s even a snapshot of it. But when the rollback to foo at first is
done, there''s supposed to be a file /tank/foo/bar. You have a name
conflict. What do you do? What I propose as the correct thing to do is to
destroy the filesystem tank/foo/bar so that the file /tank/foo/bar can be
restored; thus tank/foo will be the same immediately after the rollback as it
was when the snapshot was taken, as expected.
But now consider:

zfs create tank/foo
zfs create tank/foo/bar
touch /tank/foo/bar/baz
zfs snapshot tank/foo/bar at first
touch /tank/foo/bar/biz
zfs snapshot foo at first
zfs destroy -r tank/foo/bar
touch /tank/foo/bar
zfs rollback foo at first

Now when you do the rollback, the file /tank/foo/bar gets destroyed, but does
the filesystem tank/foo/bar get restored, along with all the stuff that was in
it and its snapshots? I propose that it should; thus, snapshots should be
recursive. Otherwise you have the inconsistent semantics that a rollback is
capable of destroying subfilesystems which were created after the snapshot but
is not capable of restoring subfilesystems which were destroyed after the
snapshot. For consistency, the rollback ought to either be able to do both or be
unable to do either. And since it obviously must be able to do one (destroy
subfilesystems in order to restore files with conflicting names), it therefore
ought to be able to do both.
This message posted from opensolaris.org

On Thu, Dec 15, 2005 at 04:03:26AM -0800, Andrew wrote:
> 
> What''s supposed to happen to the child datasets after the
rollback?
> 
Rollback only affects the contents of the filesystems.  It does not
affect child datasets, properties, or any aspects of the DSL namespace.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

Eric Schrock wrote:
> Rollback only affects the contents of the filesystems. It does not
> affect child datasets, properties, or any aspects of the DSL namespace.
I see; in the event that a subfilesystem''s mountpoint is occupied by a
file or nonempty directory after the rollback, ZFS will simply not automatically
remount the subfilesystem.

The semantics which I was hoping for are that if foo is a ZFS filesystem and a
subfilesystem foo/bar exists, and foo is mounted, then bar is necessarily
mounted too; in other words, that ZFS subfilesystems, though treated as
filesystems within ZFS, would be seen only as directories from the POSIX point
of view, and could not be independently unmounted. This would also require a
single inode namespace at the pool level rather than separate inode namespaces
for subfilesystems, so that hard links would work inter-subfilesystem, so that
the illusion of a single filesystem would be maintained for POSIX''s
sake.
The feature of allowing subfilesystems to be separately unmounted is necessary
if snapshots and rollbacks are not recursive; otherwise, there''s a
namespace conflict, as I pointed out. If snapshots and rollbacks are recursive,
then it doesn''t matter whether separate unmountability is supported.
Recursive snapshots aren''t constant time, but take time proportional to
the subfilesystem nesting depth.
Thus constant-time snapshots require separate unmountability.
Bummer.
This message posted from opensolaris.org