About aborzenkov

aborzenkov · ‎2012-02-07

Just execute “download” once more. Current kernel will be moved to backup and you will be left with two identical versions.

aborzenkov · ‎2012-02-06

As far as know, at least for aggregates it is normal - they remain in redirect status as long as at least one physical redirect had been run.

aborzenkov · ‎2012-02-03

It is possible if you have no qtree in vol1 on FASA. You can use QSM to replicate all non-qtree data. What I am not sure – whether it is possible to revert replication in this case.

aborzenkov · ‎2012-02-02

It depends what happens when client gets packet over 1500 long. if it is able to process it - probably, nothing happens. If it will discard it - communication will simply fail. If it never gets frames over 1500 - everything will work, but why would you enable JF in this case in the first place? The same applies to filer BTW. I am not sure what happens when filer gets oversized frame. Interesting is, our filers (and Cisco switches) do log quite a number of oversized frames although MTU is set to standard everywhere. I still have not got around to really investigate it. Jumbo frames are really too much pain to administer for the little gain you get.

aborzenkov · ‎2012-02-02

I wholeheartedly agree that managing non-NAS NetApp version is needlessly complicated by inability to access /etc for various tasks. As for NFS/CIFS case ... I think you have to draw the line somewhere. If you are managing file server, you are supposed to know how to make directory available and access it later. So any reference to /etc on filer is pretty unambiguous.

aborzenkov · ‎2012-02-01

It is possible that "limited CIFS" allows editing/creation of files but not directories. I think I had the same issue recently with creation of /etc/software. But I believe I was able to copy files into existing /etc/software. As you have NFS license - do not you have system from which you can manage /etc?

aborzenkov · ‎2012-02-01

Well ... usually filer has either NAS license (NFS/CIFS), in which case access to /etc is obviously not an issue; or SAN (iSCSI/FCP) in which case it enables CIFS to the extent sufficient to access /etc and edit files there. Which license do you have?

aborzenkov · ‎2012-02-01

I do not think it makes much sense to waste time on it (except if you are personally interested ☺ ); just open case with NetApp and request disk to be replaced.

aborzenkov · ‎2012-02-01

It was discussed just a couple of days ago and someone posted link to blog which describes how to setup SFTP. Then you can use any GUI/Norton Commander browser to manage files. Let me check … yes, I saved it ☺ http://cosonok.blogspot.com/2012/01/netapp-data-ontap-81-enabling-sftp.html all credits to blog author.

aborzenkov · ‎2012-02-01

I do not think NetApp publishes this information. Why do need to know it?

aborzenkov · ‎2012-02-01

Yes, it is pretty safe. As you are going to edit it under Windows, watch out for line end change (Data ONTAP is using Unix convention, not DOS).

aborzenkov · ‎2012-01-31

No, that's incorrect. igroup is local to each filer. In HA pair filers try to verify that the same LUN is not accidentally mapped to the same ID for the same initiator in different igroups, but that's the only dependency.

aborzenkov · ‎2012-01-31

Yes, something like that. There are really plenty of discussions about what to do on small filers to maximize available space. Just try search

aborzenkov · ‎2012-01-31

NDVM does not work between filers.

aborzenkov · ‎2012-01-31

Assuming that root volume is completely located on internal disks and you intend to retain FAS2040 identity - snapmirror root volume, mark destination as root, shutdown, connect shelves from FAS2040, reassign disks in maintenance mode, boot. You will need to adjust /etc/rc for different controllers (could be done before final snapmirror cutover) and allow some time for testing (network connections etc). As usual, beware LUN serial numbers change, could be quite confusing for VMware. There is nothing special in moving shelves - just connect and reassign disks. I would definitely plan at least couple of hours for it; it also depends on where old and new equipment are located, needed cabling work etc.

aborzenkov · ‎2012-01-31

It depends on target_free_space. If it set so high, that single snapshot exceeds it - yes, it will remove all snapshots. If you set target_free_space to 50% and last remaining snapshot consumes 60% of snap reserve, it will be removed.

aborzenkov · ‎2012-01-31

If you put all disks to one controller you lose high availability. Partner must be up and running to perform takeover and to be up and running it must have at least root volume.

aborzenkov · ‎2012-01-31

New TCP window size takes effect only on new connections. You cannot restart initial transfer. Unfortunately (I wish we could).

aborzenkov · ‎2012-01-30

You interface group is set to LACP. It is impossible to answer whether "settings are correct" without knowing the whole environment; in particular, Jumbo frames have to enabled on switches and communication partners as well. There are contradictory theories about flow control. I did see some strange phenomenon which (in hindsight) could be explained by lack of flow control - disruption of NFS over UDP. Problem went away after we switched to TCP ... which incidentally has own flow control and reliable delivery. So I would enable flow control (again do not forget to enable it on switches too ...) until some evidence that it is causing issues. I do not understand what do you mean under "moving ports between physical switches". Could you elaborate?

aborzenkov · ‎2012-01-30

In your configuration NetApp likely won't be able to access one of Vmware servers (each controller possibly different server). It has nothing to do with NetApp specifically, but simply how TCP/IP communication works. Use different subnets for different adapters.

aborzenkov · ‎2012-01-30

Just a wild guess - may be outdated disk qualification package.

aborzenkov · ‎2012-01-30

It is not possible to restrict space (meaning – prevent snapshot creation if it would exceed allocated space). It is possible to configure NetApp to autodelete snapshots in this case. See “snap autodelete” command.

aborzenkov · ‎2012-01-29

Yes, looks like it ignores suitable spare. Do you have any suspicious messages in /etc/messages about it?

aborzenkov · ‎2012-01-29

Have you read "High availability configuration guide", in particular "Managing takeover and giveback" chapter? For version 7.x document is called "Active/Active configuration guide".

aborzenkov · ‎2012-01-29

I do not understand this question. You do takeover/giveback between two systems in HA pair. What do you mean under "2 active filers"?

Re: Upgrade the boot_backup

Re: aggr status redirect and volume status active_redirect

Re: snapmirror question

Re: Jumbo Frame on 8.0.2

Re: Managing /etc files on a non-CIFS filer (Question/Complaint)

Re: Managing /etc files on a non-CIFS filer (Question/Complaint)

Re: Managing /etc files on a non-CIFS filer (Question/Complaint)

Re: Disk firmware could not be downloaded on 1 disk.

Re: Managing /etc files on a non-CIFS filer (Question/Complaint)

Re: Exact CPU Modules in NetApp heads

Re: Edit /etc/rc file over NFS

Re: Initiator groups not showing on both filers

Re: NetApp 2040 Initial Configuration

Re: Upgrade From FAS2040 to FAS3270 How Disruptive?

Re: Upgrade From FAS2040 to FAS3270 How Disruptive?

Re: Restrict snapshot space on a volume

Re: Disks, aggregates and raidgroups using DS4324

Re: snapmirror window_size

Re: vPC and LACP configuration

Re: NetApp 2040 Initial Configuration

Re: I have a sparing problem where a 1TB SATA spare will not spare out a failed 750GB SATA disk on a...

Re: Restrict snapshot space on a volume

Re: I have a sparing problem where a 1TB SATA spare will not spare out a failed 750GB SATA disk on a...

Re: upgrade ontap software ndu on active/active cluster

Re: upgrade ontap software ndu on active/active cluster