While the original reason for this was swap, I have a sneaky suspicion
that others may wish for this as well, or perhaps something else.
Thoughts? (database folks, jump in :-)
Lower overhead storage for my QEMU volumes. I figure other filesystems
running within a ZVOL may cause a
On 7/13/07, Darren J Moffat [EMAIL PROTECTED] wrote:
Mario Goebbels wrote:
While the original reason for this was swap, I have a sneaky suspicion
that others may wish for this as well, or perhaps something else.
Thoughts? (database folks, jump in :-)
Lower overhead storage for my QEMU
Bill Sommerfeld wrote:
On Thu, 2007-07-12 at 16:27 -0700, Richard Elling wrote:
I think we should up-level this and extend to the community for comments.
The proposal, as I see it, is to create a simple,
yes
contiguous (?)
as I understand the proposal, not necessarily
Mario Goebbels wrote:
While the original reason for this was swap, I have a sneaky suspicion
that others may wish for this as well, or perhaps something else.
Thoughts? (database folks, jump in :-)
Lower overhead storage for my QEMU volumes. I figure other filesystems
running within a
Thanks for suggesting a broader discussion about the needs and possible
uses for specialized storage objects within a pool. In doing so, part
of that discussion should include the effect upon overall complexity
and manageability as well as conceptual coherence.
In his blog post on ZFS
Lori Alt wrote:
Treat a pseudo-zvol like you would a slice.
So these new zvol-like things don't support snapshots, etc, right?
I take it they work by allowing overwriting of the data, correct?
yes, and yes
Are these a zslice?
I suppose we could call them that. That's better than
On Thu, 2007-07-12 at 16:27 -0700, Richard Elling wrote:
I think we should up-level this and extend to the community for comments.
The proposal, as I see it, is to create a simple,
yes
contiguous (?)
as I understand the proposal, not necessarily contiguous.
space which sits in a zpool.
