Mailing List Archive: Netapp: toasters

Bigger Aggregates (was Re: HSM/ILM for Netapp)

Index | Next | Previous | View Threaded

scl at sasha

Jun 2, 2009, 1:32 PM

Post #1 of 4 (1876 views)
Permalink

Bigger Aggregates (was Re: HSM/ILM for Netapp)

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 6/2/09 1:34 PM, Page, Jeremy wrote:
> > I thought they where planning to move to 100TB volumes in the very near
> > future (7.4?)
>
> DOT 8.0 is supposedly bringing WAFL improvements to allow for 100TB
> aggrs/vols (rumored to be dropping this summer).
>
> I also hear jumping any 7.x variant to 8.0 will be a disruptive upgrade.
>
> Cheers.
>
> - --
> Nick Silkey
>

I would really, really, really like to see a utility in DOT 8.x
where one aggregate can "assimilate" another aggregate. In other
words I want to combine aggrA and aggrB into a new aggrA that
contains all of the raid groups (and volumes) of the two aggregates,
with aggrB disappearing.

I don't see why this would be difficult to do. Just move the raid
groups (and hence volumes) from aggrB to aggrA. I understand that
there need to be restrictions (all RGs need to have the same raid
type, and no mixing of FC and SATA disks, etc.) Anything to avoid
massive data copies. It would even be fine if this had to be done
from a maintenance boot.

Right now I have 11 identical 10T aggregates on my snapmirror destination
filer (Each consists of 1 raid-dp RG of 16 1TB SATA disks. I would have
built slightly smaller RGs, but the 16T limit made that too wasteful.)
It's a pain to figure out where to snapmirror a new source volume, since
everyone seems to want at least 5T volumes now. I occasionally need to
reshuffle to make room. I would LOVE to be able combine all these "little"
10T aggrs into one or two bigger aggrs.

I also hope they set the limit way bigger than 100T, which seems like
just kicking the can down the road to me.

Steve Losen scl [at] virginia phone: 434-924-0640

University of Virginia ITC Unix Support

dsiggins at maileig

Jun 2, 2009, 1:52 PM

Post #2 of 4 (1747 views)
Permalink

RE: Bigger Aggregates (was Re: HSM/ILM for Netapp) [In reply to]

Greetings,
Seems like someone is hearing more rumors than I about DOT 8.0. I assume this feature you are speaking of will be very similar to the "striped volume" feature on GX, and not a true 100T volume

Don't keep your hopes too high. The bottleneck ends up being the MDV -- essentially another volume that keeps the metadata for the striped volumes. I also don't believe we have the ability in GX to snapmirror (or volume mirror) a striped volume.

Did you hear this information from a sales person?

Regards,
Douglas Siggins

-----Original Message-----
From: owner-toasters [at] mathworks on behalf of Stephen C. Losen
Sent: Tue 6/2/2009 4:32 PM
To: toasters [at] mathworks
Subject: Bigger Aggregates (was Re: HSM/ILM for Netapp)

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 6/2/09 1:34 PM, Page, Jeremy wrote:
> > I thought they where planning to move to 100TB volumes in the very near
> > future (7.4?)
>
> DOT 8.0 is supposedly bringing WAFL improvements to allow for 100TB
> aggrs/vols (rumored to be dropping this summer).
>
> I also hear jumping any 7.x variant to 8.0 will be a disruptive upgrade.
>
> Cheers.
>
> - --
> Nick Silkey
>

I would really, really, really like to see a utility in DOT 8.x
where one aggregate can "assimilate" another aggregate. In other
words I want to combine aggrA and aggrB into a new aggrA that
contains all of the raid groups (and volumes) of the two aggregates,
with aggrB disappearing.

I don't see why this would be difficult to do. Just move the raid
groups (and hence volumes) from aggrB to aggrA. I understand that
there need to be restrictions (all RGs need to have the same raid
type, and no mixing of FC and SATA disks, etc.) Anything to avoid
massive data copies. It would even be fine if this had to be done
from a maintenance boot.

Right now I have 11 identical 10T aggregates on my snapmirror destination
filer (Each consists of 1 raid-dp RG of 16 1TB SATA disks. I would have
built slightly smaller RGs, but the 16T limit made that too wasteful.)
It's a pain to figure out where to snapmirror a new source volume, since
everyone seems to want at least 5T volumes now. I occasionally need to
reshuffle to make room. I would LOVE to be able combine all these "little"
10T aggrs into one or two bigger aggrs.

I also hope they set the limit way bigger than 100T, which seems like
just kicking the can down the road to me.

Steve Losen scl [at] virginia phone: 434-924-0640

University of Virginia ITC Unix Support

scl at sasha

Jun 2, 2009, 2:16 PM

Post #3 of 4 (1743 views)
Permalink

Re: Bigger Aggregates (was Re: HSM/ILM for Netapp) [In reply to]

