zfs discuss - Jan 2007 - Deadlock with a pool using files on another zfs?

When messing around with zfs trying to break it, I creating a new pool using
files on an existing zfs filesystem.  It seem to work fine until I created a
snapshot of the original filesystem and then tried to destroy the pool using the
files.  The system appeared to deadlock and had to be rebooted.  When it came
back up the files pool was in an error state and could be destroyed.

I don''t see much value in being able to do that but it might be a good
idea to have zpool error out instead of a creating a pool that could crash that
system.


This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On 12/29/06, Eric Schrock <eric.schrock@sun.com>
wrote:
> On Fri, Dec 29, 2006 at 01:48:17PM -0800, Jason Austin wrote:
> > Which part is the bug?  The crash or allowing pools of files that are
on a zfs?
>
> The crash.  Disallowing files from a ZFS filesystem would solve part of
> the problem, but one could always create a lofi device on top of a ZFS
> file, or a file on a UFS filesystem on top of a zvol, which would result
> in the same behavior.  Since one needs PRIV_SYS_CONFIG to create a pool,
> and the solution is non-trivial, it hasn''t been high priority.
So the goal is to allow infinite nesting?

Holger
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

A bit off the subject but what would be the advantage in virtualization using a
pool of files verse just creating another zfs on an existing pool.  My purpose
for using the file pools was to experiment and learn about any quirks before I
go production.  It let me do things like set up a large raidz and fail parts out
without having a ton of disks on my test system.


This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Jason Austin wrote:
> A bit off the subject but what would be the advantage in virtualization
using a pool of files verse just creating another zfs on an existing pool.  My
purpose for using the file pools was to experiment and learn about any quirks
before I go production.  It let me do things like set up a large raidz and fail
parts out without having a ton of disks on my test system.
You can do this sort of testing with ramdisks, too.
  -- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On 12/29/06, Eric Schrock <eric.schrock@sun.com>
wrote:
> On Fri, Dec 29, 2006 at 11:23:30PM +0100, Holger Berger wrote:
> >
> > So the goal is to allow infinite nesting?
> >
>
> That would be my guess, based on the fact that disallowing the opposite
> is effectively impossible.
I guess it may be possible by adding enough return ERRDONTDOTHAT;
lines in the code but IMO it would greatly limit the usefulness of zfs
in virtualization scenarios.
> However, no serious investigation into this
> problem has been done.
;(

Holger
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On 12/29/06, Eric Schrock <eric.schrock@sun.com>
wrote:
> On Thu, Dec 28, 2006 at 04:07:57PM -0800, Jason Austin wrote:
> > When messing around with zfs trying to break it, I creating a new pool
> > using files on an existing zfs filesystem.  It seem to work fine until
> > I created a snapshot of the original filesystem and then tried to
> > destroy the pool using the files.  The system appeared to deadlock and
> > had to be rebooted.  When it came back up the files pool was in an
> > error state and could be destroyed.
> >
> > I don''t see much value in being able to do that but it might
be a good
> > idea to have zpool error out instead of a creating a pool that could
> > crash that system.
>
> Yes, this is a known issue.  There is a bug filed, but I don''t
have it
> offhand.
I hope the "fix" includes the option to create pools on zfs file
systems recursively. It''ll be a shame if there would be a restriction
as it would limit zfs usefulness for virtualization (like creating a
"mobile" zone where all data are stored in a file instead of a
physical disk).

Holger
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On Thu, Dec 28, 2006 at 04:07:57PM -0800, Jason Austin
wrote:
> When messing around with zfs trying to break it, I creating a new pool
> using files on an existing zfs filesystem.  It seem to work fine until
> I created a snapshot of the original filesystem and then tried to
> destroy the pool using the files.  The system appeared to deadlock and
> had to be rebooted.  When it came back up the files pool was in an
> error state and could be destroyed.
>
> I don''t see much value in being able to do that but it might be a
good
> idea to have zpool error out instead of a creating a pool that could
> crash that system.
Yes, this is a known issue.  There is a bug filed, but I don''t have it
offhand.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Which part is the bug?  The crash or allowing pools of files that are on a zfs?


This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On Fri, Dec 29, 2006 at 01:48:17PM -0800, Jason Austin
wrote:
> Which part is the bug?  The crash or allowing pools of files that are on a
zfs?
The crash.  Disallowing files from a ZFS filesystem would solve part of
the problem, but one could always create a lofi device on top of a ZFS
file, or a file on a UFS filesystem on top of a zvol, which would result
in the same behavior.  Since one needs PRIV_SYS_CONFIG to create a pool,
and the solution is non-trivial, it hasn''t been high priority.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

On Fri, Dec 29, 2006 at 11:23:30PM +0100, Holger Berger
wrote:
>
> So the goal is to allow infinite nesting?
>
That would be my guess, based on the fact that disallowing the opposite
is effectively impossible.  However, no serious investigation into this
problem has been done.

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

>On 12/29/06, Eric Schrock <eric.schrock@sun.com> wrote:
>> On Fri, Dec 29, 2006 at 11:23:30PM +0100, Holger Berger wrote:
>> >
>> > So the goal is to allow infinite nesting?
>> >
>>
>> That would be my guess, based on the fact that disallowing the opposite
>> is effectively impossible.
>
>I guess it may be possible by adding enough return ERRDONTDOTHAT;
>lines in the code but IMO it would greatly limit the usefulness of zfs
>in virtualization scenarios.
I thougt the appropriate errno in that case was:

ENOROPE - System has run out of rope.

Casper
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss