toasters

toasters@lists.teaparty.net

13514 discussions

Start a nNew thread

760 specs
by Michael Christian 20 Aug '04

20 Aug '04

Anyone know how many mk2 shelves you can throw on a 760? Thanks, -MikeC

2 1

RE: Number of Disks on a F720
by Timothy Naple 20 Aug '04

20 Aug '04

Paul, What size disks are you running? Tim -----Original Message----- From: Paul McGuinness (ext. 771) [mailto:Paul.McGuinness@fineos.com] Sent: Friday, August 20, 2004 1:54 AM To: toasters(a)mathworks.com Subject: Number of Disks on a F720 Hi, I have an F720 filer (Release 6.3.1) with 2 FC9 shelves and 1 DS14 shelf - both fully populated. My question is can I add another shelf to this or am I maxed out? Any thoughts on this much appreciated Paul ********************************************************************** The information contained in this e-mail is confidential, may be privileged and is intended only for the user of the recipient named above. If you are not the intended recipient or a representative of the intended recipient, you have received this e-mail in error and must not copy, use or disclose the contents of this e-mail to anybody else. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the copy you received. This e-mail has been swept for computer viruses. However, you should carry out your own virus checks. Registered in Ireland, No. 205721. http://www.FINEOS.com **********************************************************************

1 0

Number of Disks on a F720
by Paul McGuinness (ext. 771) 20 Aug '04

20 Aug '04

Hi, I have an F720 filer (Release 6.3.1) with 2 FC9 shelves and 1 DS14 shelf - both fully populated. My question is can I add another shelf to this or am I maxed out? Any thoughts on this much appreciated Paul ********************************************************************** The information contained in this e-mail is confidential, may be privileged and is intended only for the user of the recipient named above. If you are not the intended recipient or a representative of the intended recipient, you have received this e-mail in error and must not copy, use or disclose the contents of this e-mail to anybody else. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the copy you received. This e-mail has been swept for computer viruses. However, you should carry out your own virus checks. Registered in Ireland, No. 205721. http://www.FINEOS.com **********************************************************************

1 0

RE: usable size of a 146-GB drive
by Brubaker, Paul 19 Aug '04

19 Aug '04

We also back out 30% (20% for snap reserve + 10% WAFL overhead) and then another 10% buffer for disk fragmentation... So approx 40% total. Paul M. Brubaker, Jr. RIDS - Intel System Support AT&T Wireless - Harrisburg PA e-mail: paul.brubaker(a)attws.com office #: 717-526-5011 cell #: 717-578-2254 -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Bokkelkamp Ernst Sent: Thursday, August 19, 2004 2:05 PM To: geoff.hardin(a)dalsemi.com; James Brigman; toasters Subject: RE: usable size of a 146-GB drive I think this might interest you. The magic figure is about 30. 36 -> 30 GB 72 -> 60 GB 144 -> 120 GB 250 -> 180 GB Although not exactly accurate, for my purposes this has worked out quite well. The other magic factor is about 0.8 Take a filer with 5 x DS14 shelfs giving 70 drives. Assume that one shelf will be assigned to "overhead", create volumes on the remaining 4 shelf with two parity drives, giving a total of 8 drives overhead. Assume that the system drive takes two drives and 4 drives are reserved as spares (8 + 2 + 4 = 14 drives), leaving 56 drives ( or 80% ) for data. If you now apply 0.8 again to the remainder it will give you the approximate size of the space available for the file system. (this is a crude approximation of the magic 30 factor). (0.8 x 0.8 = 0.64) If you now apply 0.8 again to the remainder it will give you the approximate space availabe to the users with a snapshot reserve of 20%. (0.8 x 0.8 x 0.8 = 0.5) This crude methode has work well for me until now Bye Ernie -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of James Brigman Sent: Thursday, August 19, 2004 2:38 PM To: 'toasters' Subject: RE: usable size of a 146-GB drive Geoff; You've done some good research: I'm seeing similar numbers you're finding on 36 and 72GB disks. However, notice that the space efficiency is going to vary dramatically with the size of the RAID group. That should not be surprising: a two-spindle volume's real availability drops to 33%. (48GB / 144GB ... everyone sees that with vol0...) I believe it's possible, if you make the raid group very large and use RAID-DP, you could increase space efficiency and performance too. I don't have 144GB numbers for you, but the "250GB" drives in an R200 work out to less than 200GB usable. I'll try to post some numbers to the list later this week... JKB -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Geoff Hardin Sent: Wednesday, August 18, 2004 8:20 PM To: toasters Subject: usable size of a 146-GB drive I was just wondering if anyone had any info on the usable size of the 146-GB drives from NetApp. I am trying to figure out how many drives I'll need, but I can't really tell without knowing what my usable space will be. If it helps, here's some data I have collected from other drives. 18 GB disk - becomes 17.0 GB because of disk overhead (right size) - becomes 14.923389 because of OS overhead - becomes 13.431053 with a 10% snap reserve - becomes 11.938713 with a 20% snap reserve 36 GB disk - becomes 33.917 GB because of disk overhead - becomes 31.776308 because of OS overhead - becomes 27.273826 with a 10% snap reserve - becomes 25.421048 with a 20% snap reserve 72 GB disk - becomes 67.906 GB because of disk overhead - becomes 59.747608 because of OS overhead - becomes 53.772850 with a 10% snap reserve - becomes 47.798088 with a 20% snap reserve Thanks, Geoff Hardin UNIX System Administrator Dallas Semiconductor / Maxim Integrated Products geoff.hardin(a)dalsemi.com It's illegal to walk your elephant without a leash in Wisconsin.

