toasters

toasters@lists.teaparty.net

13514 discussions

Automatización de Procesos - Calidad ISO
by Gestion documental - Su empresa sin papel 03 Mar '05

03 Mar '05

www.gitdoc.com <http://www.gitdoc.com> Somos líderes en el desarrollo y personalización de soluciones integrales de gestión documental y automatización de procesos "workflow", adaptadas a procesos específicos de negocio. Nuestra propuesta de valor: GIT-DOC se ha desarrollado como una potente herramienta de gestión documental que permite parametrizar cualquier necesidad a la hora de estructurar documentos, gestionar contenidos o automatizar procesos con ilimitados requerimientos. Consultoría Gestión documental Workflow Gestión de contenidos Soluciones: Registro de entrada-salida Recortes de prensa Pedidos-Albaranes-Facturas Gestión de expedientes Pymes, Clínicas, Abogados Servicios: Digitalización de documentos Grabación de índices Archivo y custodia Ofrecemos distribución Nicolás Mendoza Tel.: 629 80 34 34 - 902 999 073 www.gitdoc.com <http://www.gitdoc.com> gitdoc(a)gitdoc.com <mailto:gitdoc@gitdoc.com> AVISO LEGAL Le recordamos que su cta. de e-mail figura registrada en nuestra base de datos al confirmar su deseo de recibir nuestras ofertas. Dicha información será tratada de forma totalmente confidencial con arreglo a la nueva ley L.S.S.I. y no será vendida ni traspasada a terceros en ningún caso. Si Vd. recibe este e-mail debido algún error o no es su deseo recibir mas e-mail nuestros, puede darse de baja de forma inmediata, simplemente pulsanso sobre B O R R A R <http://ias.cadema-gitdoc.com/webapp/servlet/Sborrar?email=toasters@math works.com>

1 0

RE: converting root volume to flexvol
by Palmer, Jason (EMEA) 02 Mar '05

02 Mar '05

Hi Adam, I successfully moved to a root volume on a flexible volume within an aggregate last week without any problems... I used ndmpcopy from the command line of the filer and followed the steps below - 1. Create the Aggregate (In our case a 3 disk root aggregate called AGGR) 2. Create new flexible root volume within that aggregate (I called this rootnew as we already have a root volume) 3. NDMPCOPY -l 0 -f <filer>:/vol/root/etc <filer>:/vol/newroot/etc 4. aggr options aggr root <-- To set the aggr aggregate to the root aggregate 5. vol options newroot root <-- To set the rootnew volume to the root volume 6. Reboot the filer and verify everything comes back up OK (If not you can boot in maintenance mode to reset the root volume) 7. Check that newroot in aggr is the root volume using vol status 8. If this is the case, rename root volume to rootold and rootnew to root 9. Use vol offline rootold to ofline the old root volume and if 100% happy use the vol destroy Worked fine for us - I only used the NetApp KB as a guideline. I have another 5 machines to convert in the same way - I was lucky, as the first system I did was not storing production data so there were plenty of disks and no pressure of system downtime to consider. I hope this helps, Jason Palmer Storage Architecture MCI EMEA -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Adam McDougall Sent: 02 March 2005 12:37 To: toasters(a)mathworks.com Subject: converting root volume to flexvol I am asking the list because documentation on this process seems to be inconsistant or light in nature on the NOW website. Background: When we setup our Filer, vol0 spanned 24 data disks and contained "etc". The original filer, an F820, booted from this. We've since upgraded to FAS940 and Data ONTAP 7.0 and I want to migrate root to a flexvol. We also have a new disk shelf, so I set it up as aggr0 and already have some production flexvols running from it for data. I created a flexvol named root on aggr0. I want to move the root from vol0 to this new flexvol so I can destroy vol0 (which is larger now and has no remaining production qtrees) and create a second aggregate with the 3 disk shelves that would be freed. Problem: Several articles, such as Solution ID: kb5856 make it sound like you need to copy etc into /aggr0/newvol instead of /vol/newvol. It also demonstrates that the newly created /vol/newvol appears empty after this. Why would you do it that way? Is it an ndmpcopy/rootvol thing that you would want to do this? I have successfully migrated normal data from traditional volumes to flex volumes using various combinations of ndmpcopy, tar, and rsync. Copies that complete successfully work fine. Other articles such as Solution ID: kb5634 make the procedure sound simpler yet more vague: "1. From an Admin host that has access to both traditional vol0 and the new root volume copy the entire /etc directory over to the new volume. " This I can easily handle, but I want to be fairly certain that it will actually boot from the new root vol after doing "vol options root root". I also want to put boot files on the new aggr/root disks so I can boot from that shelf incase I need to replace my compactflash card. Would 'download' do the right thing and place the boot files on the new disk shelf as long as I have set "vol options root root"? Has anyone done something similar, and how large did you make your new root volume? NetApp webpages have widely varying examples varying from 14g to recommendations of 30g or 90g. Our /etc is only 0.25 gigs and I wouldn't expect coredumps to consume more disk space than the filer has memory, and if my filer decides to start coredumping frequently then I will be thinking about the disk space and expanding it, since I can.

