toasters

toasters@lists.teaparty.net

13520 discussions

RE: VMware / A-SIS
by Davies,Matt 28 Oct '07

28 Oct '07

I was about to ask the same question..... -----Original Message----- From: owner-toasters(a)mathworks.com <owner-toasters(a)mathworks.com> To: Alan McLachlan <alanmac(a)technologist.com>; toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Sun Oct 28 21:09:20 2007 Subject: RE: VMware / A-SIS Ummmm.... What ESX CIFS driver? -----Original Message----- From: Alan McLachlan [mailto:alanmac@technologist.com] Sent: Sunday, October 28, 2007 8:26 AM To: toasters(a)mathworks.com Subject: VMware / A-SIS Hi Vaughn, For small environments on a budget where the cost of additional licenses is an issue, you can use RDM's over iSCSI or FCP for both data LUN's _and_ the VM OS images. You still need VMDK pointer files to enable vmotion. By using RDM's for the VM images you can use lun cloning for R/W snapshots within the same FlexVol, without paying for a FlexClone license and achieve a reasonable level of deduplication without paying for an A-SIS licence. i.e. create "golden images" as source LUNs then use lun clones for the prod, dev, test and backup images of the VM's. However, for larger environments using vmdk's on NAS from NFS exports or CIFS shares for the VM images is a far more scalable and manageable solution as long as you're happy to pay for A-SIS to manage deduplication. I still wouldn't be putting data volumes inside the vmdk's though. (Yes, you can use CIFS for vmdk's in ESX. Not as ideal as NFS for a whole bunch of reasons, but it works via the VMWare ESX CIFS driver and useful if you have to have CIFS for file server consolidation and don't want to pay for NFS licencing as well). Either way, storing your application data in either RDM LUN's or as direct NAS shares makes managing snapshots for dev/test copies and online backups of the production data much simpler to manage. Putting data inside vmdk's limits your functionality particularly for backups. MSCS requires an RDM for the quorum disk, but you can still use a NAS share for the data if your data profile and application characteristics indicate that it makes more sense to do that than use an RDM for the data. regards, Alan McLachlan. -----Original Message----- From: owner-toasters(a)mathworks.com on behalf of M. Vaughn Stewart Sent: Sun 10/28/2007 8:07 AM To: Jack Lyons Cc: Page, Jeremy; toasters(a)mathworks.com Subject: Re: A-SIS questions FlexClone will clone a datastore, for VM level cloning granularity you gonna have to wait I think something is just around the corner. As for MSCS you need RDMs as VMDKs are not supported with MSCS RDMs can be either FCP or iSCSI VMDKs can be on NFS or VMFS (which is over FCP or iSCSI) -- Want an e-mail address like mine? Get a free e-mail account today at www.mail.com! _____________________________________________________________ This e-mail (including all attachments) is confidential and may be privileged. It is for the exclusive use of the addressee only. If you are not the addressee, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately at help(a)generalatlantic.com <mailto:help@generalatlantic.com>. Thank You.

1 0

VMware / A-SIS
by Alan McLachlan 28 Oct '07

28 Oct '07

Hi Vaughn, For small environments on a budget where the cost of additional licenses is an issue, you can use RDM's over iSCSI or FCP for both data LUN's _and_ the VM OS images. You still need VMDK pointer files to enable vmotion. By using RDM's for the VM images you can use lun cloning for R/W snapshots within the same FlexVol, without paying for a FlexClone license and achieve a reasonable level of deduplication without paying for an A-SIS licence. i.e. create "golden images" as source LUNs then use lun clones for the prod, dev, test and backup images of the VM's. However, for larger environments using vmdk's on NAS from NFS exports or CIFS shares for the VM images is a far more scalable and manageable solution as long as you're happy to pay for A-SIS to manage deduplication. I still wouldn't be putting data volumes inside the vmdk's though. (Yes, you can use CIFS for vmdk's in ESX. Not as ideal as NFS for a whole bunch of reasons, but it works via the VMWare ESX CIFS driver and useful if you have to have CIFS for file server consolidation and don't want to pay for NFS licencing as well). Either way, storing your application data in either RDM LUN's or as direct NAS shares makes managing snapshots for dev/test copies and online backups of the production data much simpler to manage. Putting data inside vmdk's limits your functionality particularly for backups. MSCS requires an RDM for the quorum disk, but you can still use a NAS share for the data if your data profile and application characteristics indicate that it makes more sense to do that than use an RDM for the data. regards, Alan McLachlan. -----Original Message----- From: owner-toasters(a)mathworks.com on behalf of M. Vaughn Stewart Sent: Sun 10/28/2007 8:07 AM To: Jack Lyons Cc: Page, Jeremy; toasters(a)mathworks.com Subject: Re: A-SIS questions FlexClone will clone a datastore, for VM level cloning granularity you gonna have to wait I think something is just around the corner. As for MSCS you need RDMs as VMDKs are not supported with MSCS RDMs can be either FCP or iSCSI VMDKs can be on NFS or VMFS (which is over FCP or iSCSI) -- Want an e-mail address like mine? Get a free e-mail account today at www.mail.com!

3 2

RE: A-SIS questions
by Kevin Parker 27 Oct '07

27 Oct '07

J: pretty sure it has no/minimal impact since it is performing the equivalent of a snapshot operation of just dropping a pointer to blocks of data. It also has to mark blocks of disk as 'clean' now that they're free. Minimal impact. Also consider that asis requires nearstore option which will additional 256k of ram for additional snapmirror stream that it allows. Again, vry minimal impact. As to snapmirror footprint...it will send 700m over, but if dest. Isn't SIS'd, it will return to 1gb I could be wrong in both points above so open to be corrected. Good weekend to all. **Sent using wireless handheld... please excuse any typo's or brevity** Kevin Parker - NWN Corporation www.nwnit.com -----Original Message----- From: "Page, Jeremy" <jeremy.page(a)gilbarco.com> To: "toasters(a)mathworks.com" <toasters(a)mathworks.com> Sent: 10/26/2007 3:10 PM Subject: A-SIS questions I have read some of the info on how A-SIS works but I have a couple of questions: 1) Assuming an average compression rate (say /home with random docs in it) how much of a performance hit does it impose 2) Does it change how much data is sent over the wire when you use SnapMirror/SnapVault? I.e. if I get 30% compression on a 1 gig snapshot do I send 1 gig or 700 mb to update my target? Oh, and for the folks who helped earlier, we are moving our Oracle and ESX systems to NetApp, the pSeries will be fibre connected, at least at first but the ESX stuff is all going on NFS. ~Jeremy This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately. ________________________________ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately.

3 2

Re: The End of All Filers?
by Scott Baker 26 Oct '07

26 Oct '07

