On 23/02/2010 02:52, Richard Elling wrote:
On Feb 22, 2010, at 6:42 PM, Charles Hedrick wrote:
I talked with our enterprise systems people recently. I don't believe they'd
consider ZFS until it's more flexible. Shrink is a big one, as is removing an
slog. We also need to be able to expand
On Feb 23, 2010, at 5:10 AM, Robert Milkowski wrote:
On 23/02/2010 02:52, Richard Elling wrote:
On Feb 22, 2010, at 6:42 PM, Charles Hedrick wrote:
I talked with our enterprise systems people recently. I don't believe
they'd consider ZFS until it's more flexible. Shrink is a big one, as
On 23/02/2010 17:20, Richard Elling wrote:
On Feb 23, 2010, at 5:10 AM, Robert Milkowski wrote:
On 23/02/2010 02:52, Richard Elling wrote:
On Feb 22, 2010, at 6:42 PM, Charles Hedrick wrote:
I talked with our enterprise systems people recently. I don't believe they'd
I talked with our enterprise systems people recently. I don't believe they'd
consider ZFS until it's more flexible. Shrink is a big one, as is removing an
slog. We also need to be able to expand a raidz, possibly by striping it with a
second one and then rebalancing the sizes.
--
This message
On Feb 22, 2010, at 6:42 PM, Charles Hedrick wrote:
I talked with our enterprise systems people recently. I don't believe they'd
consider ZFS until it's more flexible. Shrink is a big one, as is removing an
slog. We also need to be able to expand a raidz, possibly by striping it with
a
Hello out there,
is there any progress in shrinking zpools?
i.e. removing vdevs from a pool?
Cheers,
Ralf
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
Hello there,
I'm working for a bigger customer in germany.
The customer ist some thousend TB big.
The information that the zpool shrink feature will not be implemented soon
is no problem, we just keep using Veritas Storage Foundation.
Shirinking a pool is not the only problem with ZFS,
try
Ralf Gans wrote:
Jumpstart puts a loopback mount into the vfstab,
and the next boot fails.
The Solaris will do the mountall before ZFS starts,
so the filesystem service fails and you have not even
an sshd to login over the network.
This is why I don't use the mountpoint settings in ZFS. I
]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Will Murnane
Sent: Thursday, August 21, 2008 1:57 AM
To: Bob Friesenhahn
Cc: zfs-discuss@opensolaris.org
Subject: Re: [zfs-discuss] shrinking a zpool - roadmap
On Wed, Aug 20, 2008 at 18:40, Bob Friesenhahn
[EMAIL
| The errant command which accidentally adds a vdev could just as easily
| be a command which scrambles up or erases all of the data.
The difference between a mistaken command that accidentally adds a vdev
and the other ways to loose your data with ZFS is that the 'add a vdev'
accident is only
WOW! This is quite a departure from what we've been told for the past 2 years...
In fact if your comments are true that we'll never be able to shrink a ZFS
pool, i will be, for lack of a better word, PISSED.
Like others not being able to shrink is a feature that truly prevents us from
WOW! This is quite a departure from what we've been
told for the past 2 years...
This must be misinformation.
The reason there's no project (yet) is very likely because pool shrinking
depends strictly on the availability of bp_rewrite functionality, which is
still in development.
The last
Mario Goebbels wrote:
WOW! This is quite a departure from what we've been
told for the past 2 years...
This must be misinformation.
The reason there's no project (yet) is very likely because pool shrinking
depends strictly on the availability of bp_rewrite functionality, which is
Our enterprise is about 300TB.. maybe a bit more...
You are correct that most of the time we grow and not shrink... however, we are
fairly dynamic and occasionally do shrink. DBA's have been known to be off on
their space requirements/requests.
There is also the human error factor. If someone
j == John [EMAIL PROTECTED] writes:
j There is also the human error factor. If someone accidentally
j grows a zpool
or worse, accidentally adds an unredundant vdev to a redundant pool.
Once you press return, all you can do is scramble to find mirrors for
it.
vdev removal is also
John wrote:
Our enterprise is about 300TB.. maybe a bit more...
You are correct that most of the time we grow and not shrink... however, we
are fairly dynamic and occasionally do shrink. DBA's have been known to be
off on their space requirements/requests.
Isn't that one of the
On Wed, 20 Aug 2008, Miles Nordin wrote:
j == John [EMAIL PROTECTED] writes:
j There is also the human error factor. If someone accidentally
j grows a zpool
or worse, accidentally adds an unredundant vdev to a redundant pool.
Once you press return, all you can do is scramble to
On Wed, Aug 20, 2008 at 18:40, Bob Friesenhahn
[EMAIL PROTECTED] wrote:
The errant command which accidentally adds a vdev could just as easily
be a command which scrambles up or erases all of the data.
True enough---but if there's a way to undo accidentally adding a vdev,
there's one source of
Kyle wrote:
... If I recall, the low priority was based on the percieved low demand
for the feature in enterprise organizations. As I understood it shrinking a
pool is percieved as being a feature most desired by home/hobby/development
users, and that enterprises mainly only grow thier
John wrote:
Our enterprise is about 300TB.. maybe a bit more...
You are correct that most of the time we grow and not shrink... however, we
are fairly dynamic and occasionally do shrink. DBA's have been known to be
off on their space requirements/requests.
For the record I agree with
Zlotnick Fred wrote:
On Aug 20, 2008, at 6:39 PM, Kyle McDonald wrote:
My suggestion still remains though. Log your enterprises wish for this
feature through as many channels as you have into Sun. This list, Sales,
Support, every way you can think of. Get it documented, so that when
they go
Hi,
I am searching for a roadmap for shrinking a pool. Is there some
project, where can I find informations, when will it be implemented in
Solars10
Thanks
Regards
Bernhard
--
Bernhard Holzer
Sun Microsystems Ges.m.b.H.
Wienerbergstraße 3/7
A-1100 Vienna, Austria
Phone x60983/+43 1 60563
Long story short,
There isn't a project, there are no plans to start a project, and don't
expect to see it in Solaris10 in this lifetime without some serious pushback
from large Sun customers. Even then, it's unlikely to happen anytime soon
due to the technical complications of doing so
23 matches
Mail list logo