1 0

search function of website
by Mike Langas 19 Aug '04

19 Aug '04

Is the search function broken at the following URL? http://toasters.mathworks.com/toasters/Search.html I keep getting a page can not be found error. Thanks, Mike __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

RE: usable size of a 146-GB drive
by Bokkelkamp Ernst 19 Aug '04

19 Aug '04

I think this might interest you. The magic figure is about 30. 36 -> 30 GB 72 -> 60 GB 144 -> 120 GB 250 -> 180 GB Although not exactly accurate, for my purposes this has worked out quite well. The other magic factor is about 0.8 Take a filer with 5 x DS14 shelfs giving 70 drives. Assume that one shelf will be assigned to "overhead", create volumes on the remaining 4 shelf with two parity drives, giving a total of 8 drives overhead. Assume that the system drive takes two drives and 4 drives are reserved as spares (8 + 2 + 4 = 14 drives), leaving 56 drives ( or 80% ) for data. If you now apply 0.8 again to the remainder it will give you the approximate size of the space available for the file system. (this is a crude approximation of the magic 30 factor). (0.8 x 0.8 = 0.64) If you now apply 0.8 again to the remainder it will give you the approximate space availabe to the users with a snapshot reserve of 20%. (0.8 x 0.8 x 0.8 = 0.5) This crude methode has work well for me until now Bye Ernie -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of James Brigman Sent: Thursday, August 19, 2004 2:38 PM To: 'toasters' Subject: RE: usable size of a 146-GB drive Geoff; You've done some good research: I'm seeing similar numbers you're finding on 36 and 72GB disks. However, notice that the space efficiency is going to vary dramatically with the size of the RAID group. That should not be surprising: a two-spindle volume's real availability drops to 33%. (48GB / 144GB ... everyone sees that with vol0...) I believe it's possible, if you make the raid group very large and use RAID-DP, you could increase space efficiency and performance too. I don't have 144GB numbers for you, but the "250GB" drives in an R200 work out to less than 200GB usable. I'll try to post some numbers to the list later this week... JKB -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Geoff Hardin Sent: Wednesday, August 18, 2004 8:20 PM To: toasters Subject: usable size of a 146-GB drive I was just wondering if anyone had any info on the usable size of the 146-GB drives from NetApp. I am trying to figure out how many drives I'll need, but I can't really tell without knowing what my usable space will be. If it helps, here's some data I have collected from other drives. 18 GB disk - becomes 17.0 GB because of disk overhead (right size) - becomes 14.923389 because of OS overhead - becomes 13.431053 with a 10% snap reserve - becomes 11.938713 with a 20% snap reserve 36 GB disk - becomes 33.917 GB because of disk overhead - becomes 31.776308 because of OS overhead - becomes 27.273826 with a 10% snap reserve - becomes 25.421048 with a 20% snap reserve 72 GB disk - becomes 67.906 GB because of disk overhead - becomes 59.747608 because of OS overhead - becomes 53.772850 with a 10% snap reserve - becomes 47.798088 with a 20% snap reserve Thanks, Geoff Hardin UNIX System Administrator Dallas Semiconductor / Maxim Integrated Products geoff.hardin(a)dalsemi.com It's illegal to walk your elephant without a leash in Wisconsin.

