toasters

toasters@lists.teaparty.net

13531 discussions

RE: /home layout with many filers and NIS automount
by Rainchik, Aleksandr (MED, Non GE) 17 Jan '01

17 Jan '01

There is another thing against > #auto_home NIS map > user1 filer2:/vol/vol1/& design. We have a lot of development servers. So any time you add/delete/modify a single user you should go trough _all_ the NIS/automount clients and run "automount" to let automountd know that passwd map has been just updated. Am I wrong again? Thank you. P.S. I know about rsh/ssh :) -----Original Message----- From: Jeffrey Krueger To: Rainchik, Aleksandr (MED, Non GE) Cc: toasters(a)mathworks.com Sent: 1/12/01 2:30 PM Subject: Re: /home layout with many filers and NIS automount On Fri, Jan 12, 2001 at 10:47:54AM -0600, Rainchik, Aleksandr (MED, Non GE) wrote: > Hello, > > I just need a word of advice on how to structure /home if you > use automount, have 5-10 home directory servers (NetApp filers) > and around 1000 users. Point of clarification: 5-10 filers for 1,000 users? What model filers are they and I hope they are serving other data besides homedirs! At one point we had about 15,000 home directories mostly on two NetApps - a F330 and a F540 - and they were pretty bored filers. One way to simplify your design would be to reduce the number of filers serving homedirs, especially for 1,000 users. Two good reasons to spread out homedirs are for bandwidth constraints and to spread risk/reduce points of failure. But if you have consistently high bandwidth between all users and filers than 2-4 homedir servers should be more than plenty mitigation of risk considering the cost of additional filers versus the additional benefit (considering NetApps impressive reliability). > I'm personally is looking for /home/homeserver-vol#/user-name > scheme, so my automount maps will be nice, small and manageble: > > #auto_home NIS map > filer1-0 filer1:/vol/vol0 > filer1-1 filer1:/vol/vol1 > ... > filer5-5 filer5:/vol/vol5 This is a very restrictive design because it makes homedir moves extremely conspicuous. It also flies a bit in the face of a large selling point of the automounter - eliminating host-based network paths. If a user is moved from one filer to another, or even from one volume to another, they will have a whole new path to their home directory. Worse yet, any scripts or application configurations which use the full path to their home directory will need to be re-coded or re-configured - YUK! Being able to "hide" the location of a home directory (or any other remote filesystem) is extremely useful. > But it seems like users prefer /home/username scheme and it leads > to 1000+ NIS automount map for /home, like > > #auto_home NIS map > user1 filer2:/vol/vol1/& > .... > user9999 filer3:/vol/vol4/& This is the way we do it, and the way I'd venture to guess most/many places do it. From the user perspective, it is very simple. From the admin perspective, it is easy to manage. We've found it to give maximum flexibility with minimum hassle. > Do you know if there is more elegant solution for this problem? Can you > tell me, what is your preference for /home layout? What do you mean by elegant? The above is pretty darned elegant, and for 1,000 users it should be easily manageable too. We currently have 10,223 home directories and we've got one big home directory map like above. It works great! One recommendation is you may want to use a script or database to help generate that automount map. The easiest way would be to write a shell/perl script that scanned all your "homedir" directories on each filer, ensured username uniqueness and then build the automount map. For added flexibility, we use a small database. Each row in the homedir table has the username (mountpoint under /home), the filer, and the path to their homedir. At some interval a script comes thru and builds the map. Hope this info helps! -- Jeff -- ------------------------------------------------------------------------ ---- Jeff Krueger, NetApp CA E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

4 5

6.0.1R1 Filerview -- How to print
by Darragh, Stephen J 17 Jan '01

17 Jan '01

I hope this is one of those questions that I will say "of course, why didn't I see that". 6.0.1R1 filerview running from netscape 4.7.5 on a sun solaris 8 system. There are now a great number of reports and disk information, but I can't see how to print them. There is no CTRL-P, or alt-click to bring up a print option. I could use xwd, but there must be a simple way that I am just missing. Thanks in advance... Stephen Darragh

1 0

ADV: Search Engine Registration
by mb6161＠arabia.com 17 Jan '01

17 Jan '01

Removal instructions below. I saw your listing on the internet. I work for a company that specializes in getting clients web sites listed as close to the top of the major search engines as possible. Our fee is only $29.95 per month to submit your site at least twice a month to over 350 search engines and directories. To get started and put your web site in the fast lane, call our toll free number below. Mike Bender 888-532-8842 To be removed call: 888-800-6339 X1377

1 0

ENTERPRISE EMAIL
by Joe Luchtenberg 17 Jan '01

17 Jan '01

There are a number of good threads in the toasters archives touching on large-scale e-mail implementation. My question is what other sites/newsgroups would you suggest are good primary resources for information/threads on enterprise e-mail? (I already have the Earthlink whitepaper from an earlier toasters thread) FWIW, the particular implementation under consideration is open to most anything at this time -- Exchange, sendmail, web-based, POP, etc. TIA. Joe Joe Luchtenberg Dataline, Inc. New number and email, please update: 757.858.0600 858.0606 fax joe.luchtenberg(a)data-line.com

3 3

Multicast support in ONTAP?
by Brian L. Brush 17 Jan '01

17 Jan '01

I'm experimenting with back-to-back (crossover) links between Sun boxes and filers. Specifically, I'm trying to use Solaris 8's IP network multipathing failover and fallback with such connections. The problem is that Solaris is unable to recognize the failure of a NIC directly connected to a filer. In testing, the feature works as expected on our normal switched network. Solaris's IP network multipathing failover and fallback (what a mouthful!) works by initially sending multicast ICMP echo requests (to ALL-SYSTEMS.MCAST.net). The Solaris box relies on routers and hosts to respond to the multicast requests. Then it sends periodic unicast ICMP echo requests to those specific routers/hosts and knows a NIC has failed when the responses stop. Snoop on the Solaris box reveals the filer is not responding to the multicast requests. The Solaris box, therefore, never even begins its monitoring because it thinks there is nothing to ping. Here is an excerpt: 192.168.0.5 -> ALL-SYSTEMS.MCAST.net ICMP Echo request (ID: 8194 Sequence number: 1) 192.168.0.5 -> ALL-SYSTEMS.MCAST.net ICMP Echo request (ID: 8194 Sequence number: 1) 192.168.0.5 -> ALL-SYSTEMS.MCAST.net ICMP Echo request (ID: 8194 Sequence number: 1) The filer is definitely sitting on the other end of the cable: ping -s 192.168.0.1 PING 192.168.0.1: 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=0. time=1. ms 64 bytes from 192.168.0.1: icmp_seq=1. time=0. ms 64 bytes from 192.168.0.1: icmp_seq=2. time=0. ms 64 bytes from 192.168.0.1: icmp_seq=3. time=0. ms Solaris box is an Ultra 1 with Solaris 8 10/00. Filer is an F760 running Data ONTAP 5.3.7. We've tested Sun ge to NetApp gigabit and also Sun hme to NetApp quad fast ethernet. I'm interested in hearing any suggestions that might make this configuration work. --Brian L. Brush Senior Systems Administrator Paradyne Corporation

2 1

RE: /home layout with many filers and NIS automount
by Premanshu Jain 16 Jan '01

16 Jan '01

Anybody using NDMP for NT. I need to backup NT servers on a P3000 which supports only NDMP. Where can we get NDMP for NT? prem Premanshu Jain Nortel Networks, Content Networks(Shasta) 2305, Mission College Blvd, Santa Clara, CA 95054 Direct: (408) 565-3573 ESN: 655-3573 eMail: prjain(a)shastanets.com Web: http://www.nortelnetworks.com/ipservices -----Original Message----- From: Rob Windsor [mailto:windsor@adc.com] Sent: Monday, January 15, 2001 12:45 PM To: toasters(a)mathworks.com Subject: Re: /home layout with many filers and NIS automount On Mon, 15 Jan 2001 10:37:38 PST, Jeffrey Krueger wrote: >> There is another thing against >> > #auto_home NIS map >> > user1 filer2:/vol/vol1/& >> design. We have a lot of development servers. So any time you >> add/delete/modify a single user you should go trough _all_ the >> NIS/automount clients and run "automount" to let automountd know >> that passwd map has been just updated. Am I wrong again? > This is correct, but I simple cron job which runs periodically on all NIS > clients should make short work of this task. =) Er? Solaris? That's one of the (few) beauties of NIS -- you don't have to go around telling everything that a map has changed. I've never gone machine-to-machine running automount(1) to kick it in the pants just because we changed the password or auto_home map. The _worst_ is that ncsd caches something and we need to kill and restart it. Rob++ ---------------------------------------- Rob Windsor E-Mail - mailto:rob_windsor@adc.com Senior Unix Systems Administrator Voice - phone:972-680-6919 Computer Services Fax - phone:972-680-0370 Broadband Access and Transport Group __o ADC Telecommunications _`\<,_ Richardson, TX 75082 (_)/ (_)

