toasters

toasters@lists.teaparty.net

13531 discussions

RE: Changing a LUN type
by Page, Jeremy 10 Feb '10

10 Feb '10

It can be pretty signifigant, it's not as well documented as VMDK misalignment but I'd expect similar numbers. It looks like the Solaris configuration shouldn't be an issue, it's got a larger offset but still aligned the same way as an AIX LUN. ________________________________ From: MRWILLIS(a)UP.COM [mailto:MRWILLIS@UP.COM] Sent: Wednesday, February 03, 2010 10:49 PM To: Roach, Steven; Page, Jeremy; toasters Subject: Re: Changing a LUN type Anyone ever get an IO performance delta on the misalignment created between the file system and the LUN? I suppose it would depend on the amount of IO, but just curious. Thanks. ________________________________ From: "Roach, Steven" [Steven.Roach(a)netapp.com] Sent: 02/03/2010 10:07 PM EST To: "Page, Jeremy" <jeremy.page(a)gilbarco.com>; <toasters(a)mathworks.com> Subject: Re: Changing a LUN type Jeremy, The LUN type setup up characteristics for that LUN like On-Disk Layout, while this may be working for you, you might not have optimal performance. Once it is created, I don't think you can change the LUN type, you would have to create a new one (same size) with the correct LUN type and copy over the data. On 2/3/10 9:22 PM, "Page, Jeremy" <jeremy.page(a)gilbarco.com> wrote: I am probably missing something simple but I have an AIX system running off a LUN that's configured for a Solaris box. I have two questions - *What's the impact? Are they essentially the same or is there a difference between the two that's going to cause me grief *How do I change it? Any suggestions would be much appreciated. Please be advised that this email may contain confidential information. If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by email by replying to the sender and by telephone (call us collect at +1 202-828-0850) and delete this message and any attachments. Thank you in advance for your cooperation and assistance. In addition, Danaher and its subsidiaries disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement or any amendment thereto; provided that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email. ** This message and any attachments contain information from Union Pacific which may be confidential and/or privileged. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited by law. If you receive this message in error, please contact the sender immediately and delete the message and any attachments. ** Please be advised that this email may contain confidential information. If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by email by replying to the sender and by telephone (call us collect at +1 202-828-0850) and delete this message and any attachments. Thank you in advance for your cooperation and assistance. In addition, Danaher and its subsidiaries disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement or any amendment thereto; provided that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email.

1 0

Changing a LUN type
by Page, Jeremy 04 Feb '10

04 Feb '10

I am probably missing something simple but I have an AIX system running off a LUN that's configured for a Solaris box. I have two questions - *What's the impact? Are they essentially the same or is there a difference between the two that's going to cause me grief *How do I change it? Any suggestions would be much appreciated. Please be advised that this email may contain confidential information. If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by email by replying to the sender and by telephone (call us collect at +1 202-828-0850) and delete this message and any attachments. Thank you in advance for your cooperation and assistance. In addition, Danaher and its subsidiaries disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement or any amendment thereto; provided that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email.

2 1

Ops Mgr/DFM Monitoring of CPs
by Fred Grieco 23 Jan '10

23 Jan '10

Does anyone know a good way to monitor Consistency Points and disk utilization in newer versions of OpsMgr? Or another way? These correspond to "CP ty" and "Disk Util" on a sysstat -x output. In previous versions of DFM and Management console (3.6 and 2.2), Management console had View under the logical views called "storage system - CP Details." It's not listed anymore in version 3.8. This was very handy, as high back to back CPs corresponded to performance issues we had. TIA, Fred

4 4

sdcli dll error on Windows 2008 R2
by Carl Howell 19 Jan '10

19 Jan '10

If I try to run sdcli with SnapDrive 6.2 on Windows 2008 R2, I get "Loading SnapDriveRes.dll failed." Anybody else seen this? Thanks, Carl Howell Systems Engineer Information Technology Services University of West Florida

1 0

RE: Autosupport post - soo_write Failure
by Willeke, Jochen 18 Jan '10

18 Jan '10

Hi, tested myself, the deletion did not solve the problem, sadly.... Searching for other solutions besides rebooting the system. Regards Jochen -----Original Message----- From: Willeke, Jochen Sent: Monday, January 11, 2010 4:16 PM To: toasters(a)mathworks.com Subject: Autosupport post - soo_write Failure Hey Toasters, I do have a question regarding a problem with autosupport from one filer. We use the post-method, due to mail-delivery-restrictions. Since some days we do see error-msg like these: [filername: asup.log.socket.err.post:error]: soo_write failed in autosupport post due to the error - Resource temporarily unavailable. Sadly this seems to be related to a bug, which needs a reboot which cannot be done in the next days. I found out that there are two files under /etc/log/autosupport which have the ending .post. Those files are the directly from the point in time when autosupport stopped working and start spaming the messages-file. My question is, are those files the blocking point, and can the deletion of the files solve this issue?? The files do have size 0kb and now content. Anybody ever come across this? Cheers and thanks in advance Jochen -- WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Gesch�ftsf�hrer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. J�rgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enth�lt vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt�mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

