toasters

toasters@lists.teaparty.net

13531 discussions

Amperage readings for NetApp 740 head and shelves
by Maglinger, Paul 27 Aug '04

27 Aug '04

My profound thanks to the numerous replies. A little clarification... This was for sizing PDUs (Power Distribution Units for you non-Compaq/HP folks) for the server racks and not for air conditioning. Compiling all the information I went with 2.25A@120VAC for the 740 head and 3.0A@120VAC for the shelves. I think this will get us close enough where we can balance the load sufficiently. Thanks again! > Has anyone taken any amperage readings on their heads and shelves? I see by > the label that the shelves are rated at 5.5A/120VAC 3.2A/240, but I'm > wondering about the actual current draw. I could disconnect one of the > power supplies to get the reading, but this is a production system and don't > want to tempt fate. > > Thanks! > > That that is, is; that that is not, is not; that that is, is not that that > is not; that that is not, is not that that is. Is that not it? It is. > > Paul Maglinger, A+, CA, CCA, CET, MCSE > Systems Administrator Shoe Carnival Inc. (812)867-4674 pmaglinger(a)scvl.com >

1 0

RE: Amperage readings for NetApp 740 head and shelves
by Timothy Naple 27 Aug '04

27 Aug '04

Paul, What model shelves and disks are you running on the F740? I would be happy to plug in your exact configuration and take an accurate measurement for you. Thank you, Tim Timothy Naple tnaple(a)berkcom.com 510-644-1599 VOICE 510-644-1598 FAX 888-812-9040 TOLL-FREE Berkeley Communications Corporation 2990 San Pablo Avenue Berkeley, CA 94702 http://www.berkcom.com -----Original Message----- From: Maglinger, Paul [mailto:PMAGLINGER@scvl.com] Sent: Wednesday, August 25, 2004 9:27 AM To: 'NetApps list server' Subject: Amperage readings for NetApp 740 head and shelves Has anyone taken any amperage readings on their heads and shelves? I see by the label that the shelves are rated at 5.5A/120VAC 3.2A/240, but I'm wondering about the actual current draw. I could disconnect one of the power supplies to get the reading, but this is a production system and don't want to tempt fate. Thanks! That that is, is; that that is not, is not; that that is, is not that that is not; that that is not, is not that that is. Is that not it? It is. Paul Maglinger, A+, CA, CCA, CET, MCSE Systems Administrator Shoe Carnival Inc. (812)867-4674 pmaglinger(a)scvl.com

1 0

Lotus Notes & backups
by George Kahler 26 Aug '04

26 Aug '04

Hi does anyone have any recommendations on backup strategies in regards to Notes on Solaris and the transaction logs and data on the filer ? Snapshots seen to be the natural choice, however, what recovery tools are available to facilitate the restores ? NetBackup does not presently support backing up over nfs. Thanks, George ------------------------------------------------------------------------------- George Kahler e-mail: george(a)yorku.ca Sr. Systems Administrator humans: (416) 736-2100 x.22699 Computing and Network Services machines: (416) 736-5830 Ontario, Canada, M3J-1P3

1 0

Amperage readings for NetApp 740 head and shelves
by Maglinger, Paul 25 Aug '04

25 Aug '04

Has anyone taken any amperage readings on their heads and shelves? I see by the label that the shelves are rated at 5.5A/120VAC 3.2A/240, but I'm wondering about the actual current draw. I could disconnect one of the power supplies to get the reading, but this is a production system and don't want to tempt fate. Thanks! That that is, is; that that is not, is not; that that is, is not that that is not; that that is not, is not that that is. Is that not it? It is. Paul Maglinger, A+, CA, CCA, CET, MCSE Systems Administrator Shoe Carnival Inc. (812)867-4674 pmaglinger(a)scvl.com

1 0

urgent genuine business relationship
by mimico2004 24 Aug '04

24 Aug '04