1 0

Re: Automatic NFS export on vol create
by Chris Thompson 19 Aug '04

19 Aug '04

Well, I think that's about my personal best for a toasters posting stirring things up! :-) First, a small correction. I wrote: > When a volume is created, say /vol/test, it is now autmatically > NFS exported with a rule > > /vol/test -rw,nosuid > > i.e. read-write to the world. As a volume starts off with just > a root-owned top-level directory, and there's no "root=" clause, > this isn't _exactly_ a security exposure staight away, but of course > it becomes one as soon as more interesting data is installed there. Actually, the export options used are "-rw,root=[the admin.hosts option]". It just so happens that I have admin.hosts set to the empty list on this filer (originally done for tidyness: what hosts I might want to be admin hosts changes all the time - it didn't occur to me that it would [partially] save me in the current context). Picking some points pseudo-randomly from the thread ... Tom Haynes <thomas(a)netapp.com> wrote: > One thing to be remembered in all of this discussion is that the export > changes were driven by customer requests. So, what one customer may not > like, some other customer *had* to have in the code. I dispute that anyone "*had*" to have this change. The situation is actually that in order to make things *easier* for a certain class of users using filers in very stereotyped ways, you have introduced potentially quite serious security exposures for the rest of us. > We were automatically creating default exports for the root volume. > This allowed an admin to start editing files as soon as a NFS license > was given to the filer. > > We expanded this capability to include all volumes. I dispute that the cases are at all analogous. The original root volume NFS export was done by the "setup" command (I haven't checked whether you've changed that in 6.5.x as well) as part of bootstrapping a filer into existence, and of course one expected to go over the eventual configuration with a fine toothcomb. Creating a new volume on an existing filer just isn't a comparable activity. Bruce Arden <arden(a)nortelnetworks.com> wrote: > Does "vol create" create a CIFS shares as well? No it doesn't, and that is a very pertinent point. "setup" assumed that NFS would be used for (initial) administration because ... well, because that's all there was in the early days of NetApp. A rethink of "setup" to help non-NFS-capable sysadmins might have been a more pertinent objective. Mike Sphar <mike.sphar(a)Remedy.COM> wrote: > Speaking purely for myself, as a long-time Sysadmin, the fact that so much > of Netapp's config is stored in text files was a *big* advantage to me. I couldn't agree more ... John Clear <jclear(a)ati.com> wrote: > Flat text files are good. If NetApp wants to make everything into > a database, at least have an option to populate the database from > a text file. Having `exportfs -a` read /etc/exports and create > /etc/exports.db is fine, but I want to be able to edit a text file. > > We keep quotas, exports and a few other of the config files under RCS > on all our filers, so any automatic 'helpful' changes will be lost at > the next check-out. In fact I knew that I "ought to do something" about /etc/exports maintenance after the 6.5.x upgrade --- I just didn't realise it was so urgent! Like John, I have always kept (the masters for) config files on filers under a change control system. Then in 5.3.4 the registry replaced the options settings in /etc/rc. I made do with a crontab that picks the options out of /etc/registry and compares them with a what-they-should-be file under change control and warns me of any differences. Now it looks as though I will need to do something similar for /etc/exports, but whereas many unexpected options settings are benign, that's much less likely to be true for unexpected NFS exports. Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.

3 2

usable size of a 146-GB drive
by Geoff Hardin 19 Aug '04

