Hi Toasters
Last week we attempted to extend a disk - a lun mounted in windows 2003 server using snapdrive (ver 6.0.1) - something we do fairly often.
The event viewer on the server reported:
Failed to expand the LUN by 51200 MB. Failure in expanding NTFS file system on the disk.
LUN Name = bondv8_database.lun Storage Path = /vol/vol_bondv8/ Protocol Type = LUN Storage System Name = RULWAFAS01
Error code : The parameter is incorrect.
However, the filer actually did expand the lun, and from the filer everything looked kosher.
Windows however, did not reflect the change. We disconnected/reconnected etc and it wouldn't change. Netapp told us to either a) rewrite the MBR on the disk manually using a windows support tool (beyond our expertise and a bit scary) or b) copy all the data off, destroy the volume, recreate, and copy back.
We did (b) and the copying of the data to a new volume took 7 hours, and once we destroyed/recreated a new volume, the copy back took 2 hours. This was all over the Fibre channel, and the speed difference I cant account for,
I can expand the new lun/volume using snapdrive with no problems now, but have to admit my confidence in snapdrive is shaken. It's taken all weekend to sort this out (following an aborted copy on saturday) and am worried that such a fundamental facility of the SAN is being compromised by the Snapdrive software.
Has anyone got any ideas as to why windows would do this? Its not happened before, and its a stable server, all upto date. Ontap is 7.2.5.1, filers, FC switches, drivers etc were updated late last year and we've been very stable.
thanks
Dave Ashton
********************************************************************** The information contained in this e-mail and any attachments are intended for the named recipient(s) only. It may also be privileged and confidential. If you are not an intended recipient, you must take no action as a result of receiving it, including, but not limited to copying, distributing and amending it. If this communication has been sent to you in error, please contact us immediately and do not show the communication to any other party.
Rullion shall have no liability whatsoever in respect of the content of the communication and makes no warranty as to accuracy. Any views or opinions presented are solely those of the author.
Viruses:- Although we have taken steps to ensure that this e-mail and attachments are free from viruses, we advise that in keeping with good computing practice, the recipient should ensure they are actually virus free.
**********************************************************************
________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________
Hey Dave,
On Mon, Jul 6, 2009 at 11:50 AM, David.Ashton@rullion.co.uk wrote:
Hi Toasters
Last week we attempted to extend a disk - a lun mounted in windows 2003 server using snapdrive (ver 6.0.1) - something we do fairly often.
The event viewer on the server reported:
Failed to expand the LUN by 51200 MB. Failure in expanding NTFS file system on the disk.
I've seen this happen on a LUN that was created manually, and after that was managed by SnapDrive, maybe this happened in your case too?
Greetings,
Nils
Hi Dave
One important caveat with expanding LUNs is that a LUN cannot be expanded to more than ten times its original size, due to the LUN geometry. I guess the question is what size was the LUN when it was first created and to what size did you want to expand it. I'd still say that if that were the cause then SD should have thrown an error and said "no can do".
cheers Kenneth
________________________________
To: toasters@mathworks.com Subject: Snapdrive problem From: David.Ashton@rullion.co.uk Date: Mon, 6 Jul 2009 10:50:01 +0100
Hi Toasters
Last week we attempted to extend a disk
- a lun mounted in windows 2003 server using snapdrive (ver 6.0.1) - something
we do fairly often.
The event viewer on the server reported: Failed to expand the LUN by 51200 MB. Failure in expanding NTFS file system on the disk. LUN Name = bondv8_database.lun Storage Path = /vol/vol_bondv8/ Protocol Type = LUN Storage System Name = RULWAFAS01 Error code : The parameter is incorrect.
However, the filer actually did expand the lun, and from the filer everything looked kosher. Windows however, did not reflect the change. We disconnected/reconnected etc and it wouldn't change. Netapp told us to either a) rewrite the MBR on the disk manually using a windows support tool (beyond our expertise and a bit scary) or b) copy all the data off, destroy the volume, recreate, and copy back.
We did (b) and the copying of the data to a new volume took 7 hours, and once we destroyed/recreated a new volume, the copy back took 2 hours. This was all over the Fibre channel, and the speed difference I cant account for,
I can expand the new lun/volume using snapdrive with no problems now, but have to admit my confidence in snapdrive is shaken. It's taken all weekend to sort this out (following an aborted copy on saturday) and am worried that such a fundamental facility of the SAN is being compromised by the Snapdrive software.
Has anyone got any ideas as to why windows would do this? Its not happened before, and its a stable server, all upto date. Ontap is 7.2.5.1, filers, FC switches, drivers etc were updated late last year and we've been very stable.
thanks Dave Ashton
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
-
David.Ashton＠rullion.co.uk -
Kenneth Heal -
Nils Vogels