MIM COMPANY 26 NNPC ROAD EJIGBO LAGOS NIGERIA TEL:234-8033-924567 EMAIL:mimico@libero.it magnus_asu(a)yahoo.com Dear Sir Permit me to introduce our company to you as the name implies above. Mimco is a newly etablished company to Export Agricultural and palm produce including sea foods unbehalf of CO-OPERATIVE FARMERS in the rural communities We have the following products in stock for Export 1. 100 tones of palm kernel seeds 2. 30 toneas of tropical raw natural honey 3. 100 tones of beeswax We are making preperation to receive dry crey fish/shrimes to our stock. As a newly established we encourage our customers to make travelling arrangement to come to Nigeria for inspection, confirmation and shipment of the products , this measure is taken to safeguard the products and the interest of the customers against any form of fraudulent acts. W e are looking for serious buyers our prices are affordable if you can handle this business please contact me as a matter of urgent Thanks Yours in Faith Magnus Asquo Export Director

1 0

Urgent Enquiry
by Tatsushi Yo 24 Aug '04

24 Aug '04

Ref: ZA-296-ENQR / YOKOHAMA I work for Yokozuna Financial Consultancy that is in the middle of a very important enquiry. I am getting in touch with you on behalf of our client, which is a top Japanese Bank (Yokohama Bank).We are conducting a search for any next of kin for a particular investor who has passed on. Please do you have any relatives who have lived in Japan for the last 30 years or more. Also are you aware of any relatives who might have been into real estate or a huge investor in Energy. We understand that this might be all too sudden for you, however we will appreciate that you get back to us even if no one of the above description is known to you. This will help us put an end to this matter. The reason we are getting in touch with you is because you share the same name with the individual. Please can you send us a mail indicating if you know any one with the above description? Also If no one of such description is known to you kindly send us a mail stating that, as this Will assit us stop further communication with you. Can you please send your reply to Tatsushi Yo as I am in charge of this enquiry. Please kindly get in touch by email to this enquiry, as this will enable us stop further communication with you. Thanks Tatsushi Yo *********************************************************************As a management consultancy firm we can help you answer the question below if Japan has been of any interest to you. WHY INVEST IN JAPAN ? There is tremendous investment opportunity in Japan, provided one takes the time to dig through the superficial media hype and colored analyses. While there is no shortage of accounts of what is happening in Japan, there is a dearth of relevant facts, considered interpretations, and clear-headed analysis of developments and events that answer key questions about your investments in Japan. Moreover, even in the age of instant communications and the Internet, the majority of information that is being discounted in Japan's financial markets is simply not available in English. We try to solve these problems with our vast knowledge and 20 years experience.

1 0

RE: 760 specs
by Michael Christian 20 Aug '04

20 Aug '04

Wow, that link is pure gold. I thought they were hiding the end-of-lifed configs. Thanks, Stephane. _____ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Stephane Sent: Friday, August 20, 2004 3:53 AM Cc: toasters(a)mathworks.com Subject: Re: 760 specs depends on your shelfs i think mk2 can be up to 4 or 8 according the LRC/ESH module have a look here : http://now.netapp.com/NOW/knowledge/docs/hardware/NetApp/syscfg/ choose your ontapp version then select your filer and select disk shelves you probably can read : << Note: When the disk shelf has LRCs, the maximum number of disk shelves per loop is four. >> -> understand "8 shelves otherwise"... as i read it from another machine/ontapp page << Note: When the disk shelf has ESHs, the maximum number of disk shelves per loop is six and the first shelf in the loop must have optical modules. >> Michael Christian wrote: Anyone know how many mk2 shelves you can throw on a 760? Thanks, -MikeC

1 0

Awful ufsrestore performance reading from DLT7000 on F810 (update)
by Chris Thompson 20 Aug '04

20 Aug '04

