toasters

toasters@lists.teaparty.net

13531 discussions

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

RE: Automatic NFS export on vol create
by Mike Sphar 18 Aug '04

18 Aug '04

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. Databases always seem like a good idea until they get corrupted, or the front-end administration tools fail because of bad data. (Anyone else ever adminned AIX? Hell, just the other day I had to spend a fair amount of time trying to repair a corrupted registry on a Windows box.) -- Mike Sphar - Sr Systems Administrator - Remedy, a BMC Software Company -----Original Message----- From: Haynes, Tom [mailto:thomas@netapp.com] Sent: Wednesday, August 18, 2004 1:04 PM To: skeezics(a)selectmetrics.com Cc: toasters(a)mathworks.com Subject: Re: Automatic NFS export on vol create Is it a dumbing down or an automation of common steps? I know when I designed and coded the automatic writing of the /etc/exports, my goal was to remove some repetitive and manual steps. 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. Some of the posters on this thread make it sound like this was a conspiracy. If we had been a brand new company and we came out with a product which kept the exports information in a database instead of a flat file, would you have been this upset? Or would you have enjoyed the experience? I've been of the flat file bent myself for a long time. Now that I have to maintain the exports file, I'm leaning towards a database for it. There is just too much ambiguity in parsing entries in the host lists - well formed fields, like *shudder* XML, make too much sense. Anyway, there is no global plan to dumb down the product - just local designs to reduce problems found in customer escalations. > On Wed, 18 Aug 2004, Bruce Arden wrote: > > Uh, whoops, now I've got this "/vol/new" export at the end of the file? > Hmmm. Harmless, in this case, because at reboot there was no volume named > "new" so it wasn't exported... still, this was another little surprise > that could have had more serious consequences, and as another long-time > Unix/ONTAP hacker I have to lobby against the dumbing down of ONTAP. Any > sysadmin qualified to run the box can learn it in an hour or less; filers > don't need to be much simpler than they are now. What's next? "Hey, > Boeing, this 747 is too hard to fly, make it easier so we can use cheaper > pilots." > > Cringe. > > -- Chris > -- Tom Haynes, ex-cfb thomas(a)netapp.com

1 0

any other gotchas for 6.5.x export files
by Kerry Herschel 17 Aug '04

17 Aug '04

Hi, I am about to upgrade to 6.5.x from 6.4.2P11. Are there any other gotchas about the exports file in 6.5.x? Thanks, Kerry ================================================================ Margaret.K.Herschel(a)jpl.nasa.gov JPL Information Services Jet Propulsion Laboratory Phone 818.354.1111 DISCLAIMER: The personal and professional opinions presented herein are my own and do not, in any way, represent the opinion or policy of JPL.

3 2

Re: Automatic NFS export on vol create
by Davin Milun 17 Aug '04

17 Aug '04

Agreed... Making it an option would be a much cleaner solution. It's all these changes/weirdnesses etc. that is causing me to not even consider moving to the 6.5 series yet. I plan on staying with 6.4.x for quite a while longer, until the rest of the changes/bugs/etc have been found and ironed out. Davin. At 12:58, on Aug 17, 2004, "Chris Blackmor" wrote: > > I am with Matt on this one. If you want it to default as "on" that is > fine. Then those of us who want to do everything ourselves are happy and > those that want a little more help are happy too. > > I appreciate NA trying to help but really... this goes a little too far. > C- > > On Tue, Aug 17, 2004 at 01:39:43PM -0400, Matt Phelps wrote: > > Haynes, Tom wrote: > > >I'll put myself in here, it seems like as good a point as any. And > > >I'll forwarn you that I am the one who coded all of the changes in the > > >way OnTap handles exports. > > > > > >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. > > > > > > > So why not an "option auto_update_exports off" ??? > > > > Then, we can *all* have it "our way".

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