One of the storage admins was talking about this issue during lunch.... The really big filesystem (bfs) we moved to NetApp, has continued to grow...to where it is now bigger than a single tray. So, now we have bfs1, bfs2, bfs3, bfs4, bfs5, bfs6 being served up from the NetApp, and the application developers added some storage management feature to the app to support this.
One of the neat things about the zfs appliance, is the nfs migration feature....we make the old share on netapp read-only, point all the clients to the zfs appliance a creates a cache of the metadata and starts copying the data over in the background (or on demand if a client requests something that hasn't been copied over yet). At least that's the theory....storage admin is grumbling that NetApp uses /vol/<filesystem> on the exports and ZFS appliance is using /export/<filesystem> and wants the ZFS appliance to do /vol before trying the NFS migration in production. Guess I don't understand why the name of the export is so important. Where we mount stuff is neither named /vol nor /export. Oracle guy says we could consolidate those filesystems in the move, but we'll need the application developers to change the app back. It requires the developers to poke around if one of the bfs# stores fills up to move stuff to another store. Not sure why the ASAs didn't get the developers to make it so they could manage it themselves. They were also talking about how NetApp licenses every single radio button....manager says its 3 pages long of license keys for the features we got. And, Sun gives everything...and when an update brings new features, it just shows up...don't have to buy it. So far sounds like Oracle isn't going to change that, even though they stopped doing a lot of things that Sun was losing (or not making) money doing. Like .edu discounts. Oh, we ask different groups to estimate their storage needs regularly so we can plan upgrades....well, the people that use 'bfs#'...gave us a graph of their estimated needs....and it shows that they have exponential growth plans and want us to give them infinite storage in 5 years. What was supposed to happen when you fill up a single ZFS pool? ----- Original Message ----- > On Thu, 16 Jun 2011, John Stoffel wrote: > > So push comes to shove, Netapp does NOT offer an easy way to > > expand/grow/migrate your data transparently from one set of > > disks/shelves to another. > > It's not easy, no. Depending on what you're trying to accomplish, > exactly, it may be possible doing a cluster failover and giveback, > though. > It's not really supported, especially for customers, but professional > services still has a few tricks up their sleeves. > _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