You may recall I raised this on toasters in early March this year. A quick recap: We ufsdump some Solaris partitions onto a DLT7000 attached to an F810. They are blocked at 63KB and write performance is not bad (though not quite as good as the dumps/restores of the F810 itself). But ufsrestore from this drive reads at 10% or less of that rate. Tests showed this problem was not specific to ufsrestore, but seemed always to occur when reading via the rmt(8) interface. But it didn't use to happen, back when this was Solaris 8 and ONTAP 6.2.2 on an F740, as opposed to Solaris 9 and ONTAP 6.4.3P2 on an F810 - so what changed? I've now repeated the experiments with ONTAP 6.5.1R1P6, and get the same results. But, I now have a workround! It turns out that if you stuff more than one "R" (read) command into the rmt(8) connection before waiting for the results of the first one then you can keep the tape moving. Keeping just one extra read pending all the time gives almost the full advantage, and gets ufsdump-type speeds. So I can run a (Perl) program using that algorithm to pull the whole dump file onto local disc on the Solaris hosts, and then ufsrestore from that. (Luckily, space isn't a significant problem here.) One needs to be careful about subsequent tape positioning because of the extra read(s) past end-of-file that have been done. I still don't know the answer to "what changed?", though. Here's an idea that _didn't_ work. I thought: as ONTAP restore reads the tape at a decent rate, why don't I apply it to the Solaris dumps and then move the results from the filer to the Solaris local discs? After all, if Solaris ufsrestore can read ONTAP dumps (modulo occasional problems that have been discussed in other threads over the years), then why shouldn't ONTAP restore be able to read Solaris dumps? So give it a try: filer> restore rfD nrst0a /vol/test/solaris-test RESTORE: tape file #1 on device nrst0a. RESTORE: Unsupported dump format. RESTORE: Could not initialize media. RESTORE: RESTORE IS ABORTED Oh well, it was a good idea while it lasted ... :-) 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.

1 0

RE: IPsec NFS to Unix clients
by Muhlestein, Mark 20 Aug '04

20 Aug '04

Here are a couple of other things you can do to improve NFS security: 1. If you have CIFS you might consider using the nfs.require_valid_mapped_uid option. That allows you to set up the usermap.cfg file to do things like this: # allow the following UIDs NFS access from the specified IP addresses tom <= 192.168.3.34:tom jerry <= jerrypc.dorm.foo.edu:jerry jerry <= lab1.foo.edu:jerry jerry <= lab2.foo.edu:jerry # etc. # allow root from the admin network Administrator <= 10.10.20.0/24:root # prevent all other NFS access "" <= * The nfs.require_valid_mapped_uid option causes the usermap.cfg entries to be consulted even for access to data on qtrees with UNIX security. Combined with the normal export controls, this approach works as long as clients are not allowed to successfully spoof source IP addresses. It is also more manageable if the number of combinations of users/hosts is not overly large or dynamic; however I know we have had sites that have used this type of approach with a script-generated usermap.cfg. 2. If you have MultiStore available you can also use that to fence off NFS access. NFS clients accessing an IP address associated with a vfiler are not allowed to access storage assigned to another vfiler. This is enforced at the WAFL layer, so even if clients attempt handle spoofing the access is denied as long as the potentially rogue clients are not allowed to access the other vfilers' IP addresses (e.g. different networks on separate NICs). Mark -----Original Message----- From: Steve Losen [mailto:scl@sasha.acc.virginia.edu] Sent: Friday, August 20, 2004 7:08 AM To: Brian Parent Cc: toasters(a)mathworks.com Subject: Re: IPsec NFS to Unix clients > Has anyone else come up with some alternate means by which to secure > NFS exported data, where the server is a NetApp filer? (For years I've > been losing the battle to get the physical network secure, using > locking wall jacks in our public access labs.) I've been using NetApp > file servers since 1995, and have been generally happy, but this security > problem is making me seriously reconsider. We came up with a pretty ugly hack to prevent folks from installing impostor NFS clients on a physically insecure network, such as in a student Unix lab. We were aware of the risk, but were finally motivated to do something when some little bastard (ahem, student) replaced a lab machine with his Linux laptop, so he was able to NFS mount the home directories, and because he had root on his laptop, he could su to any user and have read/write access to their home directory. So here is what we did. We export to a netgroup. We discovered that once a NFS client has an NFS mount, it doesn't matter if you remove the NFS client from the netgroup map. NFS keeps working fine. So we removed all the lab machines from the netgroup. We wrote a little client/server application in perl that temporarily puts the NFS client in the netgroup. The NFS client connects to the NIS master and identifies itself with a "secret handshake" The NIS master adds the NFS client to the netgroup map and the NFS client mounts the home directory volume. Then the NIS master removes the NFS client from the netgroup map. The NIS master has a list of machines that are allowed to be added to the netgroup. This prevents the attack we experienced. Physical access to the network is not enough any more. You also need to know the "secret handshake" to get added to the netgroup map, and only root has access to that file. (If someone gets root on a lab machine, then they don't need an impostor machine.) This is certainly far from perfect. There is no protection against a man in the middle attack. I suppose someone could put a Linux box with two ethernet interfaces between the lab machine and the ethernet switch. The Linux box could be programmed to pass through network packets, except that it would intercept NFS packets and modify them. Perhaps the uid field could be changed. That way the hacker could make NFS requests as himself on the lab machine, but his Linux box would change the uid field to another user. Does NFS have any protection against this sort of tampering? IPsec would prevent this, of course. There is also a brief window of vulnerability while the lab machine is in the netgroup. Perhaps with some determined trial and error a hacker could quickly slip in an impostor machine and mount the volume during this window. But he would need to power cycle the lab machine to make it boot and he would need to slip in the impostor at just the moment that the lab machine was in the netgroup. Not easy, but certainly possible. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

2 1

reliability of 15k vs 10k
by Michael Christian 20 Aug '04

20 Aug '04

Does anyone have a good feel for the reliability of the 15k drives vs 10k? We haven't really used the 15k's much yet, but the prices seem to be coming into line... Thanks, -MikeC

1 0

IPsec NFS to Unix clients
by Brian Parent 20 Aug '04

20 Aug '04

If anyone has been able to get IPsec protected NFS working between a NetApp filer and a Unix machine, I'd love to hear about it. I can get it to work using a Solaris 8 box as both the server and the client, but when I try to use a NetApp (6.4.4R1) as the server, no luck. I opened a case (697672), but was told that the only clients supported are windows 2K and later. This doc reinforces that: http://now.netapp.com/NOW/knowledge/docs/ontap/rel65/html/ontap/nag/ipsec2.… Towards the end of the page, under the section: About the Network Appliance IPsec implementation ... Only clients running Windows 2000 or greater are supported for IPsec connections. An RFE is filed: http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=130292 though the page is pretty useless, as it only says "Bug information not available". I enabled "watching" for that RFE, but haven't heard anything back since April, 2004. I've also tried using kerberos to secure the NFS exported data, but the way we share the data between heterogeneous platforms, it means that unless we can get all of our supported clients to use kerberized NFS, then it doesn't help to do any subset. At this point, MacOS X is holding us back. I'm praying that Tiger (10.4?) release will address the issue, but I'm not holding my breath. Even if they do, another hurdle is CAP. We re-export NFS mounted data via CAP to MacOS 9 boxes. Getting CAP to track kerberos credentials is not something we're willing to invest time in. Has anyone else come up with some alternate means by which to secure NFS exported data, where the server is a NetApp filer? (For years I've been losing the battle to get the physical network secure, using locking wall jacks in our public access labs.) I've been using NetApp file servers since 1995, and have been generally happy, but this security problem is making me seriously reconsider.

3 4

RE: Number of Disks on a F720
by Stephenson, Burke T. GD 20 Aug '04

20 Aug '04

We had up to 4-6 DS8/9 shelves on a F720 at one time. The limitation that we ran into was the .5TB limitation. I am not sure what the actual disk limitation is, or if there even is one. Burke -----Original Message----- From: Paul McGuinness (ext. 771) [mailto:Paul.McGuinness@fineos.com] Sent: Friday, August 20, 2004 9: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 **********************************************************************

2 1

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

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