2 4

Re: SnapMirror for data migration within the same controller
by André M. Clark 15 Jan '10

15 Jan '10

So after trying a wide variety of things there was nothing that I could do to prevent snapmirror from using the loopback adapter for in controller snapmirrors. I really wish that 7G had the volume move command like GX. Thanks anyway for the suggestions. AC On 1/15/10 1:38 AM, "Nils Vogels" <bacardicoke(a)gmail.com> wrote: > What you could try (and I don't know if it works) is specify the > snapmirror destination as the interface IP of one of your ethernet > interfaces ? > > Greetings, > > Nils > > On Fri, Jan 15, 2010 at 01:15, André M. Clark <Andre.Clark(a)earthlink.net> > wrote: >> Romeo, >> >> I need to keep snapshots so vol copy is out. Also, it will still use the >> internal loopback adapter. What I am trying to do is see if I can get >> faster throughput than the loopback adapter within the same controller. I >> will definitely let you know what the final outcome is. Thanks for the >> advice. >> >> André >> >> >> On 1/14/10 6:12 AM, "Romeo Theriault" <romeotheriault(a)gmail.com> wrote: >> >> If you do not need snapshots then maybe vol copy will do what you need. >> >> vol copy can copy snapshots as well. From 7.2.6.1 vol man page, >> >> vol copy start [ -S | -s snapshot ] source destination >> >> Copies all data, including snapshots, from one vol- >> ume to another. If the -S flag is used, the com- >> mand copies all snapshots in the source volume to >> the destination volume. To specify a particular >> snapshot to copy, use the -s flag followed by the >> name of the snapshot. >> >> >> Though I'm not sure this would be any faster than a snapmirror. >> >> Andre, I'd be interested to hear what your outcome of this eventually is. >> >> Thanks, >> > >

1 0

SnapMirror for data migration within the same controller
by André M. Clark 15 Jan '10

15 Jan '10

Is there a way to perform a SnapMirror migration within the same controller without using the internal loopback adapter (~40Mbs). I have a situation where I need to migrate close to 6TB of data (multiple volumes) off of older smaller drives to larger 300G drives. Ideally I'd like to use SnapMirror multiplexing, however, I'm not sure that, even with direct connection between interfaces, this would even work (I'm thinking that the internal loopback would still take over). I don't want to do multiple snapmirrors (orig. controller> temp controller> orig. controller) but this may be my only path in order to get the speed that I need for the transfer. Any ideas?

5 6

RE: Does anyone know if the dedup is across the entire aggr or just the volume in 7.3.x?
by Page, Jeremy 12 Jan '10

12 Jan '10

We're at vSphere, it does support 64 (and that's what the NetApp tool recommends). It's probably over ambitious to get one vol per service but maybe one per customer (Engineering, Finance etc). That should keep the similar data together. We too are seeing 40% or so on our VM's. It looks like Aggr level dedup will be out with 8. ________________________________ From: Glenn Walker [mailto:gwalker@aetas.org] Sent: Saturday, December 19, 2009 2:32 PM To: Page, Jeremy Cc: toasters(a)mathworks.com Subject: Re: Does anyone know if the dedup is across the entire aggr or just the volume in 7.3.x? It isn't global dedupe, like Data Domain - I think that was one of the big benefits of the attempted purchase of DD. That said, it's still pretty good - even if only at the volume level. We're seeing tremendous savings of storage and no real performance impact. We've got VMWare over NFS in our environment and on average we're seeing about 45% dedupe rates - pretty impressive given the fact that the application files, temp files, and page files are all co-termed on the same VMDKs. At last count, we've deduped 20TB of storage. Keep in mind, volume per service may prove difficult as VMWare 3.5.X has a limit of 32 NFS-based datastores per server: if you run big clusters like we do, you'll probably run out of datastores if each volume is a separate service. VSphere is rumored to raise the limit to 64 I think. Glenn On Mon, Dec 7, 2009 at 1:39 PM, Page, Jeremy <jeremy.page(a)gilbarco.com> wrote: Does anyone know if the dedup is across the entire aggr or just the volume in 7.3.x? I'd like to break up my VMware environment so we have a volume per service (so SQL Warehouse volume, Call Center etc). This would be nice because we could delegate the rights to them, move them around if specific apps required more IO and aid in troubleshooting. The question I have is will this kill our dedup percentages? Please be advised that this email may contain confidential information. If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by email by replying to the sender and by telephone (call us collect at +1 202-828-0850) and delete this message and any attachments. Thank you in advance for your cooperation and assistance. In addition, Danaher and its subsidiaries disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement or any amendment thereto; provided that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email. Please be advised that this email may contain confidential information. If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by email by replying to the sender and by telephone (call us collect at +1 202-828-0850) and delete this message and any attachments. Thank you in advance for your cooperation and assistance. In addition, Danaher and its subsidiaries disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement or any amendment thereto; provided that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email.

7 7

Autosupport post - soo_write Failure
by Willeke, Jochen 11 Jan '10

11 Jan '10

Hey Toasters, I do have a question regarding a problem with autosupport from one filer. We use the post-method, due to mail-delivery-restrictions. Since some days we do see error-msg like these: [filername: asup.log.socket.err.post:error]: soo_write failed in autosupport post due to the error - Resource temporarily unavailable. Sadly this seems to be related to a bug, which needs a reboot which cannot be done in the next days. I found out that there are two files under /etc/log/autosupport which have the ending .post. Those files are the directly from the point in time when autosupport stopped working and start spaming the messages-file. My question is, are those files the blocking point, and can the deletion of the files solve this issue?? The files do have size 0kb and now content. Anybody ever come across this? Cheers and thanks in advance Jochen -- WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Gesch�ftsf�hrer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. J�rgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enth�lt vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt�mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

S Family/Storevault and Windows 2008
by Michael Schipp 10 Jan '10

10 Jan '10

Hi all, Has there been any development with this product? Last I found was that there is no support for Windows 2008 native mode AD and that there will never be. Is this still correct? Thanks

1 0

Re: Question about moving a shelf that is used for vmware iscsi datastores between filers
by Romeo Theriault 07 Jan '10

07 Jan '10

For future reference for others on the mailing list who might try a similar procedure in the future I also received a useful response from Matt Hallmark which points out that you also need to keep the target portal group tags the same for *nix/esx hosts. On Thu, Jan 7, 2010 at 8:39 AM, Matt Hallmark <matt(a)cosmictoaster.com>wrote: > You will run into trouble, with all *nix/esx hosts if the iSCSI Target > Portal Group tag(s) change. > > goliath> iscsi tpgroup show > TPGTag Name Member Interfaces > 1 e0a_old (none) > 1004 e3a_default e3a > 1005 e3b_default e3b > 2000 VIF_e0_AC_default VIF_e0_AC > 2001 VIF_e0_BD_default VIF_e0_BD > > Those are changable, but would require an iSCSI maintenance window to > complete. > > Matt Romeo

1 0

Re: Question about moving a shelf that is used for vmware iscsi datastores between filers
by Romeo Theriault 07 Jan '10

07 Jan '10

> According to this you should be fine: > > http://www.vmware.com/files/pdf/vmfs_resig.pdf > Great, this is exactly what I was looking for. This clearly explains how vmware determines which datastore is which: When you define a new VMFS volume on a block device, VMFS calculates a > volume signature and writes it in the header of the VMFS volume. This volume > signature is a combination of the LUN number, as seen by that ESX host, and > the disk serial number as the storage array reports it to the ESX host. > VMFS volume signature = LUN number + disk serial number > So it seems that if I keep the lun serial numbers the same across the move, and remap the luns to the same lun id's vmware will recognize the datastores as the original datastores. Thanks for the help everyone, -- Romeo Theriault System Administrator Information Technology Services

1 0

Issues mounting snapshot
by Raj Patel 07 Jan '10

07 Jan '10

Hi, Simple problem - I have a SQL server (Windows 2008, 64 bit, SQL 2008, Snapdrive 6.1 & snapmanager sql 5.0.0.38 (both 64bit) Snapshots work fine - however the dbcc check fails when it attempts to mount the snapshot for a verification. Now - I am able to mount the snapshot on a Windows 2003, 32 bit box running Snapdrive 6.1 so I'm fairly certain its not a volume space issue. The actual error I get is 'A timeout of 120 secs elapsed while waiting for volume arrival notification from the operating system' - this happens when I use the SD GUI to manually mount the snapshot. The console shows pretty much the same sort of error if I watch it while running the GUI mount. We have this working fine on other SQL servers and its just started happening on this box. Any ideas ? Our DBA's are starting to wonder if the aggravation of troubleshooting SM SQL / SD issues is worth the convenience of instant snapshots. At least with traditional backups they know where they stand. Thanks in advance, Raj.

3 4

Question about moving a shelf that is used for vmware iscsi datastores between filers
by Romeo Theriault 07 Jan '10

07 Jan '10

Sorry if this post is a bit off-topic as it may relate more to vmware than netapp but I'm hoping it relates enough to netapp that it's ok. Scenario is: I have two netapp filers and both are being used solely for a single vmware cluster which has access to both filers for use as iscsi (and only iscsi) datastores. I need to move one shelf (aggregate) on one of the filers to the other filer. I'm comfortable with the netapp side of things but am unsure if anything special needs to happen on the vmware side for it to recognize the datastores now that they are on the other head. I've simulated a test by snapmirroring a test datastore to the other head, unmapping the old lun, changing the lun serial of the new lun to the old luns, mapping the new lun back to the same lun id that the old lun was using and vmware was content with this (i.e. it saw the datastore as the original with all it's content). Will moving a shelf with several datastores to the other head work as well? Thanks for any help. -- Romeo Theriault System Administrator Information Technology Services

3 2

RE: Fixing corrupted NTFS LUN's
by Suresh Rajagopalan 23 Dec '09

23 Dec '09

The LUN's are corrupt from the perspective of the HBA itself (any HBA), Emulex HBAanywhere reports the LUN size to be "Not available" and block size to be "Not available". Restoring from backup was the only workaround. I've not encountered a corruption like this kind before, 6 LUN's got lost in this manner. Suresh From: Darren Sykes [mailto:Darren.Sykes@csr.com] Sent: Wednesday, December 23, 2009 2:51 AM To: Michael Schipp; Suresh Rajagopalan; toasters(a)mathworks.com Subject: RE: Fixing corrupted NTFS LUN's Hmmm, maybe I hadn't thought that one though - you're right in that you'd need an OS which saw the LUN before attempting to recover the partitions on it - assuming you're booting from iSCSI? If you're not, then my original advice stands. However, that's not to say you couldn't boot into Windows (by whatever means - another physical disk if necessary) then follow my advice re: FDISK /fixmbr or alternate commercial product. I wouldn't be too hopeful of Linux fixing it - I'd try Windows tools first as I'd think they'd have a better chance of recovering a Windows file system. The other option that we've followed in the past is recovering the partition table from a snapshot prior to the corruption, assuming you have one. We booted Linux, mounted the LUNS and literally did a direct copy of the MBR. From: Michael Schipp [mailto:mschipp@asi.com.au] Sent: 23 December 2009 10:21 To: Darren Sykes; Suresh Rajagopalan; toasters(a)mathworks.com Subject: RE: Fixing corrupted NTFS LUN's If the disks (read LUNs) do not appear to windows as a disk then a Windows based disk recover tool will also not see the drive to recover - e.g. for these to work it would need to see a disk drive and see no or corrupt file/partition system to fix it. Suggest you look at an Linux boot CD/DVD that has iSCSI support to see if it can mount it as a NTFS volume. (follow Darren Sykes advise so as not to break it further) A quick google for a tool to recover LUNs does not look very promising - good luck and please post back if you do find something. From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Darren Sykes Sent: Wednesday, 23 December 2009 8:51 PM To: Suresh Rajagopalan; toasters(a)mathworks.com Subject: RE: Fixing corrupted NTFS LUN's You'd think the LUNs are fine (and the fact they're actually just a file on the Netapp won't matter as it's a file system issue). I assume something like fdisk /fixmbr or the recovery console were no use to you (disclaimer: work on a flexclone or at least make sure you have a snapshot before trying that!)? There are commercial products (such as http://www.partition-recovery.com/) but I can't vouch for their effectiveness. From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Suresh Rajagopalan Sent: 23 December 2009 07:26 To: toasters(a)mathworks.com Subject: Fixing corrupted NTFS LUN's Following up on my post, we had HBA and path issues causing LUN corruption on several NTFS LUN's on the original host. As a result, we cannot even see a partition table on the LUN's. Are there any utilities to manipulate or repair NTFS LUN files (which are visible as flat files via the CIFS share to the volume)? Thanks Suresh From: Suresh Rajagopalan Sent: Tuesday, December 22, 2009 7:38 PM To: toasters(a)mathworks.com Subject: Cannot see LUNs after server move We had a bunch of NTFS LUN's on a server that crashed (2003x64/Snapdrive 4.2.1). We are trying to move the LUNS to another server(Snapdrive 6/Win2k3x64). To do this we did the following: 1) Unmap old initiator from lun 2) Zone new server to the Netapp filer. 3) Try to use connect disk from new server to the lun 4) This gives a error saying drive notification timeout To debug this more, I opened Disk Management. The disks do not show up there either. But they show up as LUNs under Device manager. Why do the LUN's show up in Device Manager/Disk drives but not in Disk management? Thanks Suresh To report this email as spam click here <https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==> . Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom ************************************************************************ ************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************ ************

1 0

Re: Filers and anti virus software benefit
by Joel Krajden 19 Dec '09

19 Dec '09

Thank you for the feedback Glenn. We have decided that the overhead does is not worth the benefits. We have hundred of students compiling executables on a daily basis which would end up being scanned. Joel Quoting Glenn Walker <gwalker(a)aetas.org>: > We use it extensively, but I swear I think it's only added overhead. > > There are lots of issues wrt size of container, type of data, etc. In many > cases, the files need to be excluded (PST for example). Our particular > environment has virus scanning on laptops, servers, mail gateways, mail > servers, etc, so there seems to be little added benefit (as you mentioned, > zero day infections will not be stopped). That said, while we employ > several devices to perform this function (3 per cluster for home\shared - we > do _not_ scan application data), there seems to be no performance impact. > It's really an insurance policy, which is very cheap compared to how much > money is spent on all other infrastructure combined. But actually > beneficial? I don't really think so... > > Glenn > > On Tue, Dec 8, 2009 at 3:19 PM, Joel Krajden <joelk(a)encs.concordia.ca>wrote: > >> Most of our clients (1000) accessing the filers for home directory shares >> are protected with an anti virus tool that scans a file on opening. There >> are unmanaged clients which have access to the filers and they may or may >> not be protected with an anti virus that is up to date, but they only risk >> infecting their own files in general. >> >> Is there any real benefit to having virus checking implemented on the filer >> as well. Given that zero day infections will not be stopped, the additional >> cost of dedicated virus scanners and software licensing is significant, the >> performance hit with thousands of users will be high; what have other filer >> administrators used as arguments for or against using these products. >> >> Any experience from administrators where the product has been of value? >> >> >> Joel >> >> > -- | Joel Krajden | Rm: EV-7105, Tel: 514 848-2424 3052 | | Core Services Manager | | | Engineering & | Email: joelk(a)encs.concordia.ca | | Computer Science | www.encs.concordia.ca/~staffcs/joelk | | Concordia University | In a circus, the clowns are supposed | | Montreal, Canada | to make you laugh, not cry. |

1 0

Re:
by Joel Krajden 10 Dec '09

10 Dec '09

You are correct and anyways migration would only work on the same filer. Sorry for suggesting a dead end. Joel Michael Barrow wrote: > 'snapmirror migrate' is only applicable for an existing SnapMirror > relationship. In this particular instance, the SnapMirror relationship > has effectively been torn down and a new relationship must be built. > > On Wed, Dec 9, 2009 at 5:56 AM, Joel Krajden <joelk(a)encs.concordia.ca > <mailto:joelk@encs.concordia.ca>> wrote: > > You might want to look at > > Solution ID: kb40272 > Last updated: 30 SEP 2009 > > Sample procedure using ' snapmirror migrate ' that avoids remounting > in a NFS environment > > > > Joel > > > John Stoffel wrote: > > "Fox," == Fox, Adam <Adam.Fox(a)netapp.com > <mailto:Adam.Fox@netapp.com>> writes: > > > Fox> VSM (and therefore SM2T) will preserve inodes, but it will > be up > Fox> to you to preserve the FSID of the original volume on east. If > Fox> you go into priv set advanced, you will find 'vol > read_fsid' and > Fox> 'vol rewrite_fsid' which can accomplish this. Be aware that > Fox> Rewriting the fsid requires the volume to be restricted and you > Fox> will need to rewrite the original one first to something > totally > Fox> different. FSIDs must be unique not only within a > controller but > Fox> within an HA-pair if you want failover to work properly. > > Ouch! Sounds funky and possibly trouble. > > While I don't have any common snapshots between west> and east> > filers, I do have some common snapshots on each filer for other > snapmirror relationships, since west> is also snapmirroring tools to > two other sites. > > Would it be possible to do the following: > > 1) quiece all snapmirrors of tools from west> to south> and > north> > - will this leave me with two snap shots for the west->north > pair, or will snapmirror automatically cleanup when done? > > 2) comment out tools entries on all filers: west, south, > north & > east. > > 3) on west> (my source), do 'snap rename > north(####)_tools.1234 \ > east(######)_tools.1234' > 4) on east> snapmirror resynnc tools > > - wait until competed > > 5) on west> snap rename east(######)_tools.1234 \ > north(######)_tools.1234 > 6) do snap update tools on east, north, south to make sure they > can all update again. > > 7) re-enable snapmirror.conf entries for tools. > > Or I wonder if I need to interrupt the west->north snapmirror in > progress, and make sure I only rename the more recent snapshot, so > that I still have valid snapshots between west->north, and now a > second one to re-purpose as my west->east pair base? > > Any hope? > Thanks, > John > > > > Fox> While these commands are perfectly safe when used properly, > they are > Fox> guns so point them away from you (i.e. know what you're > doing before you > Fox> it or you could have a disruption you don't want). > > Fox> -- Adam Fox > Fox> Systems Engineer > Fox> adamfox(a)netapp.com <mailto:adamfox@netapp.com> > > > Fox,> -----Original Message----- > Fox,> From: John Stoffel [mailto:john.stoffel@taec.toshiba.com > <mailto:john.stoffel@taec.toshiba.com>] Fox,> Sent: Monday, > December 07, 2009 5:50 PM > Fox,> To: toasters(a)mathworks.com <mailto:toasters@mathworks.com> > Fox,> Subject: Redoing snapmirror to a destination > > > Fox,> Guys, > > Fox,> Do to stupidity on my part, I managed to accidently delete > a snapshot > Fox,> on the source side of a snapmirror pair, so that > snapmirror can't > Fox,> continue. It's not critical, it's just our tools area, > which isn't > Fox,> updated frequently. > > Fox,> So now I want to re-snapmirror, but I want to limit the > downtime of > Fox,> the clients on the destination side as much as possible > when I switch > Fox,> them to the new re-snapmirrored volume. > > Fox,> Currently, my clients mount east:/vol/tools, so what I'd > like to do > Fox,> is: > > west> snapmirror store tools rst0a,rst1a > > east> vol create tools .... > east> vol restrict tools > east> snapmirror retrieve tools_new rst0a,rst1a > > Fox,> Now for the tricky part: > > east> nfs off > east> vol rename tools tools_old > east> vol rename tools_new tools > east> nfs on > east> exportfs -a -v > > Fox,> so that all my clients see (on a read-only volume) is a > quick outage > Fox,> or pause in NFS traffic, then they just continue on using > tools and > Fox,> such as usual. > > Fox,> Or will I be forced to reboot all of my client machines > one by one? > Fox,> Which will be truly truly truly painful... > > Fox,> The general snapmirror update and cleanup of the old volume is > Fox,> trivial. It's limiting the outage to my clients that I > worry about. > Fox,> Thanks, > Fox,> John > Fox,> John Stoffel - Senior Staff Systems Administrator - > System LSI Group > Fox,> Toshiba America Electronic Components, Inc. - > Fox,> http://www.toshiba.com/taec > Fox,> john.stoffel(a)taec.toshiba.com > <mailto:john.stoffel@taec.toshiba.com> - 508-486-1087 > > > > > > > > -- > | Joel Krajden | Rm: EV-7105, Tel: 514 848-2424 3052 | > | Core Technologies Mgr | | > | Engineering & | Email: joelk(a)encs.concordia.ca > <mailto:joelk@encs.concordia.ca> | > | Computer Science | | > | Concordia University | In a circus, the clowns are supposed | > | Montreal, Canada | to make you laugh, not cry. | > > > > > -- > Michael Barrow > michael at barrow dot me > -- | Joel Krajden | Rm: EV-7105, Tel: 514 848-2424 3052 | | Core Technologies Mgr | | | Engineering & | Email: joelk(a)encs.concordia.ca | | Computer Science | | | Concordia University | In a circus, the clowns are supposed | | Montreal, Canada | to make you laugh, not cry. |

1 0

Netapp blog
by Patrick van Helden 10 Dec '09

10 Dec '09

For some time now I have been adding items regarding issues and fixes with Netapp systems into a blog type format for myself. I have posted this blog online so everyone can enjoy! http://netappfas.blogspot.com/ netappfas.blogspot.com For now I have only migrated the old articles but am planning to add new ones regularly. -- View this message in context: http://old.nabble.com/Netapp-blog-tp26727926p26727926.html Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.

1 0

Re: migrating a volume with snapmirror
by Joel Krajden 09 Dec '09

09 Dec '09

Wonder if you can put the source volume into restricted mode first and migrate will the open read or write simply continue if the FSID are identical. It should but I have never tried it. Joel Ed Wilts wrote: > On Wed, Dec 9, 2009 at 7:56 AM, Joel Krajden <joelk(a)encs.concordia.ca > <mailto:joelk@encs.concordia.ca>> wrote: > > You might want to look at > > Solution ID: kb40272 > Last updated: 30 SEP 2009 > > Sample procedure using ' snapmirror migrate ' that avoids remounting > in a NFS environment > > > Unfortunately, it only works if all NFS access has stopped. If you > have just one host out there that you forgot about that is doing I/O to > the volume, it's remount time and users grumbling about stale handles. > > .../Ed > > Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE > ewilts(a)ewilts.org <mailto:ewilts@ewilts.org> > Contact Me Linkedin <http://www.linkedin.com/in/ewilts> > > -- | Joel Krajden | Rm: EV-7105, Tel: 514 848-2424 3052 | | Core Technologies Mgr | | | Engineering & | Email: joelk(a)encs.concordia.ca | | Computer Science | | | Concordia University | In a circus, the clowns are supposed | | Montreal, Canada | to make you laugh, not cry. |

2 1

Redoing snapmirror to a destination
by John Stoffel 09 Dec '09

09 Dec '09

Guys, Do to stupidity on my part, I managed to accidently delete a snapshot on the source side of a snapmirror pair, so that snapmirror can't continue. It's not critical, it's just our tools area, which isn't updated frequently. So now I want to re-snapmirror, but I want to limit the downtime of the clients on the destination side as much as possible when I switch them to the new re-snapmirrored volume. Currently, my clients mount east:/vol/tools, so what I'd like to do is: west> snapmirror store tools rst0a,rst1a east> vol create tools .... east> vol restrict tools east> snapmirror retrieve tools_new rst0a,rst1a Now for the tricky part: east> nfs off east> vol rename tools tools_old east> vol rename tools_new tools east> nfs on east> exportfs -a -v so that all my clients see (on a read-only volume) is a quick outage or pause in NFS traffic, then they just continue on using tools and such as usual. Or will I be forced to reboot all of my client machines one by one? Which will be truly truly truly painful... The general snapmirror update and cleanup of the old volume is trivial. It's limiting the outage to my clients that I worry about. Thanks, John John Stoffel - Senior Staff Systems Administrator - System LSI Group Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec john.stoffel(a)taec.toshiba.com - 508-486-1087

7 7

Filers and anti virus software benefit
by Joel Krajden 09 Dec '09

09 Dec '09

Most of our clients (1000) accessing the filers for home directory shares are protected with an anti virus tool that scans a file on opening. There are unmanaged clients which have access to the filers and they may or may not be protected with an anti virus that is up to date, but they only risk infecting their own files in general. Is there any real benefit to having virus checking implemented on the filer as well. Given that zero day infections will not be stopped, the additional cost of dedicated virus scanners and software licensing is significant, the performance hit with thousands of users will be high; what have other filer administrators used as arguments for or against using these products. Any experience from administrators where the product has been of value? Joel

3 2

Covert IBM N Series to NetApp Solution
by ifstat 08 Dec '09

08 Dec '09

Ok, I'm sure this has been covered somewhere during the years, and I'm well aware that this is taboo in terms of the NetApp IBM partnership, but I would like to attempt or rather investigate the following: 1. Reconfigure an IBM N3700 to FAS270, initializing the disks and deploying NetApp Data ONTAP, does anyone know if the underlying hardware (firmware) will accept this. 2. Add NetApp disks and shelves to the system, ie grow with NetApp directly and not neccessarily IBM. Anyone attempted this your info would be helpful. We are not concerned about the support agreements, financially NetApp is cheaper and easier, so in this day and age it all about the MONEY:). -- View this message in context: http://old.nabble.com/Covert-IBM-N-Series-to-NetApp-Solution-tp26690019p266… Sent from the Network Appliance - Toasters mailing list archive at Nabble.com.

3 2

Re: Redoing snapmirror to a destination
by John.Stoffel＠taec.toshiba.com 07 Dec '09

07 Dec '09

I just double checked and I don't have any common snapshots unfortunately. Time to file a req with netapp to make 'snap delete ...' Be less permissive in deleting snapshots used for any snap* relationships without a force switch of some sort... Thanks, John stoffel ----- Original Message ----- From: Michael Barrow [michael(a)barrow.me] Sent: 12/07/2009 03:02 PM PST To: John Stoffel Cc: <toasters(a)mathworks.com> Subject: Re: Redoing snapmirror to a destination Do you not have *any* Snapshots in common between the source and destination? If you have common Snapshots, you can issue a 'snapmirror resync' on the destination and the relationship will be established. This is better than swapping the volume because you'll likely get stale file handles. -- Michael Barrow michael at barrow dot me On Dec 7, 2009, at 2:50 PM, John Stoffel wrote: > > Guys, > > Do to stupidity on my part, I managed to accidently delete a snapshot > on the source side of a snapmirror pair, so that snapmirror can't > continue. It's not critical, it's just our tools area, which isn't > updated frequently. > > So now I want to re-snapmirror, but I want to limit the downtime of > the clients on the destination side as much as possible when I switch > them to the new re-snapmirrored volume. > > Currently, my clients mount east:/vol/tools, so what I'd like to do > is: > > west> snapmirror store tools rst0a,rst1a > > east> vol create tools .... > east> vol restrict tools > east> snapmirror retrieve tools_new rst0a,rst1a > > Now for the tricky part: > > east> nfs off > east> vol rename tools tools_old > east> vol rename tools_new tools > east> nfs on > east> exportfs -a -v > > so that all my clients see (on a read-only volume) is a quick outage > or pause in NFS traffic, then they just continue on using tools and > such as usual. > > Or will I be forced to reboot all of my client machines one by one? > Which will be truly truly truly painful... > > The general snapmirror update and cleanup of the old volume is > trivial. It's limiting the outage to my clients that I worry about. > > Thanks, > John > John Stoffel - Senior Staff Systems Administrator - System LSI Group > Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec > john.stoffel(a)taec.toshiba.com - 508-486-1087 > > > >

1 0

Re: Redoing snapmirror to a destination
by John.Stoffel＠taec.toshiba.com 07 Dec '09

07 Dec '09

Hmmm fsid is something to keep in mind. I can do a couple of tests vols later to see what happens. Thanks for the feedback all! Thanks, John stoffel ----- Original Message ----- From: Bert Kiers [kiersb(a)xs4all.net] Sent: 12/08/2009 12:34 AM CET To: John Stoffel Cc: toasters(a)mathworks.com Subject: Re: Redoing snapmirror to a destination On Mon, Dec 07, 2009 at 05:50:20PM -0500, John Stoffel wrote: Hi, > so that all my clients see (on a read-only volume) is a quick outage > or pause in NFS traffic, then they just continue on using tools and > such as usual. > Or will I be forced to reboot all of my client machines one by one? > Which will be truly truly truly painful... The trick is to keep the fsid the same. I doubt the steps you outline will do that. Is it possible to tell a filer to use a particular fsid for a volume? (I guess snapmirror does not change inodes, what is also needed here.) Grtnx, -- Bert Kiers XS4ALL UNIX systeembeheerder, suspected terrorist 1984 was not meant as a manual

1 0

Re: Redoing snapmirror to a destination
by John.Stoffel＠taec.toshiba.com 07 Dec '09

07 Dec '09

No common snaps that I know of, but its a good idea. John Thanks, John stoffel ----- Original Message ----- From: "Page, Jeremy" [jeremy.page(a)gilbarco.com] Sent: 12/07/2009 03:04 PM PST To: John Stoffel; <toasters(a)mathworks.com> Subject: RE: Redoing snapmirror to a destination I think you can resynch if there are any common snapshots, did you call Netapp? -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of John Stoffel Sent: Monday, December 07, 2009 5:50 PM To: toasters(a)mathworks.com Subject: Redoing snapmirror to a destination Guys, Do to stupidity on my part, I managed to accidently delete a snapshot on the source side of a snapmirror pair, so that snapmirror can't continue. It's not critical, it's just our tools area, which isn't updated frequently. So now I want to re-snapmirror, but I want to limit the downtime of the clients on the destination side as much as possible when I switch them to the new re-snapmirrored volume. Currently, my clients mount east:/vol/tools, so what I'd like to do is: west> snapmirror store tools rst0a,rst1a east> vol create tools .... east> vol restrict tools east> snapmirror retrieve tools_new rst0a,rst1a Now for the tricky part: east> nfs off east> vol rename tools tools_old east> vol rename tools_new tools east> nfs on east> exportfs -a -v so that all my clients see (on a read-only volume) is a quick outage or pause in NFS traffic, then they just continue on using tools and such as usual. Or will I be forced to reboot all of my client machines one by one? Which will be truly truly truly painful... The general snapmirror update and cleanup of the old volume is trivial. It's limiting the outage to my clients that I worry about. Thanks, John John Stoffel - Senior Staff Systems Administrator - System LSI Group Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec john.stoffel(a)taec.toshiba.com - 508-486-1087 Please be advised that this email may contain confidential information. If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by email by replying to the sender and by telephone (call us collect at +1 202-828-0850) and delete this message and any attachments. Thank you in advance for your cooperation and assistance. In addition, Danaher and its subsidiaries disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement or any amendment thereto; provided that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email.

1 0

Jump to page:

2026

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