>
> Greetings,
> Seems like someone is hearing more rumors than I about DOT 8.0. I assume this feature you are speaking of will be very similar to the "striped volume" feature on GX, and not a true 100T volume
>
> Don't keep your hopes too high. The bottleneck ends up being the MDV -- essentially another volume that keeps the metadata for the striped volumes. I also don't believe we have the ability in GX to snapmirror (or volume mirror) a striped volume.
>
> Did you hear this information from a sales person?
>

No, I'm just responding to to the earlier toasters thread.

I'm not talking about striped volumes -- just regular aggregates,
volumes, and files, all of which are limited to 16T.

The 16T limit comes from using a 32 bit integer to store block
id numbers. In WAFL a block is 4K so 4K * (2 ^ 32) = 16T.

I think an engineer once told me that they now store block id
numbers in 64 bit integers, but have not raised the limit
because they need to redesign any algorithms that do not
scale gracefully. Since DOT 8.x is a major upgrade from 7.x
(where aggregates, flex vols, flex clones, etc., were first
introduced) I am hoping that the 16T limit will be increased
significantly.

Overall I am very pleased with netapp, but this 16T limit has got
to be costing them business, since several of their competitors
(Isilon, BlueArc) allow single volumes of over a petabyte.

Steve Losen scl [at] virginia phone: 434-924-0640

University of Virginia ITC Unix Support

Darren.Sykes at csr

Jun 3, 2009, 2:43 AM

Post #4 of 4 (1718 views)
Permalink

RE: Bigger Aggregates (was Re: HSM/ILM for Netapp) [In reply to]

I'd expect you're right... actual single aggregates of 100GB sound
unlikely to be.

However, don't write off striped volumes due to MDV bottlenecks. That
issue is likely to go away in the future.

Snapmirror a striped volume, you'd imagine Netapp would be working on
fixing that issue in a release of OnTAP 8 too.

Darren

From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
On Behalf Of Douglas Siggins
Sent: 02 June 2009 21:52
To: Stephen C. Losen; toasters [at] mathworks
Subject: RE: Bigger Aggregates (was Re: HSM/ILM for Netapp)

Greetings,
Seems like someone is hearing more rumors than I about DOT 8.0. I assume
this feature you are speaking of will be very similar to the "striped
volume" feature on GX, and not a true 100T volume

Don't keep your hopes too high. The bottleneck ends up being the MDV --
essentially another volume that keeps the metadata for the striped
volumes. I also don't believe we have the ability in GX to snapmirror
(or volume mirror) a striped volume.

Did you hear this information from a sales person?

Regards,
Douglas Siggins

-----Original Message-----
From: owner-toasters [at] mathworks on behalf of Stephen C. Losen
Sent: Tue 6/2/2009 4:32 PM
To: toasters [at] mathworks
Subject: Bigger Aggregates (was Re: HSM/ILM for Netapp)

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 6/2/09 1:34 PM, Page, Jeremy wrote:
> > I thought they where planning to move to 100TB volumes in the very
near
> > future (7.4?)
>
> DOT 8.0 is supposedly bringing WAFL improvements to allow for 100TB
> aggrs/vols (rumored to be dropping this summer).
>
> I also hear jumping any 7.x variant to 8.0 will be a disruptive
upgrade.
>
> Cheers.
>
> - --
> Nick Silkey
>

I would really, really, really like to see a utility in DOT 8.x
where one aggregate can "assimilate" another aggregate. In other
words I want to combine aggrA and aggrB into a new aggrA that
contains all of the raid groups (and volumes) of the two aggregates,
with aggrB disappearing.

I don't see why this would be difficult to do. Just move the raid
groups (and hence volumes) from aggrB to aggrA. I understand that
there need to be restrictions (all RGs need to have the same raid
type, and no mixing of FC and SATA disks, etc.) Anything to avoid
massive data copies. It would even be fine if this had to be done
from a maintenance boot.

Right now I have 11 identical 10T aggregates on my snapmirror
destination
filer (Each consists of 1 raid-dp RG of 16 1TB SATA disks. I would have
built slightly smaller RGs, but the 16T limit made that too wasteful.)
It's a pain to figure out where to snapmirror a new source volume, since
everyone seems to want at least 5T volumes now. I occasionally need to
reshuffle to make room. I would LOVE to be able combine all these
"little"
10T aggrs into one or two bigger aggrs.

I also hope they set the limit way bigger than 100T, which seems like
just kicking the can down the road to me.

Steve Losen scl [at] virginia phone: 434-924-0640

University of Virginia ITC Unix Support

To report this email as spam click here
<https://www.mailcontrol.com/sr/09GGQ8zDbgfTndxI!oX7Uoa1VnJPWXo6fVziaKzd
JZaqbNfBm0Cn26uIE3Jkf5d0NMZGMWsdFFILtzovJ!KJwA==> .

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads