Home | Featured | Data ONTAP 8.0 – Part III

Data ONTAP 8.0 – Part III

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×

I’ve twice posted now on Data ONTAP 8.0 shortcomings and this evening I did a little more research with the IBM version of Netapp’s hardware, the N-Series products.  Fortunately, IBM are slightly more generous and informative in their documentation than Netapp and this document (freely available online) provides more background information on the “DOT8″ transition process.  So, I’ve tried to produce a more in-depth objective view of the steps to move to “DOT8″.  Firstly the following diagram provides a clue as to how Data ONTAP has migrated to the current release.

Data ONTAP History

Data ONTAP History

At the point of reaching DOT8, Data ONTAP has been re-written to run off FreeBSD as the original GX code did.  This is a departure from the original Berkeley Net/2 code as documented in this post from Dave Hitz.  I have no idea how much of this version of the code was a re-write, but presumably porting over WAFL with all the bells and whistles it now has wasn’t an easy task.  This may go towards explaining why the current release of ONTAP took so long to come out.

Although the diagram shows the code base as being a single product, it isn’t.  There are still two modes, 7-mode, emulating  7G and cluster-mode emulating the GX product line.  These modes are non-interchangeable; you choose the one you want to use at system installation time and it’s fixed; no chance to change in the future.  As the IBM document explains (quote) “If a customer decides to change from one mode to another, the change is a transition rather than an upgrade (or downgrade).  Dual boot capabilities are not present, so the transition requires total reconfiguration of the storage system.  This can include backup and restore of user data”.

I think it would have been fairer to draw two parallel lines here as it appears there are still to pretty separate versions of code masquerading as a single marketing version.  So, the remainder of this discussion focuses on 7-mode.


What happens if you want to take an existing system and upgrade it?  Well, depending on your hardware, you may or may not be able to perform an upgrade.  Systems such as the 6xxx models, 3×70 & 3×40 models are upgradeable, devices such as the 2050 are not.  There are also restrictions on the disk shelves that can be used too.  Should you choose to upgrade from your current 7G release, you can only move to 7-mode or build a new 8.0 installation, presumably on new hardware as you wouldn’t want to trash your existing environment.  Be aware though, that upgrade actually removes certain features.  For instance, SMB 2.0, IPv6 & IPSec are not supported.  They will reappear in a future release.  Does this mean writing these features in the ported version of WAFL was too hard or was taking too long?  Why else would you remove features from an upgrade only to replace them later?  One final upgradeability gotcha – Performance Acceleration Modules (PAM) are not supported with the initial version of 8.0.


As mentioned in my previous post, aggregates move to 100TB in size.  However there are many restrictions.

  • Volume SnapMirror will not replicate between unlike aggregate types; so you can’t replicated to/from 32-bit to 64-bit aggregates.
  • aggr copy and vol copy commands will not work between different formats.
  • Flexvol size for volumes using de-duplication in 64-bit aggregates is limited to 16TB
  • System root volumes can only reside on 32-bit aggregates.

On the positive side, Qtree SnapMirror and SnapVault do work between aggregate formats.

Aggregate Migration

Here’s IBM’s statement on migration of data: “Currently there is no direct migration path or conversion from 32-bit to 64-bit aggregates.  The following options can be used to migrate the data: qtree SnapMirror, SnapVault, ndmpcopy”. Each of these options also has limitations, which I don’t have time to go into, but you can read in the referenced document.


I’ve been trying to find any benefits of upgrading to DOT8 from the customer’s perspective. For new installations, the increased aggregate size is obviously a benefit, but does come with restrictions.  There are now interface groups rather than VIFs and it appears snapshots can now be named.  Excluding these, I can’t see that DOT8 is anything more than a positioning exercise as Netapp continue to get the real features they wanted in this version into future releases.  This has been hinted at by other commentators.

Whilst I can see the benefits to Netapp of this move, I fail to see the benefit to the customer, who will have to suffer major migration headaches to realise what are small improvements from a major version upgrade.  I suspect many customers will chose to wait for 8.0.1, 8.1 or whatever version actually integrates the real improvements.  During that time, it offers more opportunities for the competition to be snapping closer to Netapp’s heels.

About Chris M Evans

Chris M Evans has worked in the technology industry since 1987, starting as a systems programmer on the IBM mainframe platform, while retaining an interest in storage. After working abroad, he co-founded an Internet-based music distribution company during the .com era, returning to consultancy in the new millennium. In 2009 Chris co-founded Langton Blue Ltd (www.langtonblue.com), a boutique consultancy firm focused on delivering business benefit through efficient technology deployments. Chris writes a popular blog at http://blog.architecting.it, attends many conferences and invitation-only events and can be found providing regular industry contributions through Twitter (@chrismevans) and other social media outlets.
  • Pingback: Tweets that mention The Storage Architect » Blog Archive » Data ONTAP 8.0 – Part III -- Topsy.com()

  • http://www.backupcentral.com W. Curtis Preston

    One either needs (or doesn’t need) the functionality available in the next version. One might want a 50 TB volume, an interface group, or named snapshots. Any of those is enough to upgrade for the person who wants them.

    The limitations you cite don’t seem like limitations at all. SnapMirror/aggrcopy/volcopy have always been block/volume-based utilities, so if you upgrade the volume you have to upgrade the replicated copy of said volume. Since the main reason to upgrade to DOT8 is to get >16TB volume sizes, how could you replicate the 50 TB volume to a 32-bit volume? If you DON’T need a >16TB volume, why would you upgrade it? As for qtree snapmirror, OTOH, it has always been a file-based utility.

    And FWIW, I only see something as a limitation if it is NEW to that release. For example, you can only do root volumes on 32-bit. That’s the same as the 32-bit version. IOW, it’s not a new limitation; they just didn’t address the old limitation. See what I mean?

    Does it suck that you can’t in-place upgrade a 32-bit volume to 64-bit? You betcha. I can think of a whole lot of other places where the same is true. In-place upgrades tend to be the exception rather than the rule.

    Back to the volume size… So, other than the fact that you can have a volume size that’s more than 6 times larger then before, there’s no benefit. That’s like saying “other than getting 300 MPG, there’s no benefit to me buying this car.” Either you’ve been waiting for that feature or you haven’t. If you have, then it’s here. If you haven’t, then you should wait for the more feature-rich version you’re looking for. (This approach also allows a bunch of people to use it and give it some time in field before the other version comes out.)

  • http://www.brookend.com Chris Evans


    Thanks for the comments. I see your point, however here’s mine. If I upgrade to DOT8, I don’t get 64-bit aggregates as part of the “upgrade” – I can’t convert either the root volume or existing aggregates; so if as you say I’m pushing 16TB on by root aggregate, I have to purchase a new aggregate to get around that – costing me at least a RAID-group’s worth of disks if not more. I may as well stay at ONTAP 7G and just buy more disk. I agree you need to need the new functionality, but if the price of upgrade is a migration then that’s not an upgrade.

    Previously customers would have been able to make use of vol copy or upgrades of the filer head to replace hardware. That was Netapp’s sticky feature – no need to spend hours migrating data as an in-place upgrade was reasonably painless. Now DOT8 seems like a whole new product – restrictions on both hardware and software for the upgrade. If there was ever a time for existing customers to look at whether a migration away from Netapp was a good thing, it’s now as the effort moving to DOT8 is no different than moving to another vendor.


  • http://www.recoverymonkey.org Dimitris Krekoukias

    Hi Chris,

    Since you are trying to help customers that already have NetApp, here’s an idea: It might be easier to have a meeting with a NetApp engineer that, after having you sign an NDA probably, will be able to answer all your questions. It will save you a lot of time and will probably change the tone of your posts.

    I notice at the moment you’re going to various websites looking up docs etc – there’s altogether too much documentation and I admit certain things aren’t covered in the docs you’d expect them to be (but may be in others).

    So, do yourself a favor and start a relationship with someone from engineering… :)

    I’ll cross-post that in your other entries.



  • http://www.brookend.com Chris Evans


    Are you saying anything I’ve posted is incorrect? If there are any discrepancies, let me know and I will correct them, however what I’ve written is published material.

    I’m not sure how much benefit a revelation of futures under NDA would be as I wouldn’t be able to write about it. I doubt my wife would be too impressed if I started dating someone from Netapp Engineering…


  • http://storagebod.typepad.com Martin G

    I don’t find a lot wrong with the tone of Chris’ posts; he’s not being any harder on NetApp than he is on any vendor.

    And Chris is right about the NDA thing; NDAs are a real pain for most bloggers and can almost be seen as a gagging mechanism. If it’s under NDA, we can’t write about it.

    Now I have a vague idea as to what is supposed to be coming in 8.1 and beyond and it is fairly obvious to me that 8.0 was a place-holder release. A ‘We need to get something shipped’ release but all the real goodness will come later. A classic x.0 release!!

  • http://www.brookend.com Chris Evans


    I can understand the concept of a “place-holder” release if it just kept the status-quo, i.e. it was released as part of a re-write to a new platform (e.g. 64 bit). What I don’t get is the removal of existing features, making the upgrade all but impossible for certain customers. It creates uncertainty about when and if features will be re-introduced into the product, despite any promises a vendor may give. I wonder if there are any other examples of this happening? For instance, were key beneficial features removed from VMAX compared to DMX?


  • http://storagebod.typepad.com Martin G

    we need to be fair, lets take Virtual Provisioning from EMC for example; it was certainly less than fully featured at launch. And as far as I know, you still can’t seamlessly migrate into VP from traditional EMC LUNs.

    Nowhere near enough attention is being paid to this; in the rush to deliver new features, no-one seems to be bothering to think about the transition…


  • http://www.brookend.com Chris Evans


    Good example. I think you’re right, releases are coming out half-baked, or should I say, not fully baked. I wouldn’t expect a vendor to provide every feature in the first release, but at least those features that make the product useful


  • http://www.recoverymonkey.org Dimitris Krekoukias

    Hey Chris,

    No need to date anyone from NetApp Engineering… :)

    All I’m saying is, if you know what’s around the corner, NDA or not, it will most probably modify the content of the post since you will then realize there is no point to some of the comments, whether they’re accurate now or not. For the record, I don’t find anything wrong with the tone either, I agree with Martin. It’s just… a little late. You should have posted all that when 8.0 first came out :)

    Bear with me:

    Yes, 8.0 is missing some features vs 7.x (tons of new code, it’s not the same codebase) BUT there’s support for PAM on 8.0 if you need it. So with a PVR NetApp will support PAM (sorry, Flash Cache) on 8.0, for example. Widely known? No, which is why it helps to know an engineer.

    With the 8.01 release out so soon, a lot of your recent posts will become at least partially obsolete. I know that’s being Captain Obvious and all tech is the same that way but, all I’m saying is, whatever frustration prompted you to create these recent posts (and 3-4 posts in a row about a single vendor is, indeed, highly atypical for your blog), would have been lessened given certain knowledge. So, naturally, and not because of NDA restrictions, the post would have looked different.

    BTW: EMC FAST is the worst offender in that space, yet I see very little of that being called out (Clariion FAST in pre-FLARE30 is, at best, weak – with FLARE30 it becomes what EMC intended it to be when they launched it ages ago, and FLARE30 isn’t even out yet, and when it comes out it will be a .0 release!) How about some of that love if you like calling out everyone? :) (I did it here when it was still fresh and nobody could refute it: http://bit.ly/9dj7XW)

    At the moment, 8.0 is the basis for all the new stuff to come, the new foundation if you like. I have many customers that went to 8.0 just to get large aggregates, despite some of the functionality regression. I normally advise my customers to wait until 8.01 anyway. You’re not really making a new point then :) It’s not as if we’ve been pushing everyone to make a mass upgrade to 8.0.

    Isn’t that a pretty universal truth? Who deploys version .0 of anything these days unless they absolutely need a certain feature in that release? Most people will wait until the first major maintenance release at the very least (8.01 in this case).

    Also, quite a few of the software features of V-Max can’t be used in the DMX (or you get a “diluted” version). Slightly older Clariions can’t take FLARE30. Same way some older NetApp platforms that don’t support 64-bitness can’t be upgraded to ONTAP 8. We can’t support the older boxes perpetually – no vendor does that.

    Hopefully this won’t seem to you as an affront… :) Just trying to explain my perspective.


  • Adriaan


    Lets look at this another way.
    Firstly I commend your stance on prodding vendors to do better and this is not to discourage this or to protest any bias.
    You have fashioned a series of blogs around NetApp and perceived shortcoming, questions and concerns. no problem.
    You are trying to solve real problems for large clients and are simply being challenging to the suppliers about the tools they provide for your toolkit.


    You are not party to the NDA material, are not well connected into the NetApp community and are basing your work on openly accesible research, reading and materials. (have I got this wrong?)

    You are then publically raising issues you have eg. why are there features in missing in 7 mode DOT8.0. Answer is simple – the code freeze used for the transition into DOT8.0 is not the latest DOT7, but an earlier one – your own software development experience should confirm this for you as a necessary expediency – the latest additions to DOT7 will need to be added in beyond the 8.0 release. Access to NetApp will have clarified this – it was part of sessions I attended as long ago as late 2007. I have thus been able to plan for two years without this surprise.

    You raise further issues without indication that you have approached NetApp for solution – You have become aware of them recently, they have been working on this for two years. Dimitris indicated this as the tone of your article – clearly he did not mean it as bias – but it would seem to him that you think NetApp has not put thought or effort into this. I am sure you two will find you can get to common ground with a bit of open direct discussion.

    I am comfortable with the comment above that DOT8 is not fully baked – and NetApp will probably also by giving clear guidance under which circumstances they recomend for or against early upgrade to DOT8. Further revisions beyond dot8 would become progressively more baked.

    you cannot have it all ways, lots of new features, rapid release of software updates and mission critical support for all features, so choose two. I support your encouragement that they try harder, and recomend you take up the multiple offers to get included into the community.

    I take another view to the NDA quandary – having read the small print many times – There is very little that is new and secret squirrel stuff that goes on – and it it not hard keeping that isolated. Most of the information is similiar to competitors, and rapidly becomes available publically in generic form. What I find honour bound to, is respecting the timeline and content of release plans and early access to information on expected limitations and workarounds so I can plan and advise properly.

    New releases of any product have sensitive issues – see Chad Sakac’s handling of the VAAI stuff on his blog as a good example. You can bet insiders knew that stuff many months ago.

  • http://www.brookend.com Chris Evans


    Phew – glad to hear dating is not required. The subject of “.0″ product adoption is an interesting one. Certainly the test will be what happens with 8.0.1 or 8.1 which by the sounds of things is more likely to be the killer release. Unfortunately I doubt we’ll see that within the next 6 months?

    Now, no offence taken for you calling out EMC (I’m sure they would have returned the favour). Most vendors are equally culpable when it comes to over-hyping their features.

    Whilst it is unusual for me to post 3 Netapp posts in a row, this subject was fresh in my mind and the first 2 posts didn’t really do justice to what I was thinking. However tomorrow is another day. Don’t expect post number 4 – yet.


  • http://www.brookend.com Chris Evans


    I have to take issue with a number of your comments; firstly I *am* party to NDA information, albeit limited and clearly there’s no way I would discuss anything I know with this regard as it would be unprofessional. Second, you describe the Netapp “community” as if it is some sort of private members club. It’s irrelevant to my discussion. Not having access to the “netapp community” doesn’t disbar me from having an opinion.

    As I said, I have only been reviewing this recently – I work on a range of technologies – not just one. This means I come back to technology on a periodic basis. So just because I am quoting my experiences as they occur shouldn’t be a cause for derision either.

    Let’s take a look at where we stand with DOT8. It was released almost exactly a year ago, deficient of certain features. There’s promise of 8.0.1 & 8.1 – neither of which I believe have official release dates. If 8.0 was an interim “get something out there” release, then surely 8.0.1 should have been a quick follow up. Assuming 8.1 is released this time next year, then there will have been a 2 year lag in getting version 8 simply back to parity with the last version of 7G.

    Yet again there’s the heart of the discussion – 2 years to bring code back to parity on a new codebase. Does this sound like an agile flexible operating system with plenty of life left in it?

  • http://www.recoverymonkey.org Dimitris Krekoukias


    You wrote:

    “Yet again there’s the heart of the discussion – 2 years to bring code back to parity on a new codebase. Does this sound like an agile flexible operating system with plenty of life left in it?”

    Interesting view, and I think that seems to be the point of all your recent articles regarding ONTAP.

    This is more akin to Sun changing from BSD to SysV than anything else :)

    When that happened back in the day, I lamented the loss of various features, then eventually the grand vision for Solaris became clear over the years. The old codebase wouldn’t scale to what Sun was planning. Or maybe I have it wrong, but you get the idea…

    Effectively, it’s a rewrite, with most of the existing features within a new codebase, plus some new ones, and with some insane ones to come. So indeed it takes a lot of time to do it right, in order to ensure the system will have plenty of life left in it.

    This is mission-critical code, and ensuring quality to that level takes precedence over putting in features.

    Would I like it to have happened in 2 months? Sure.

    Is it realistic?


  • http://www.brookend.com Chris Evans


    Let’s just wait and see if the promise lives up to the hype.

  • Adriaan


    First of all my intention was not to be derisory – that comment jumped out at me – if you thought so I apologise unreservedly.

    So as for the NetApp community – this is in no way a private members club- it is simply the active and ready to engage and help people in and outside of NetApp willing to help and learn from each other. Many are active on forums – Alex Mc, Dimitris, Radek, John Martin, John Fulbright, Vaughn to name a few. Many more will go out of their way to help and answer questions.

    Here is the first issue – they do expect you to listen and learn to understand the bigger picture before challenging each basic step. This is because they acknowledge there are compromises that have to be made, and ways to mitigate certain undesired behaviours in the products. YES, of course there are both good and bad outcomes.

    So as a resposible outsider you are free to accept or decline the solution, even to seek change, but they do reserve the right to keep to their way and change occurs long before a product is released.

    I believe you have a lot of experience and can provide valuable input – but more into the fundamental direction which means engaging deeper into the company.

    You also clearly deserve better access to information than purely reading up so that you can provide the best forward guidance on system use. I support not only a consumer council, but there should also be a forum for people who work across the industry or in complementary roles.

    You have my email and I would try answer or redirect any queries – I have never worked for NetApp, but in the reseller, consulting and user space.

  • Pingback: Articles » Blog Archive » Losing Your Mind With Data Recovery()

  • Bryce Devito

    The in place 32 bit–>64 bit upgrade will be available in the next version of ONTAP. That’s what I’m waiting for before upgrading.

  • Pingback: The Storage Architect » Blog Archive » EMC Delays New CLARiiON and Celerra? – UPDATED()

  • Prism

    Why would anyone run out of space on the root aggregate? NetApp specifically recommends that the root aggregate never be used for data storage. I don’t see the problem with the root being a 32-bit aggr because it should never be larger than a 3-disk raid group. Since the config & logs are far smaller than today’s smallest drives your root aggregate should have more than enough space, while aggr1 can be as big as you want- and contain many 28-disk raid groups to maximize your system capacity if it works for you.

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×