This cracks me up. NetApp helped themselves to a bunch of Auspex patents years ago, and quickly purchased them once Auspex went under so no one else could sue them for patent infringement. Talk about the pot calling the kettle black. ----- Original Message ---- From: Tim McCarthy <tmacmd(a)gmail.com> To: Maxwell Reid <max.reid(a)saikonetworks.com>; owner-toasters(a)mathworks.com; Glenn Dekhayser <gdekhayser(a)voyantinc.com>; NetApp Toasters List <toasters(a)mathworks.com> Sent: Thursday, October 25, 2007 6:09:26 PM Subject: Re: The End of All Filers? Last I heard years ago... Portions of ONTAP we're borrowed from FreeBSD (like TCP). A number of years ago, all that borrowed code had been re-written, so much so that it could no longer be FreeBSD fragments. Sent from my Verizon Wireless BlackBerry -----Original Message----- From: "Maxwell Reid" <max.reid(a)saikonetworks.com> Date: Thu, 25 Oct 2007 17:52:14 To:"'Glenn Dekhayser'" <gdekhayser(a)voyantinc.com>, <toasters(a)mathworks.com> Subject: RE: The End of All Filers? FYI, FreeBSD is used primarily by GX based systems. Classic ONTAP is proprietary, with some stuff borrowed from NetBSD (probably for portability across different processor architectures.) Regards, Max > -----Original Message----- > From: owner-toasters(a)mathworks.com > [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser > Sent: Thursday, October 25, 2007 5:20 PM > To: toasters(a)mathworks.com > Subject: RE: The End of All Filers? > > > OK, here's what bugs me about Schwartz's comments. > > He brings up FreeBSD, and Netapp's 'use' of this open-sourced > OS on which Ontap is 'based' - let's just put the validity of > that statement away for the time being because we'll start a > whole fork of the conversation just on THAT (yeah, and Vista > is based on MS-DOS 1). > > He (jonathan) vilifies Netapp as hypocritical for using the > open-sourced OS, yet trying to kill poor little open-sourced > ZFS, insinuating that Netapp will approve of open-source when > it suits them and fight it when it becomes inconvenient. > > Here's the thing- BSD VOLUNTARILY open-sourced FreeBSD. It > was THEIR CHOICE because THEY OWNED IT. Netapp didn't take > SCO Unix (if they 'took' anything at all) and said "we'll use > that, I found the code on Gopher" (well, it WAS a long time ago.). > > Netapp did not voluntarily release WAFL nor would one expect > them to. For Sun to open-source IP that it did not own is NOT > LEGAL OR CORRECT, assuming that Netapp's patents hold up to > the prior art claims (and I think they will, since ZFS and > its underpinnings came later). > > Someone with a cynical view could concoct a few scenarios in > which Sun DELIBERATELY open-sourced ZFS because perhaps they > KNEW they would get crucified in a patent battle, and by > open-sourcing it, they let the cat out of the bag, so to > speak. They do say that it's easier to ask for > forgiveness than to ask for permission, right? Tagging > Netapp with an > 'anti-open-source' label gains an instant fan-base of many > Linux freaks (I say 'freaks' affectionately as I am one), and > comes with some real possible economic pain for Netapp, so > maybe there was a mis-calculation that netapp would just let > it be. A mis-calculation, by the way, that could have severe > ramifications on Mr. Schwartz's employment I'm sure. The tone > of jonathan's blog does wreak a bit of mad desperation, doesn't it? > > > Well enough of that. I'm going out with netapp tonight in > san Francisco! :-) > > Glenn (the other one) > > > > > > > > > > > > Subject: RE: The End of All Filers? > > Glenn wrote: > > >Let me see if I got this straight: > >ZFS copied the snapshot technologies, and general way that > WAFL works, > >which is patented by NetApp. Then released it to the open source > >community. > > You got that about right. > > >What did I miss? > > StorageTek's Iceberg product was where a lot of the concepts > came from originally. > > It's a matter of the judge & jury's preference and the > questions that are put before them - should you be able to > implement a technology solution concept with your code if you > use some of the same algorithms? Did Sun actually see the > source code and steal it? Who is a llowed to copy who? Who > owns the original patents? > > Looks like quite a circular argument to me. > > It'll be interesting to see who wins. > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

The End of All Filers?
by No More Linux! 26 Oct '07

26 Oct '07

http://blogs.sun.com/jonathan/entry/harvesting_from_a_troll

12 15

RE: The End of All Filers?
by Glenn Marsh 25 Oct '07

25 Oct '07

Here is another nice post to read. http://blogs.netapp.com/dave/2007/09/netapp-sues-sun.html ************************************************************************ Glenn Marsh Lattice Semiconductor Corporation Senior Unix Systems Administrator 5555 NE Moore Court CAD Engineering Hillsboro, Oregon 97124 glenn.marsh(a)latticesemi.com 503-268-8000 503-268-8136 phone - 503-268-8459 fax ************************************************************************

1 0

Head upgrade 3020 to 3040
by Darish Rajanayagam 25 Oct '07

25 Oct '07

Greeting Toasters, We will soon be upgrading our FAS3020 filer to a FAS3040. The two main protocols the filer is used for is NFS and ISCSI. I am concerned of the implications this upgrade will have on the iscsi network. Has anyone done this type of migration and can share their experience with me? Will upgrading the head unit impact iscsi iqns, lun serial numbers etc? Thanks, Darish.

2 1

Re: WAFL metadata files
by April Jenner 23 Oct '07

23 Oct '07

