Maurice Volaski wrote:
I think my initial response got mangled. Oops.
creating a ZFS pool out of files stored on another ZFS pool. The main
reasons that have been given for not doing this are unknown edge and
corner cases that may lead to deadlocks, and that it creates a complex
structure with potentially undesirable and unintended performance and
reliability implications.
Computers are continually encountering unknown edge and corner cases in
the various things they do all the time. That's what we have testing for.
I agree. The earlier discussions of this topic raised the issue that
this is not a well tested area and is an unsupported configuration.
Some the of problems that arise in nested pool configurations may also
arise in supported pool configurations; nested pools may significantly
aggravate the problems. The trick is to find test cases in supported
configurations so the problems can't simply be swept under the rug of
"unsupported configuration".
Deadlocks may occur in low resource
conditions. If resources (disk space and RAM) never run low, the
deadlock scenarios may not arise.
It sounds like you mean any low resource condition. Presumably, utilizing
complex pool structures like these will tax resources, but there are many
other ways to do that.
We have seen ZFS systems lose stability under low resource conditions.
They don't always gracefully degrade/throttle back performance as
resources run very low.
I see a parallel in the 64 bit vs 32 bit ZFS code...the 32 bit code has
much tighter resource constraints put on it due to memory addressing
limits, and we see notes in many places that the 32 bit code is not
production ready and not recommended unless you have no other choice.
The machines the 32 bit code is run on also tend to have tighter
physical resource limits, which compounds the problems.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