1 0

converting root volume to flexvol
by Adam McDougall 02 Mar '05

02 Mar '05

I am asking the list because documentation on this process seems to be inconsistant or light in nature on the NOW website. Background: When we setup our Filer, vol0 spanned 24 data disks and contained "etc". The original filer, an F820, booted from this. We've since upgraded to FAS940 and Data ONTAP 7.0 and I want to migrate root to a flexvol. We also have a new disk shelf, so I set it up as aggr0 and already have some production flexvols running from it for data. I created a flexvol named root on aggr0. I want to move the root from vol0 to this new flexvol so I can destroy vol0 (which is larger now and has no remaining production qtrees) and create a second aggregate with the 3 disk shelves that would be freed. Problem: Several articles, such as Solution ID: kb5856 make it sound like you need to copy etc into /aggr0/newvol instead of /vol/newvol. It also demonstrates that the newly created /vol/newvol appears empty after this. Why would you do it that way? Is it an ndmpcopy/rootvol thing that you would want to do this? I have successfully migrated normal data from traditional volumes to flex volumes using various combinations of ndmpcopy, tar, and rsync. Copies that complete successfully work fine. Other articles such as Solution ID: kb5634 make the procedure sound simpler yet more vague: "1. From an Admin host that has access to both traditional vol0 and the new root volume copy the entire /etc directory over to the new volume. " This I can easily handle, but I want to be fairly certain that it will actually boot from the new root vol after doing "vol options root root". I also want to put boot files on the new aggr/root disks so I can boot from that shelf incase I need to replace my compactflash card. Would 'download' do the right thing and place the boot files on the new disk shelf as long as I have set "vol options root root"? Has anyone done something similar, and how large did you make your new root volume? NetApp webpages have widely varying examples varying from 14g to recommendations of 30g or 90g. Our /etc is only 0.25 gigs and I wouldn't expect coredumps to consume more disk space than the filer has memory, and if my filer decides to start coredumping frequently then I will be thinking about the disk space and expanding it, since I can.

1 0

Save yourself from Gal Bladder (Kidney Stone)
by Citizen Welfare Organisation 01 Mar '05

01 Mar '05

Following is the article extracted from dawn (28/02/05) KARACHI: Reduction in tea urged to check stone formation - Urolithiasis symposium concludes KARACHI, Feb 27: Health experts at a symposium on Sunday recommended that tea and coffee should be reduced and dark-coloured soft drinks, aerated drinks and alcohol should be avoided to prevent formation of urinary stones. They were speaking at the concluding session of three-day urolithiasis symposium, organized by the Sindh Institute of Urology Transplant in association with the European Urolithiasis Society. During the panel discussion on "Are urinary stones preventable?" health professional said that excess oxalates in diet, less fluid intake particularly in hot climate, and warm working environment were common risk factors for stone formation in the urinary tract. Panellists of the session were Dr S.R. Khan from the USA, Dr A. Rodgers from S. Africa, Dr P.N. Rao from the United Kingdom, Dr A. Hesse from Germany, Dr K. Sarica from Turkey, Dr F. Marickar from India, Dr D. Gohel from Hong Kong, Dr N. Laube from Germany, Dr P. Shrivastav from India and Dr Adibul Hasan Rizvi. Dr A. Naqvi was the moderator. The joint consensus was that recurrence of stones in a person having had stone disease could be decreased. "General recommendations are that fluid intake should be sufficient to make the urine of a light colour. Plain water, barley water and rice water are beneficial. Yoghurt is also beneficial as it helps to disintegrate bacteria," they said. Earlier, describing the history of urinary tract stone disease, Dr F.A. Khan from Lahore stated that Andersen in 1932 had described southern Punjab as the hot spot for kidney stones. Reporting the results of a survey on bladder stone among children in Punjab, he said that the age at onset was as low as one year, while it was also observed that in Northern Punjab upper tract stones were higher in incidence, whereas in Southern Punjab bladder stones were more common. "Bladder stones in children are closely linked with poverty and diarrhoeal disease," he added. Dr M.D.I. Gohel from Hong Kong discussed whether kidney stones be eradicated by herbal medicines. He delivered an interesting talk on Chinese kampou medicine, being used to inhibit calcium oxalate crystallization. He said that experimental studies had proved that herbal medicines contained substances, which could prevent calcium oxalate aggregation and growth. This could prevent renal stone formation and help to expel the crystal easily, he added. Dr Fazil Marickar from India said that plant extracts, especially scoparia dulcis, had proved very successful in clearing renal injuries produced by oxalate crystals. "Substances as tamarind, plantain stem and horse gram help in passage, reduction of size and movement of stones," he added. Talking on ethnobotanic approaches towards treatment of stone disease, Dr I. Chaudhry said that it was conversion of a natural product into a useful substance. He predicted that in future food fossils would be consumed in larger quantities and research on them would help in using them as therapy for many diseases. Discussing the metabolic aspects of stone disease, Dr Shrivastav from India said that low urinary volume, low citrate and high uric acid levels in urine had been observed in significantly large number of patients with renal stones. "These factors could be taken as predictors for stone formation in the future," he added. -PPI This is a public welfare message and sent one time any ways if u want to unsubscribe then send an email with a subject remove to removemefromlist(a)gawab.com If you want to send your offer to 500,000 peoples then email at khimarketing(a)gawab.com

1 0

RE: Quick access to quota information
by barrie_spence＠agilent.com 28 Feb '05

28 Feb '05

I've just been busy writing a script to manage and enforce quotas the "UNIX way" (i.e. lock down the quota at the soft limit if the user doesn't cleanup within 14 days of exceeding it). The CPAN Perl "Quota" module works a treat: use Quota; $host='filer'; $volume_path = '/vol/vol1/users'; $uid = 501; ($block_curr, $block_soft, $block_hard, $block_timelimit, $inode_soft, $inode_hard, $inode_timelimit) = Quota::rpcquery($host, $volume_path, $uid); It's pretty fast and appears to work on HP-UX, Solaris and Linux. The only thing you have to watch for is that the results are low while the quotas are resizing (easy to check with a SNMP query). Regards, Barrie -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Jacek Nogala Sent: 21 February 2005 09:36 To: toasters(a)mathworks.com Subject: Quick access to quota information The landscape: - The company is cable tv providing also Internet services - They intend to use FAS920 in NFS environment (all servers are Linux) - At this very moment they are servicing about 80k users but wanting to be able to service more that 200k - Services for users are to be implemented with UID and GID quotas Requirements: - They need to be able to retrieve quickly information about current quota usage for each specific UID or GID. - The information will be available via: -- Call Center - estimated queries 12 times per minute -- WEB GUI for users - estimated queries 120 times per minute - The quota information should be retrieved within 2 s and should be not older than 30 s - There is not specific requirements regarding method of getting the result (SNMP/RSH/NFS RPC/HTTP are acceptable) We discussed with them SNMPwalk and quota report parsing but they cannot accept it due to high and growing number of users. The most convenient way would be short series of SNMP queries for specific UID / GID. Any suggestions other than "make and parse quota report" are welcome. Best regards, Jacek