Hello All: There are a couple of possibilities on this one. Data ONTAP GX can handles "lots" of objects very fast. Data ONTAP GX would fix this problem and remove all the limitations but a lot of people aren't ready for GX yet. (Sabastian might consider it) "Lots" is very subjective but the original case of using the "ls" command and taking a coffee break is typical of a case where the directory structure is just too large to fit into memory. Without more information, none of use can be sure that is really the problem. (We'd have to see statistics and look at lots of factors). If tanyone needs to access millions of files in a single directory and doesn't want to move to GX, then working with NetApp support to change the directory structure is the best case scenario. You can hopefully get the performance back with small tweaks. "Metadata" is sounding like a subjective term as well. There is no evidence that the metadata is a problem. The directory file is probably the problem (The directory file is a special file that has inode numbers and maps those numbers to names. It has to be read into system memory to send the information back for an "ls") Just my .02 cents. --April ----- Original Message ---- From: Blake Golliher <thelastman(a)gmail.com> To: Peter D. Gray <pdg(a)uow.edu.au> Cc: toasters(a)mathworks.com Sent: Monday, October 22, 2007 6:26:56 PM Subject: Re: WAFL metadata files I'd argue that this is general file system issue, not so much a wafl issue. I don't think wafl is particularly slow at this workload either, they do far better then most other nas gear I've used for this workload. There are trickier things out there, like bluearc has some preloaded cache for meta data to help speed it along, but that's just fixing the problem by tossing it all in memory. If you compare a file system operation to file system operation between netapp and bluearc I'm sure you'd fine similar performance issues for a directory with millions of objects. But I do hope some of those wafl guys can figure out a way to make lots of objects in a file system faster. It can be a huge pain. -Blake On 10/22/07, Peter D. Gray <pdg(a)uow.edu.au> wrote: > On Mon, Oct 22, 2007 at 12:55:48PM -0700, Blake Golliher wrote: > > I have to deal with millions of objects in filesystems, I highly > > recommend subdirectories. look at your nfs_hist output. First do > > nfs_hist -z. Then count to 30 and run nfs_hist again. It's a > > histogram of all nfs ops, and how long they took in milisecond > > buckets. I'd bet lookup is taking a very long time. When dealing > > with a large number of objects, sensible directory structures are key. > > > > Yes, but to be fair, this is a weakness in the wafl filesystem. > You cannot have everything, and wafl has made a trade off > in the way it stores file metadata that makes it slow to > handle large number of files in a directory. > > I am not sure if netapp is planning any enhancements in this area > or even what would be possible. > > Anybody care to comment? > > Regards, > pdg > > -- > > See mail headers for contact information. > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

disk busy 100%
by No More Linux! 23 Oct '07

23 Oct '07

we see this alot on one of our 3050's, the disks are 144gb 10k FCAL, we are very concerned: CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 33% 1633 14262 1967 2934 5948 0 0 5 99% 33% : 100% 40% 2036 13033 1799 12622 5279 0 0 5 99% 27% D 100% 58% 3800 16660 2534 13262 24247 0 0 5 99% 100% : 100% 40% 3271 17156 2268 10978 18927 0 0 5 100% 100% : 100% 30% 1217 9699 1802 7390 24154 0 0 5 99% 100% : 100% 22% 2318 571 2020 8697 21873 0 0 5 93% 100% : 100% 20% 1428 706 2014 7663 21820 0 0 5 94% 100% : 100% 63% 2728 57180 3438 7852 19920 0 0 5 100% 100% : 100% 76% 2787 30640 17043 44909 38679 0 0 5 99% 77% D 100% 72% 1995 20426 20208 41305 35765 0 0 5 98% 100% : 100% 68% 2049 19219 22977 43481 36810 0 0 5 98% 100% : 100% 66% 2234 23097 20839 39816 38096 0 0 5 98% 100% : 100% 63% 2352 23897 27837 35960 16489 0 0 5 99% 55% : 100% 54% 2478 23635 30499 36404 0 0 0 5 99% 0% - 100% 64% 1644 20728 7715 33592 34764 0 0 5 99% 78% D 100% 46% 2901 15620 2120 15486 35537 0 0 5 99% 100% : 100% 42% 3209 13807 1929 18263 34560 0 0 5 99% 100% : 100% 39% 1118 15173 2115 17007 34335 0 0 5 99% 100% : 100% 37% 1111 15072 1830 3434 10154 0 0 5 99% 43% : 100% 24% 1215 14888 1678 1331 0 0 0 5 99% 0% - 100% what could be causing this and how can we alleviate it?

5 6

Quick question re upgrade from Ontap 6.5.6 to 7.2.3
by Bryano 23 Oct '07

23 Oct '07

I have just gone through the upgrade guide and drawn up my plan of attack so to speak however it does not state how long the wafl conversion will take (I appreciate this is hard to gauge) and if you have to wait for the conversion to finish before you can create new aggregates and flex volumes and start migrating data in to them from existing trad vols - can anyone advise? Thanks -- View this message in context: http://www.nabble.com/Quick-question-re-upgrade-from-Ontap-6.5.6-to-7.2.3-t… Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters