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
consid
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
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 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 s
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 p
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
http://mail.opensolaris.org/mailman/listinfo
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 se
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 setti
| 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 on
ECTED]
-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
&l
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
On Aug 20, 2008, at 6:39 PM, Kyle McDonald wrote:
> 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 the
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 agre
I've heard (though I'd be really interested to read the studies if someone
has a link) that a lot of this human error percentage comes at the hardware
level. Replacing the wrong physical disk in a RAID-5 disk group, bumping
cables, etc.
-Aaron
On Wed, Aug 20, 2008 at 3:40 PM, Bob Friesenhahn <
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 po
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 o
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
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
> "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
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 someon
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, wh
> 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
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
replaci
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 reliably.
24 matches
Mail list logo