2 1

full volume performance
by Charles Bartels 28 Feb '05

28 Feb '05

Hi Folks, It is pretty well know that disk performance start to suffer when the partition begins to fill up. So I am wondering if you would see the same effect with a full volume (traditional or flexible) in a relatively empty aggregate, or a full qtree in a relatively empty volume? Any thoughts on the matter would be appreciated. -C.

2 1

RE: F720 head upgrade?
by Jeff Mohler 28 Feb '05

28 Feb '05

You have some NFS tuning to do in TCP, UDP is fine. This isnt your root problem, but it cant help. Check the output regarding TCP receive buffer sizes. Client vancouver has network problems, NFS retransmits. Check output. Doesnt harm the system, but that client is impacted. Youre fighting performance -vs- storage space. You have a number of 18 and 36G drives. Vol0 is laid out properly given this mix, you dont mix sizes within a given raid group. However disks 16, 18, and 19 are on their own as the raid group of 36G drives for this volume. They are also being beat on pretty hard. I see that your cache hits are 100%, this would cause you to wonder if you need a larger filer, more cache RAM..but that might not be it. You have 100% disk utilization as a fact of life on the system, but you are only doing disk reads for the most part, and NOT heavy ones. Nine to 12Mb/sec max. Thats danged odd. Heres your problem. Vol0. The 18G drives are about 65% busy, 95% reads. The 36G drives are 83% bush, again mostly reads. Vol1 is quiet as a church on bowling night. Solutions: Move data being accessed from vol0 to vol1, make use of the untilized performance you have there if this 60 seconds of history is a normal data activity. Likewise, move some of that date from vol1 to vol0, because you never want over 80% full volumes. ;) Rebuild your volumes. Make vol0 all of the 18G drives, 11data-1parity. Raw about 204Mb. Make vol1 all of the 36G drives, 6data-1parity. Raw about 207Mb. If you did this, your volume sizes would be larger than they are today, because youre not wasting space on mixed sized raid groups of 18 and 36G drives (vol1 is like this), and you end up with a LARGER number of spindles to parellelize your data access across in vol0 with a single volume of more 18G drives. Guaranteed, 100% of your performance problem is that itty bitty second raid group in volume 1. Unfortunately you will have to destroy the village to save it, but once you take the downtime to do so, you might find years of worthwhile performance out of your 720. Of course, you get to play God at work, and save a ton of cash while making thing better with no money spent. Yes, a larger system might reduce the missed cache hits, but 12Mb/sec is WAY less than a properly configured F720 can dish out. Id say you could triple that output easy if you did this. Is a 12drive raid group ok?? Id say YES. ONTAP is wayyyy more resilient than it used to be. You have plenty of drives left if you like, to enable raid_dp as well, which will give a 10data-2parity the basic reliability of two separate 5-1 raid groups, cept you have a larger stripe to make your reads against which seems to be your largest type of data activity according to this perfstat. What size Tshirt do I wear? XXL. :)

2 1

Stocks discovered for quick profit
by Angelica Carlton 28 Feb '05

28 Feb '05

