DO NOT DO THIS if it is an Oracle database.  We did a few years ago and started having weird issues.  Also, you are on your own if you do.  Oracle does not support running databases over CIFS.  They support NFS and LUNs, but no CIFS.
----- Original Message -----
From: Milazzo Giacomo
To: David.Ashton@rullion.co.uk
Cc: Willeke, Jochen ; owner-toasters@mathworks.com ; toasters@mathworks.com
Sent: Thursday, September 04, 2008 9:51 AM
Subject: R: R: Noob...

Ok.

If the lecacy application could do it consider the usage of a CIFS shared area instead of a LUN formatted and mounted on Windows VM.

The file system overall performances will be more than better ;-)

Double space available, snapshotting faster and so on…

 

 

 

Da: David.Ashton@rullion.co.uk [mailto:David.Ashton@rullion.co.uk]
Inviato: giovedì 4 settembre 2008 15.33
A: Milazzo Giacomo
Cc: Willeke, Jochen; owner-toasters@mathworks.com; toasters@mathworks.com
Oggetto: Re: R: Noob...

 


thanks all for the excellent advice and pointers. I'll remove the snap reserve, I think the sizing is probably correct then.

The lun is mounted on a windows server that has snapdrive installed. The rate of change - varies from 3GB somedays to 80GB on others.
The server runs a legacy app that uses an enormous 3.6 million flat text files (220GB), and the number of open files is in the 10,000's at any one time so it gets a battering.

Dave

Rullion Management Services Ltd is a company registered in England and Wales with company number 2797732.


"Milazzo Giacomo" <G.Milazzo@sinergy.it>
Sent by: owner-toasters@mathworks.com

04/09/2008 14:06

To

"Willeke, Jochen" <Jochen.Willeke@wincor-nixdorf.com>, <David.Ashton@rullion.co.uk>, <toasters@mathworks.com>

cc

Subject

R: Noob...

 




A first answer came from Jochen and I’ve to add that if you have a volume that has to contain a LUN (that is, with NetApp, a file) the default snapshot reservation area of 20% (or less) must be removed, so the snap schedule.
In your case
 
Filer> snap reserve vol_bond 0
Filer> snap sched vol_bond 0 0 0
 
This in case you use some software of Snapmanager suite (You did not tell us the usage of that lun) or the snapmirror snapshots will be placed in the active file system area having the necessary free space. Never size a volume less that 2/2.5 time the size of the contained luns.
 
Bye
 
Da: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] Per conto di Willeke, Jochen
Inviato:
giovedì 4 settembre 2008 12.54
A:
David.Ashton@rullion.co.uk; toasters@mathworks.com
Oggetto:
RE: Noob...

 
Hi David,
 
as far as i can see, everything is as expected.
When you have fractional_reserve set to 100 (%), as soon as you create snapshots on that volume, ontap will reserve 100% of the Luns size within the volume, to gurantee writes to complete successfully.

 
The maths show:
 
820GB * 0,8 (for snap reserve) = 656 GB
 
320GB Lun * 2 (for fractional reserve) = 640 GB
 
P = 640 / (656*100) = 97,56 %
 
Think ontap is doing some rounding, so 98% is correct.
 
Regards
 
Jochen
 

 



From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of David.Ashton@rullion.co.uk
Sent:
Thursday, September 04, 2008 12:04 PM
To:
toasters@mathworks.com
Subject:
Noob...


Hi, please excuse my noobness, I've recently inherited a Netapp system or 3, I'm fairly new to SANs in general and netapp in particular. This isnt my full time gig (storage), its one thing amongst the 2 thousand other things I'm working on today, but I allocate a fair amount of time to figuring this stuff out.


I'm struggling with something I'm sure all netapp storage people go through, I've read the manuals, I've played around for about 6 months on the filers and I cant answer this.


I have a FAS3020. I have a volume, lets call it vol_bond. Its 820GB, 20% snap reserve. It contains one lun, which is 320GB. The space guarantee is volume, and fractional reserve is 100.


Currently, there are 5 snapshots, totalling 8GB. It is snap mirrored to another filer.  Snapshots are created nightly, there are no problems with that. At weekends, after various backup activity, these grow to about 80GB, but we only keep 5 and they're deleted.


Its all up and running, everythings fine.


Except for the filer status which reports:
/vol/vol_bond is full (using or reserving 98% of space and 0% of inodes, using 49% of reserve) and the df -r output is

/vol/vol_bondv8/     687865856  670681368   17184488  335194536  /vol/vol_bondv8/
/vol/vol_bondv8/.snapshot  171966464   14140040  157826424          0  /vol/vol_bondv8/.snapshot

What am I missing? I thought I had this thing nailed but obviously not.

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
________________________________________________________________________

 



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.


________________________________________________________________________
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
________________________________________________________________________


________________________________________________________________________
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
________________________________________________________________________