1 0

RE: /home layout with many filers and NIS automount
by Darragh, Stephen J 16 Jan '01

16 Jan '01

There are two types of automount maps (direct and indirect). I believe that direct maps are the ones that need to be signaled when a map changes. We have had to use direct maps for nested filesystem mounts, but do this only on an exception basis. See the O'Reilly book "Managing NFS and NIS" by Hal Stern. Hope this helps Stephen Darragh > -----Original Message----- > From: Rob Windsor [SMTP:windsor@adc.com] > Sent: Monday, January 15, 2001 3:45 PM > To: toasters(a)mathworks.com > Subject: Re: /home layout with many filers and NIS automount > > On Mon, 15 Jan 2001 10:37:38 PST, Jeffrey Krueger wrote: > > >> There is another thing against > >> > #auto_home NIS map > >> > user1 filer2:/vol/vol1/& > >> design. We have a lot of development servers. So any time you > >> add/delete/modify a single user you should go trough _all_ the > >> NIS/automount clients and run "automount" to let automountd know > >> that passwd map has been just updated. Am I wrong again? > > > This is correct, but I simple cron job which runs periodically on all > NIS > > clients should make short work of this task. =) > > Er? Solaris? That's one of the (few) beauties of NIS -- you don't have > to go around telling everything that a map has changed. > > I've never gone machine-to-machine running automount(1) to kick it in the > pants just because we changed the password or auto_home map. The _worst_ > is that ncsd caches something and we need to kill and restart it. > > Rob++ > ---------------------------------------- > Rob Windsor E-Mail - mailto:rob_windsor@adc.com > Senior Unix Systems Administrator Voice - phone:972-680-6919 > Computer Services Fax - phone:972-680-0370 > Broadband Access and Transport Group __o > ADC Telecommunications _`\<,_ > Richardson, TX 75082 (_)/ (_) >

1 0

inode limitation?
by Magnus Thorne 16 Jan '01

16 Jan '01

Greetings, I'm planning on using a NetApp 760 to store *many* small files. However, I'm getting vague answers from NetApp for my problem, so I figure I'd ask here. NetApp has told me that they don't recommend that I have more than 250,000 inodes per volume. Is this a real limitation, because my NetApps currently have 6.1 million inodes available? The online documentation says I only need to add more hard drives to get more inodes (1 per 32K). Has anyone used the netapp for small files? Small means millions of < 60K. Also, I need all these files available on one share. Also, what should I look out for? I know to disable the read ahead cache. I plan to not use snapshots. thanx, -Mag

4 3

FW: /home layout with many filers and NIS automount
by Rainchik, Aleksandr (MED, Non GE) 15 Jan '01

15 Jan '01

Basically, if it's indirect map, as auto_home, you don't need to kick "automount" on every client, but if it's direct map - you have to. -----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Monday, January 15, 2001 12:38 PM To: Rainchik, Aleksandr (MED, Non GE) Cc: 'Jeffrey Krueger '; 'toasters(a)mathworks.com ' Subject: Re: /home layout with many filers and NIS automount On Sat, Jan 13, 2001 at 03:16:20PM -0600, Rainchik, Aleksandr (MED, Non GE) wrote: > > There is another thing against > > #auto_home NIS map > > user1 filer2:/vol/vol1/& > design. We have a lot of development servers. So any time you > add/delete/modify a single user you should go trough _all_ the > NIS/automount clients and run "automount" to let automountd know > that passwd map has been just updated. Am I wrong again? This is correct, but I simple cron job which runs periodically on all NIS clients should make short work of this task. =) -- Jeff

1 0

Re: inode limitation?
by Ketil Kirkerud Elgethun 15 Jan '01

15 Jan '01

Magnus Thorne <Magnus.Thorne(a)evoice.com> writes: > NetApp has told me that they don't recommend that I have more than 250,000 > inodes per volume. Are you sure you're not confusing this with "per directory" ? Even though WAFL is fairly efficient when it comes to large directories, there are limits to what you would want to experience.. > Is this a real limitation, because my NetApps currently > have 6.1 million inodes available? Neo, it's not. This is a 760: df Filesystem kbytes used avail capacity Mounted on /vol/vol0/ 343184120 265805356 77378764 77% /vol/vol0/ df -i Filesystem iused ifree %iused Mounted on /vol/vol0/ 13987164 6012814 70% /vol/vol0/ And it's running just fine (mailspool with one file per message) > The online documentation says I only > need to add more hard drives to get more inodes (1 per 32K). You can have 1 inode per 4K, IIRC. > Has anyone > used the netapp for small files? Small means millions of < 60K. Also, I > need all these files available on one share. As you can see: yes, no problems. > > Also, what should I look out for? I know to disable the read ahead cache. I'm not sure that would help a lot with small files - this is more of a win wit large files (or possible very slow clients) > I plan to not use snapshots. Whether or not to use snapshots is more a question of the change rate in your data set than the number of files - the 760 shown above is running with readahead set, and snapshots. No problems whatsoever. Regards, -- ---Ketil Kirkerud Elgethun, Infostream ASP

1 0

RE: inode limitation?
by Toal, Dave 15 Jan '01

15 Jan '01

Jim, The website I fix uses very small files to handle details of customer events so they can be billed. One file per event. I'm not saying this is a good design. <chuckle> smith> maxfiles spool Volume spool: maximum number of files is currently 8258829 (1428275 used). smith> df -i /vol/spool Filesystem iused ifree %iused Mounted on /vol/spool/ 1428275 6830554 17% /vol/spool/ smith> df /vol/spool Filesystem kbytes used avail capacity Mounted on /vol/spool/ 46944924 14936040 32008884 32% /vol/spool/ /vol/spool/.snapshot 0 7834048 0 ---% /vol/spool/.snapshot smith> How come it's not "maxfiles /vol/spool" -- different coders? Dave -----Original Message----- From: Jim VandeVegt To: Magnus Thorne; 'toasters(a)mathworks.com' Sent: 1/15/01 2:38 PM Subject: Re: inode limitation? --- Magnus Thorne <Magnus.Thorne(a)evoice.com> wrote: > NetApp has told me that they don't recommend that I have more than > 250,000 > inodes per volume. Is this a real limitation, because my NetApps > currently > have 6.1 million inodes available? The online documentation says I > only > need to add more hard drives to get more inodes (1 per 32K). Has > anyone > used the netapp for small files? Small means millions of < 60K. > Also, I > need all these files available on one share. The training I received from NetApp personnel indicated that a particular strength of WAFL is the ability to add more inodes on the fly. There wasn't any mention of any particular recommended limit. A quick check of my system shows that even my smallest volumes currently have "Maximum Numer of Files" set over 1 million. On a 760, one volume with 330 GB of data space, 13 million on MAX files, 550 thousand currently. Another with 150 GB of data space, 6 million on MAX files, 414 thousand currently. As far as I know, no one at our site purposely expanded any of the MAX settings. ===== Jim VandeVegt vandevegt(a)yahoo.com vandevegt(a)avaya.com http://members.xoom.com/vandevegt Toilet paper should come off the front! __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/

1 0

solaris 2.6 nfs client tuning?
by Toal, Dave 15 Jan '01

15 Jan '01

Hey, all. This lots-of-nfs-mounts topic inspires me to ask yet another sanity-check question: Currently I'm fixing a process which moves lots of data from one vol to another. Can't simply vol copy because there are things I can't over-write on the destination. This data is in about 40 directories, with maybe 2G in each. The method I'm using is to set up many pairs of mounts, one for each directory, all from the same two vols. This is because the nfs client, a sun 450 running solaris 2.6, shows huge lag for ls, cp, whatever, in a mounted directory where a cp is already running. iostat shows the nfsd devices at 100% busy -- for destination and source -- when a cp runs between a mount-point pair. So: filer1:/vol/A/d1 /mnt/A_01 filer2:/vol/B/d1 /mnt/B_01 filer1:/vol/A/d2 /mnt/A_02 filer2:/vol/B/d2 /mnt/B_02 filer1:/vol/A/d3 /mnt/A_03 filer2:/vol/B/d3 /mnt/B_03 ad nauseum... and if I cp /mnt/A_01/fatfile to /mnt/B_01 then there's no i/o lag whatsoever in /mnt/A_02. These filers are 760's, by the way. Then I discovered a serious "sweet spot" at a very low number. "max" is the number of simultaneous copies between mount point pairs. "k/sec" are my visual estimates of _each_ cp rate, from watching iostat for about a minute; rates jump around by +- 100 k/sec. Column on the right is total throughput for all cp. max=3 ~ 2300 k/sec |= 6900 max=4 ~ 1800 k/sec |= 7200 max=5 ~ 1500 k/sec |= 7500 max=6 ~ 1200 k/sec |= 7200 max=8 ~ 800 k/sec |= 6400 max=9 ~ 800 k/sec |= 7200 max=10 ~ 600 k/sec |= 6000 I've seen much higher data rates from the 760's. So I'm thinking this means I need to learn nfs client tuning for solaris. Yes? Dave -- dave toal systems optimist Thomson & Thomson N. Quincy, MA -----Original Message----- From: Jeffrey Krueger To: Rainchik, Aleksandr (MED, Non GE) Cc: 'Jeffrey Krueger '; 'toasters(a)mathworks.com ' Sent: 1/15/01 1:37 PM Subject: Re: /home layout with many filers and NIS automount On Sat, Jan 13, 2001 at 03:16:20PM -0600, Rainchik, Aleksandr (MED, Non GE) wrote: > > There is another thing against > > #auto_home NIS map > > user1 filer2:/vol/vol1/& > design. We have a lot of development servers. So any time you > add/delete/modify a single user you should go trough _all_ the > NIS/automount clients and run "automount" to let automountd know > that passwd map has been just updated. Am I wrong again? This is correct, but I simple cron job which runs periodically on all NIS clients should make short work of this task. =) -- Jeff

1 0

Re: inode limitation?
by Jim VandeVegt 15 Jan '01

15 Jan '01

--- Magnus Thorne <Magnus.Thorne(a)evoice.com> wrote: > NetApp has told me that they don't recommend that I have more than > 250,000 > inodes per volume. Is this a real limitation, because my NetApps > currently > have 6.1 million inodes available? The online documentation says I > only > need to add more hard drives to get more inodes (1 per 32K). Has > anyone > used the netapp for small files? Small means millions of < 60K. > Also, I > need all these files available on one share. The training I received from NetApp personnel indicated that a particular strength of WAFL is the ability to add more inodes on the fly. There wasn't any mention of any particular recommended limit. A quick check of my system shows that even my smallest volumes currently have "Maximum Numer of Files" set over 1 million. On a 760, one volume with 330 GB of data space, 13 million on MAX files, 550 thousand currently. Another with 150 GB of data space, 6 million on MAX files, 414 thousand currently. As far as I know, no one at our site purposely expanded any of the MAX settings. ===== Jim VandeVegt vandevegt(a)yahoo.com vandevegt(a)avaya.com http://members.xoom.com/vandevegt Toilet paper should come off the front! __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/

1 0

Re: /home layout with many filers and NIS automount
by Jim VandeVegt 15 Jan '01

15 Jan '01

--- Andrew Steingruebl <steingra(a)pprd.abbott.com> wrote: > "Rainchik, Aleksandr (MED, Non GE)" said: > > > > >Speaking about this case: > >> > >> #auto_home NIS map > >> user1 filer2:/vol/vol1/& > >> .... > >> user9999 filer3:/vol/vol4/& > > > >What I'm afraid of, is that if you have 200 users > >logged in your box, you will have 200 mountpoints, > >one mountpoint per each holy user!!! I really feel > >bad about it. Am I wrong? In the Solaris /etc/auto_home file you can specify an additional colon in the directory path to indicate the highest exported directory, and the automounter will use some sort of symbolic link such that only one connection per exported file system will result. A 'df- k', however, might still show you all the connections, I haven't tested with a large number as of yet. The syntax for /etc/auto_home for the above example would then be: user0001 filer2:/vol/vol1:& user9999 filer3:/vol/vol4:& Assuming you have /vol/vol? exported on the Filers. ===== Jim VandeVegt vandevegt(a)yahoo.com vandevegt(a)avaya.com http://members.xoom.com/vandevegt Toilet paper should come off the front! __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/

1 0

RE: /home layout with many filers and NIS automount
by Rainchik, Aleksandr (MED, Non GE) 15 Jan '01

15 Jan '01

Speaking about this case: > > #auto_home NIS map > user1 filer2:/vol/vol1/& > .... > user9999 filer3:/vol/vol4/& What I'm afraid of, is that if you have 200 users logged in your box, you will have 200 mountpoints, one mountpoint per each holy user!!! I really feel bad about it. Am I wrong? -----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Friday, January 12, 2001 2:31 PM To: Rainchik, Aleksandr (MED, Non GE) Cc: toasters(a)mathworks.com Subject: Re: /home layout with many filers and NIS automount On Fri, Jan 12, 2001 at 10:47:54AM -0600, Rainchik, Aleksandr (MED, Non GE) wrote: > Hello, > > I just need a word of advice on how to structure /home if you > use automount, have 5-10 home directory servers (NetApp filers) > and around 1000 users. Point of clarification: 5-10 filers for 1,000 users? What model filers are they and I hope they are serving other data besides homedirs! At one point we had about 15,000 home directories mostly on two NetApps - a F330 and a F540 - and they were pretty bored filers. One way to simplify your design would be to reduce the number of filers serving homedirs, especially for 1,000 users. Two good reasons to spread out homedirs are for bandwidth constraints and to spread risk/reduce points of failure. But if you have consistently high bandwidth between all users and filers than 2-4 homedir servers should be more than plenty mitigation of risk considering the cost of additional filers versus the additional benefit (considering NetApps impressive reliability). > I'm personally is looking for /home/homeserver-vol#/user-name > scheme, so my automount maps will be nice, small and manageble: > > #auto_home NIS map > filer1-0 filer1:/vol/vol0 > filer1-1 filer1:/vol/vol1 > ... > filer5-5 filer5:/vol/vol5 This is a very restrictive design because it makes homedir moves extremely conspicuous. It also flies a bit in the face of a large selling point of the automounter - eliminating host-based network paths. If a user is moved from one filer to another, or even from one volume to another, they will have a whole new path to their home directory. Worse yet, any scripts or application configurations which use the full path to their home directory will need to be re-coded or re-configured - YUK! Being able to "hide" the location of a home directory (or any other remote filesystem) is extremely useful. > But it seems like users prefer /home/username scheme and it leads > to 1000+ NIS automount map for /home, like > > #auto_home NIS map > user1 filer2:/vol/vol1/& > .... > user9999 filer3:/vol/vol4/& This is the way we do it, and the way I'd venture to guess most/many places do it. From the user perspective, it is very simple. From the admin perspective, it is easy to manage. We've found it to give maximum flexibility with minimum hassle. > Do you know if there is more elegant solution for this problem? Can you > tell me, what is your preference for /home layout? What do you mean by elegant? The above is pretty darned elegant, and for 1,000 users it should be easily manageable too. We currently have 10,223 home directories and we've got one big home directory map like above. It works great! One recommendation is you may want to use a script or database to help generate that automount map. The easiest way would be to write a shell/perl script that scanned all your "homedir" directories on each filer, ensured username uniqueness and then build the automount map. For added flexibility, we use a small database. Each row in the homedir table has the username (mountpoint under /home), the filer, and the path to their homedir. At some interval a script comes thru and builds the map. Hope this info helps! -- Jeff -- ------------------------------------------------------------------------ ---- Jeff Krueger, NetApp CA E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

3 2

Can volumes span FCAL controllers?
by Matt Phelps 13 Jan '01

13 Jan '01

Hi, We're probably going to ba adding another FCAL controller to our 840 soon. Can volumes include disks that are on both controllers? -- Matt Phelps System Administrator, Computation Facility Harvard - Smithsonian Center for Astrophysics mphelps(a)cfa.harvard.edu, http://cfa-www.harvard.edu/~mphelps

6 9

/home layout with many filers and NIS automount
by Rainchik, Aleksandr (MED, Non GE) 13 Jan '01

13 Jan '01

Hello, I just need a word of advice on how to structure /home if you use automount, have 5-10 home directory servers (NetApp filers) and around 1000 users. I'm personally is looking for /home/homeserver-vol#/user-name scheme, so my automount maps will be nice, small and manageble: #auto_home NIS map filer1-0 filer1:/vol/vol0 filer1-1 filer1:/vol/vol1 ... filer5-5 filer5:/vol/vol5 But it seems like users prefer /home/username scheme and it leads to 1000+ NIS automount map for /home, like #auto_home NIS map user1 filer2:/vol/vol1/& .... user9999 filer3:/vol/vol4/& Do you know if there is more elegant solution for this problem? Can you tell me, what is your preference for /home layout? Thank you. -- Aleksandr Rainchik, SUN CSA

6 5

RE: F7XX systems; 18gb and 36gb disks/shelves
by Conley, Mark 12 Jan '01

12 Jan '01

FYI on the used equipment, none of the software licenses on Netapp equipment are transferable. Which means you are paying for hardware only! Mark Conley -----Original Message----- From: ScottUCE(a)aol.com [mailto:ScottUCE@aol.com] Sent: Friday, January 12, 2001 3:09 PM To: toasters(a)mathworks.com Subject: FS: F7XX systems; 18gb and 36gb disks/shelves Available NetApp equipment includes: F720 F740s - Qty 8 F760s - Qty 4 18gb disk shelves/drives 36gb disk shelves/drives Spares kits Lots of older NetApp stuff -- systems, add-ons and parts We'd be delighted to hear from you should you have any interest. Scott Fischmann Union Computer Exchange, Inc. 6233 Idylwood Lane Minneapolis, MN 55436 Phone: 952 935 7282 www.unioncomputer.com

1 0

FS: F7XX systems; 18gb and 36gb disks/shelves
by ScottUCE＠aol.com 12 Jan '01

12 Jan '01

Available NetApp equipment includes: F720 F740s - Qty 8 F760s - Qty 4 18gb disk shelves/drives 36gb disk shelves/drives Spares kits Lots of older NetApp stuff -- systems, add-ons and parts We'd be delighted to hear from you should you have any interest. Scott Fischmann Union Computer Exchange, Inc. 6233 Idylwood Lane Minneapolis, MN 55436 Phone: 952 935 7282 www.unioncomputer.com

1 0

RE: backup for f760
by Davis, John 12 Jan '01

12 Jan '01

You should definitely add the BakBone backup s/w (ndmp version) to your short list..I just installed and set it up today pointing at a SL Bullfrog 10K..got about 10mb/sec (ave) backing up an Oracle database..very easy to install and much easier to learn to use.. -----Original Message----- From: Jeff Bryer [mailto:bryer@sfu.ca] Sent: Friday, January 12, 2001 2:37 PM To: nlehrer(a)ibb.gov Cc: toasters(a)mathworks.com; ch(a)ibb.gov Subject: Re: backup for f760 We've recently purchased an AIT-2 library (Spectralogic Gator 64000) which we are still testing out and evaluating software on before putting into production. We have some DLT-7000 drives around the place, and have been replacing them fairly regularly due to problems that we chose not to purchase another DLT-7000 based library. Based on feedback from this list, we're not even considering Legato's Networker (for it's poor quality in NDMP support). We've been focusing on Syncsort Backup Express, Quadratec Time Navigator and Veritas NetBackup Data Center. > i need to backup our f760, currently about 200GB. i will be testing legato > networker [we already use it] with ndmp and need to decide on a tape system. i > am open to either dlt7000 or ait-2 based stacker solutions. what are people > happy with? > -- Jeff Bryer bryer(a)sfu.ca Systems Administrator (604) 291-4935 Academic Computing, Simon Fraser University

1 0

backup for f760
by neil lehrer 12 Jan '01

12 Jan '01

hi, i need to backup our f760, currently about 200GB. i will be testing legato networker [we already use it] with ndmp and need to decide on a tape system. i am open to either dlt7000 or ait-2 based stacker solutions. what are people happy with? thanks

2 1

Re: /home layout with many filers and NIS automount
by Paul Wiltsey 12 Jan '01

12 Jan '01

Large maps are not that bad to manage... I vote for: user1 filer2:/vol/vol1/& .... user9999 filer3:/vol/vol4/& That is how we do it anyway. ----- Original Message ----- From: "Rainchik, Aleksandr (MED, Non GE)" <Aleksandr.Rainchik(a)med.ge.com> Date: Friday, January 12, 2001 11:47 am Subject: /home layout with many filers and NIS automount > Hello, > > I just need a word of advice on how to structure /home if you > use automount, have 5-10 home directory servers (NetApp filers) > and around 1000 users. > > I'm personally is looking for /home/homeserver-vol#/user-name > scheme, so my automount maps will be nice, small and manageble: > > #auto_home NIS map > filer1-0 filer1:/vol/vol0 > filer1-1 filer1:/vol/vol1 > ... > filer5-5 filer5:/vol/vol5 > > > But it seems like users prefer /home/username scheme and it leads > to 1000+ NIS automount map for /home, like > > #auto_home NIS map > user1 filer2:/vol/vol1/& > .... > user9999 filer3:/vol/vol4/& > > Do you know if there is more elegant solution for this problem? Can > youtell me, what is your preference for /home layout? > > Thank you. > > -- Aleksandr Rainchik, SUN CSA > >

1 0

RE: performance problem on a 740
by Knight, Jason 12 Jan '01

12 Jan '01

Are you using SnapMirror on these F740's? -----Original Message----- From: Bertrand HUTIN [mailto:bertrand_hutin@amdahl.com] Sent: Friday, January 12, 2001 9:32 AM To: toasters(a)mathworks.com; vitar_dalloken(a)amdahl.com Subject: performance problem on a 740 On one of my customer's 740 filer, the average load is 72% and reached 100%, with OPS around 200 to 400. On another one with about the same OPS, the average load is 42%. Net and disk input/output is almost the same on both filers. what could be wrong?

1 0

RE: Can volumes span FCAL controllers?
by Mankovsky, Mike 12 Jan '01

12 Jan '01

My apologies for this response. It was intended for a different mail thread. Mike -----Original Message----- From: Mankovsky, Mike [mailto:mike.mankovsky@netapp.com] Sent: Friday, January 12, 2001 8:06 AM To: 'Chris Thompson'; scl(a)sasha.acc.virginia.edu Cc: sirbruce(a)ix.netcom.com; jason.santos(a)onsemi.com; mphelps(a)cfa.harvard.edu; toasters(a)mathworks.com Subject: RE: Can volumes span FCAL controllers? I don't see the reason to get Jess involved at this point. Mike -----Original Message----- From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] Sent: Friday, January 12, 2001 7:45 AM To: scl(a)sasha.acc.virginia.edu Cc: sirbruce(a)ix.netcom.com; jason.santos(a)onsemi.com; mphelps(a)cfa.harvard.edu; toasters(a)mathworks.com Subject: Re: Can volumes span FCAL controllers? Steve Losen <scl(a)sasha.acc.virginia.edu> wrote: > [in response to Bruce Sterling Woodcock <sirbruce(a)ix.netcom.com>] > > > > > That's not entirely true -- you can span a volume across controllers, > > > just dont span RAID groups across controllers. > > > > When a volume has 2 RAID groups, is the NVRAM split among > > RAID groups? How are CPs done? > [ Good introduction to consistency points for newbies ] > > So in answer to your question, the NVRAM is shared by all volumes > and raid groups because it is a log of incoming write requests, > not a disk buffer cache. But to resume the original thread, the question is whether or not the writes done as part of CPs are clustered in a way that helps to reduce the overheads of switching between FCAL controllers. CPs for different volumes are logically distinct operations, but are in practice synchronised, either by the 10-second clock or by NVRAM filling up. In saying that one should avoid spreading a volume over multiple controllers, but can have different volumes on different controllers, the assumption is that writes (mostly) occur first to one volume, then to another. If the same is to apply to RAID groups, then the assumption is that the writes associated with taking a CP on a single volume are (mostly) clustered by RAID group. This sounds entirely reasonable, given that the filer tries to write whole stripes, or at least stripes in which as many planes as possible are being updated. Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.

1 0

RE: Can volumes span FCAL controllers?
by Mankovsky, Mike 12 Jan '01

12 Jan '01

I don't see the reason to get Jess involved at this point. Mike -----Original Message----- From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] Sent: Friday, January 12, 2001 7:45 AM To: scl(a)sasha.acc.virginia.edu Cc: sirbruce(a)ix.netcom.com; jason.santos(a)onsemi.com; mphelps(a)cfa.harvard.edu; toasters(a)mathworks.com Subject: Re: Can volumes span FCAL controllers? Steve Losen <scl(a)sasha.acc.virginia.edu> wrote: > [in response to Bruce Sterling Woodcock <sirbruce(a)ix.netcom.com>] > > > > > That's not entirely true -- you can span a volume across controllers, > > > just dont span RAID groups across controllers. > > > > When a volume has 2 RAID groups, is the NVRAM split among > > RAID groups? How are CPs done? > [ Good introduction to consistency points for newbies ] > > So in answer to your question, the NVRAM is shared by all volumes > and raid groups because it is a log of incoming write requests, > not a disk buffer cache. But to resume the original thread, the question is whether or not the writes done as part of CPs are clustered in a way that helps to reduce the overheads of switching between FCAL controllers. CPs for different volumes are logically distinct operations, but are in practice synchronised, either by the 10-second clock or by NVRAM filling up. In saying that one should avoid spreading a volume over multiple controllers, but can have different volumes on different controllers, the assumption is that writes (mostly) occur first to one volume, then to another. If the same is to apply to RAID groups, then the assumption is that the writes associated with taking a CP on a single volume are (mostly) clustered by RAID group. This sounds entirely reasonable, given that the filer tries to write whole stripes, or at least stripes in which as many planes as possible are being updated. Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.

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