19 Aug '04

I was just wondering if anyone had any info on the usable size of the 146-GB drives from NetApp. I am trying to figure out how many drives I'll need, but I can't really tell without knowing what my usable space will be. If it helps, here's some data I have collected from other drives. 18 GB disk - becomes 17.0 GB because of disk overhead (right size) - becomes 14.923389 because of OS overhead - becomes 13.431053 with a 10% snap reserve - becomes 11.938713 with a 20% snap reserve 36 GB disk - becomes 33.917 GB because of disk overhead - becomes 31.776308 because of OS overhead - becomes 27.273826 with a 10% snap reserve - becomes 25.421048 with a 20% snap reserve 72 GB disk - becomes 67.906 GB because of disk overhead - becomes 59.747608 because of OS overhead - becomes 53.772850 with a 10% snap reserve - becomes 47.798088 with a 20% snap reserve Thanks, Geoff Hardin UNIX System Administrator Dallas Semiconductor / Maxim Integrated Products geoff.hardin(a)dalsemi.com It's illegal to walk your elephant without a leash in Wisconsin.

2 1

RE: Automatic NFS export on vol create
by Munn, Stuart SITI-ITISEEES 19 Aug '04

19 Aug '04

>The idea of programming is to "solve a problem". >From the reaction on this list, looks like the automation created more >problems than solved. That is a big assumption! what is the number of Netapps admins on this list compared to those actually managing Netapps devices?... quite small I would think. And how many of them on the list think this is a problem... even smaller ... Still I agree that this is undesirable from a security point of view I'd much prefer the old method, or at least a way of turning off this feature... Cheers Stuart -----Original Message----- From: devnull(a)adc.idt.com [mailto:devnull@adc.idt.com] Sent: Wednesday, August 18, 2004 7:29 PM To: Haynes, Tom Cc: NetApp Toasters List Subject: Re: Automatic NFS export on vol create > Is it a dumbing down or an automation of common steps? I agree. I think it is automation. But, maybe i dont want it. How about -UpdateExportsFile or a -DontUpdateExportsFile to go along with vol create If you are going to "automate" something, make sure you give people a way out of it. Your idea of automation might interfere with someone else's idea of control. > You have to remember that is what programming is all about: > 1) finding common blocks of functionality and wrapping them in a function. > 2) reducing the human interaction. hmm. agreed...sorta. The idea of programming is to "solve a problem". From the reaction on this list, looks like the automation created more problems than solved. If i see more emails which say "thanks for automation the vol creation tom", i will be forced to think otherwise. So, instead, lets solve old RFE's like ACL's for nfs first.

1 0

RE: usable size of a 146-GB drive
by Stephenson, Burke T. GD 19 Aug '04

19 Aug '04

The 144GB drives (never heard of 146GB) show up as 136FB Burke -----Original Message----- From: Geoff Hardin [mailto:geoff.hardin@dalsemi.com] Sent: Thursday, August 19, 2004 1:20 AM To: toasters Subject: usable size of a 146-GB drive I was just wondering if anyone had any info on the usable size of the 146-GB drives from NetApp. I am trying to figure out how many drives I'll need, but I can't really tell without knowing what my usable space will be. If it helps, here's some data I have collected from other drives. 18 GB disk - becomes 17.0 GB because of disk overhead (right size) - becomes 14.923389 because of OS overhead - becomes 13.431053 with a 10% snap reserve - becomes 11.938713 with a 20% snap reserve 36 GB disk - becomes 33.917 GB because of disk overhead - becomes 31.776308 because of OS overhead - becomes 27.273826 with a 10% snap reserve - becomes 25.421048 with a 20% snap reserve 72 GB disk - becomes 67.906 GB because of disk overhead - becomes 59.747608 because of OS overhead - becomes 53.772850 with a 10% snap reserve - becomes 47.798088 with a 20% snap reserve Thanks, Geoff Hardin UNIX System Administrator Dallas Semiconductor / Maxim Integrated Products geoff.hardin(a)dalsemi.com It's illegal to walk your elephant without a leash in Wisconsin.

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