US Oi| and Gas Report Oil Climbs, Gains Soar We have the leading track record for finding fast moving, Low-priced energy p|ays. Look at the moves made by our |ast 2 Hot Picks: SPRL .14 to .36 in 12 days, up 157% PRVB .10 to .265 in 8 days, up 165% Like a viper coiled to strike, this Hot Oi| P|ay is on the fast-track to Mi||ions in gains from expanding production in the Heart of the "Oi| Be|t". Emerson Oil and Gas, Inc. OTC - EOGI Immediate Acquire - Huge News on Increased Production Current Price .15 Target Price .4O in 1O days Oil prices continue to explode and ignite the shares of major producers which is fo|lowed by soaring undervalued OTC Oil P|ays. Widespread gains in energy stocks are inflating the portfo|ios of aggressive OTC investors. Due to recent|y acquired high-potential oil and gas projects, EOGI is an underva|ued gem experiencing a sharp in crease in production revenue and becoming a "cash-flow positive" |eader in major oil-producing states. EOGI's high-yie|ding, mu|tip|e dri|ling programs have been solidified through valuab|e strategic al|iances. These exploration partnerships enab|e the Company to accumulate substantial working interests being developed into a continuously expanding revenue stream. EOGI is focused on joint-ventures involving we|l re-entry programs in extremely pro|ific production areas using the highest |eve| of techno|ogy currently available. Recent deve|opments for EOGI have been perfectly timed as a|| 6 Dow Jones Oi| and Gas Indexes just hit their highest |evels of the year, with Energy Stocks outperforming a|l other market sectors. The Company's Oi| and Gas interests in Louisiana and Texas, in addition to their deve|oping natural gas wel|s in Alberta, Canada, are continuing to in crease in va|ue with energy prices up 60% from one year ago. Leading economists and oi| analysts agree on predictions that a further 30-6O% in crease is |ike|y next year. We are expecting EOGI to release major news announcements regarding production figures on mu|tiple projects in high-gear. EOGI's expansion p|ans are on track to acquire additional prospects and properties that can on|y add to their growing bottom-line and spark further interest in this undervalued oi| play. With a very sma|| f|oat estimated at |ess than 5 million shares, EOGI should gap sharp|y to the upside on heavy vo|ume as the value of their current oi| deals are revealed. US Oi| and Gas Report cautions that sma|| and micro-cap stocks are high-risk investments and that some or all of the investment can be |ost. We suggest you consult a professional investment advisor before making any investment decisions. US Oil and Gas Report recommends you use the information found here as an initia| starting point for conducting research and due di|igence on the featured company in order to determine an opinion of the company before investing. We are not an Investment Advisor, Financial P|anning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. This is not an offering of securities for sa|e or so|icitation of any attempt to acquire or sell securities. US Oi| and Gas Report has been given nineteen thousand do|lars from a third party for the dissemination of this company profile. Since we have been given compensation there is an inherent conf|ict of interest in our statements and opinions. Readers of this pub|ication are cautioned not to place undue reliance on future-looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties that could cause resu|ts to differ materially from those set forth in those statements. If you wish to stop future mailings, or if you fee| you have been wrongfu|ly p|aced in our membership, please go here or send a b|ank e mail with No Thanks in the subject to (-stox0033@ yahoo.com-)

1 0

RE: F720 head upgrade?
by Davin Milun 27 Feb '05

27 Feb '05

perfstat is a utility that you run from an admin host. http://now.netapp.com/NOW/download/tools/perfstat/ At 7:45, on Feb 27, 2005, "Michael Fahy" wrote: > > When I type "perfstat" I get "perfstat not found". I did "priv set > advanced" and found a "perf" command (but no perfstat). The only option is > "perf report -t" which produced: ...

2 1

RE: F720 head upgrade?
by Jeff Mohler 27 Feb '05

27 Feb '05

Run a perfstat..or at least tell us what its been up to. Has the file system been full or over 80% for any period of time? A perfstat will shed a TON of light. Id be glad to peek at it if you sent the output my way. :) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Fahy, Michael Sent: Saturday, February 26, 2005 8:44 PM To: toasters(a)mathworks.com Subject: F720 head upgrade? My good old F720 seems to have run out of gas. It is now running at 100% CPU utilization all the time and application performance has gotten really bad. I'm hoping to be able to upgrade the head and still use the three drive shelves. But I'm wondering why I'm seeing this poor performance all of a sudden and if it really is normal behavior. The F720 has a gigabit network interface but network usage never goes over 10%. When network usage gets to 5%, which would mean 50 Mbps, the CPU hits 100% and stays there. Is that really the maximum capacity of an F720? The three drive shelves are: Shelf 0: EDM Kernel Version : 0.4 App. Version : 0.0 Shelf 1: VEM Kernel Version : 2.5 App. Version : 3.1 Shelf 2: VEM Kernel Version : 2.5 App. Version : 3.1 What options do I have for replacing the head with a faster one that would work with these shelves?

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters