toasters

toasters@lists.teaparty.net

13520 discussions

VLD drive for UNIX
by Uros Lampret 31 Mar '02

31 Mar '02

Hi! I know there is Virtual Local Drive software called SnapDrive for Win NT and 2000. Is there similar software to do this on UNIX. I have an aplication that don't want to run from NFS mount. I need to mount this in the way that OS will see it as local drive. I use IBM AIX. Best regards, Uros _____________________________

2 1

RE: Freeing NFS locks
by Edward Hibbert 30 Mar '02

30 Mar '02

That sounds useful - would the reacquire be transparent to the client apps holding the locks? If so, then I could just issue that periodically...and so could the NetApp :-). -----Original Message----- From: Dylan Northrup [mailto:northrup@loudcloud.com] Sent: 30 March 2002 19:46 To: Edward Hibbert Cc: toasters(a)mathworks.com Subject: Re: Freeing NFS locks On Sat, 30 Mar 2002, Edward Hibbert wrote: :=I have a situation where I have a host which is not pingable, but lock_dump :=shows it as having a lot of NFS locks active. := :=Two questions: :=- Is there anything I can do to free up the locks (just for that host)? :=- Why doesn't the filer spot that the host has died, and free the locks :=automatically? There's an rpc call you can do to the filer to instruct it to free all locks and re-acquire them from hosts that are still responsive. You'll likely have to write a program to do this since I don't believe there is a utility that will allow you to do this already. You can get more information by looking at the NLM (Network Lock Manager) spec, particularly the NLMPROC4_FREE_ALL procedure. The reason the filer doesn't know the host has died is because NFS is inherently stateless and the NLM tries to impose state on top of NFS. Because NFS is stateless, the only time the filer knows anything has changed is when the client communicates with it. If the client panics or halts without shutting down normally the filer doesn't know it's fallen off the map and holds the locks like it should waiting for a a communication that won't come until the host is rebooted or its network connectivity is re-established. Hope this helps. -- Dylan Northrup <*> northrup(a)loudcloud.com <*> Evil Dylan, the Unix Dylan "Harder to work, harder to strive, hard to be glad to be alive, but it's really worth it if you give it a try." - Cowboy Mouth, 'Easy'

1 0

Soundj - Skol Beats
by Soundj - Skol Beats 30 Mar '02

30 Mar '02

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Soundj - detonando a barreira do som</TITLE> <META http-equiv=Content-Type content="text/html; charset=windows-1252"><BASE href=> <SCRIPT language=JavaScript>  </SCRIPT> <STYLE title=pc_css type=text/css>DIV { FONT-WEIGHT: normal; FONT-SIZE: 13px; FONT-FAMILY: Arial,Helvetica } A:link { FONT-STYLE: normal; TEXT-DECORATION: none } A:visited { FONT-STYLE: normal; TEXT-DECORATION: none } A:hover { TEXT-DECORATION: underline } DIV.tit1 { FONT-WEIGHT: bold; FONT-SIZE: 17px } DIV.side { FONT-WEIGHT: normal; FONT-SIZE: 11px; FONT-STYLE: normal } DIV.bar { FONT-WEIGHT: bold; FONT-SIZE: 9px; COLOR: white; LINE-HEIGHT: 1.6; FONT-FAMILY: Verdana, Arial, Helvetica } INPUT { FONT-WEIGHT: bold; FONT-SIZE: 9px; FONT-FAMILY: Verdana, Arial, Helvetica } </STYLE> <BASE href=http://www.soundj.com.br/news/> <META content="MSHTML 6.00.2713.1100" name=GENERATOR></HEAD> <BODY vLink=#003399 link=#003399 bgColor=#000000 background=http://www.soundj.com.br/news/bg_green_new.gif topMargin=0> <DIV></DIV> <TABLE cellSpacing=0 cellPadding=0 width="100%" bgColor=#000000 border=0> <TBODY> <TR> <TD width=135 bgColor=#000000><img src="http://www.soundj.com.br/news/fo.gif"></TD> <TD width=223> </TD> <TD width="100%" bgColor=#000000> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td> </td> <td> <div align="center"></div> </td> </tr> </table> </TD> </TR></TBODY></TABLE> <SCRIPT language=javascript>  </SCRIPT> <TABLE cellSpacing=0 cellPadding=4 width="100%" border=0> <TBODY> <TR> <TD onmouseover="mouseOver(this,'#cc6600');" onclick=mouseClick(this); onmouseout="mouseOut(this,'#000000');" align=middle width="14%" bgColor=#000000> <div align="center"><A href="http://www.soundj.com.br" target=_blank><FONT face=Arial,Helvetica color=#ffcc00 size=2><B>.:: clique aqui e visite nosso site www.soundj.com.br ::.</B></FONT></A> </div> </TD> </TR> </TBODY> </TABLE> <TABLE cellSpacing=0 cellPadding=0 width="100%" bgColor=#ffffff border=0> <TBODY> <TR> <TD vAlign=top> <TABLE cellSpacing=0 cellPadding=4 width="100%" border=0> <TBODY> <TR> <TD bgColor=#e8e8d0> <TABLE cellSpacing=0 cellPadding=0 width="95%" align=center border=0> <TBODY> <TR> <TD><font face="Verdana,Arial,Helvetica" size="1">Newsletter Soundj.com.br </font></TD> </TR></TBODY></TABLE></TD></TR></TBODY></TABLE> <TABLE cellSpacing=0 cellPadding=12 border=0> <TBODY> <TR vAlign=top> <TD bgcolor="#FFFFFF"> <DIV class=tit1><A href="http://www.soundj.com.br"> </A></DIV> <DIV align=right> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="11%"><img src="http://www.soundj.com.br/soundj/rave/rave5.jpg" align=left border=0></td> <td width="89%"> <div class=tit1><a href="http://www.soundj.com.br">Escorregue nessa aventura</a></div> <div>Confira as fotos da festa Rave H2O que rolou no dia 23 de março. Muita agitação ao comando do DJ AAron Liberator da Inglaterra. Fomos até lá para conferir, mas parece que não fomos só nós.. <div align=right><img height=8 src="http://www.soundj.com.br/news/setinha_gde.gif" width=13 border=0><a href="http://www.soundj.com.br/soundj/artigodetalhe.asp?id=11">Leia mais</a></div> </div> </td> </tr> </table> </DIV> </TD></TR></TBODY></TABLE><BR> <TABLE cellSpacing=2 cellPadding=3 width="95%" align=center border=0> <TBODY> <TR> <TD bgColor=#c8c8b0> <DIV><B>Novidades do site - <a href="http://www.soundj.com.br/soundj/balada.asp">baladas</a> - <a href="http://www.soundj.com.br/soundj/chupim.asp">humor</a> - <a href="http://www.soundj.com.br">música</a></B></DIV> </TD></TR> <TR vAlign=top> <TD> <TR vAlign=top> <TD> <DIV> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="16%"><b><img src="http://www.soundj.com.br/soundj/endo.jpg"></b></td> <td width="84%"><b><a href="http://www.soundj.com.br/soundj/mixagens.asp">Dj Leandro Endo faz sua primeira versão de mixagens para o site Soundj.</a></b></td> </tr> </table> <B> </B></DIV> <DIV> <p>Se você gosta de música eletrônica, acesse agora mesmo nossa seção de mixagens em mp3 e confira as alucinantes viradas do DJ Leandro Endo. São 60 minutos ao vivo para você baixar no seu computador e curtir ao máximo. "Nós vamos leva-lo para outra dimensão".<br> <b><br> Dados técnicos do arquivo:</b></p> <p align="left">Formato = MP3<br> Tamanho= 9.9 Megas<br> Tempo estimado do download = 45 minutos para modem 28.8k<br> Tempo de duração das mixagens = 1 hora<br> <br> * Você poderá ouvir todas as músicas enquanto faz o download ou se preferir faça o pedido do CD Soundj acessando nosso formulário on-line.<br> <br> </p> <p align="center"><a href=http://www.soundj.com.br><img src="http://www.soundj.com.br/soundj/skol.gif"> </a> </p> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td bgcolor="#c8c8b0"><b> Humor</b></td> </tr> </table> <p align="center"><br> <br> Encomendar a sua felicidade R$120.000.000,00<br> Viver até os 115 anos R$6.700.000,00<br> Comprar a China R$ 97.250.000.000.000,00 <br> Dar de cara com uma privada bem na hora em que você mais precisa, quase não tem preço, para todas as outras coisas, existe o Brand Card). <br> <br> <img height=8 src="http://www.soundj.com.br/news/setinha_gde.gif" width=13 border=0><a href="http://www.soundj.com.br/soundj/chupim.asp">Saiba mais sobre este cartão que está revolucionando o mundo. </a></p> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td bgcolor="#c8c8b0"><b>Outras novidades</b></td> </tr> </table> <p>Agora em parceria com a CDnow você poderá comprar CDs com até 40% de desconto.<br> <br> O site Soundj está ajudando na divulgação do movimento Anti Drogas, estamos elaborando alguns conteúdos que seram colocados aleatóriamente no site. </p> </DIV> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td bgcolor="#c8c8b0"><b><font face="Verdana, Arial, Helvetica, sans-serif">Mais pera ai quem são vocês ? </font></b></td> </tr> </table> <div align="left"> <p><br> Somo um grupo de DJs e estamos lançando este site em sua primeira versão após 3 meses de muito trabalho. Atualmente contamos com o apoio de 12 pessoas com um único objetivo em comum. Levar até você o melhor som eletrônico. Trabalhamos muito para tonar nossos ideais uma realidade. Para quem vê tudo pronto até parece que foi fácil, mas sem o compromisso e a dedicação seria quase impossível traduzir em bit o sonho que hoje está a sua frente. Este mesmo email que você está vendo agora, também é visto por 14 milhões de pessoas de todos os cantos. Número que só foi possíveil graças ao nosso intenso suor.<br> <br> O compromisso com a música eletrônica a partir de hoje está selado num único lugar:<br> <IMG height=8 src="http://200.177.252.101/img/setinha.gif" width=11 border=0><A href="http://www.soundj.com.br">www.soundj.com.br</A>  <BR> <br> <br> </p> <table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td bgcolor="#c8c8b0"><b><font face="Verdana, Arial, Helvetica, sans-serif">Críticas - sugestões ? nosso email é:</font></b></td> </tr> </table> <div align="left"> <p></p> </div> <p align="left"><br> <img height=8 src="http://200.177.252.101/img/setinha.gif" width=11 border=0><a href="mailto:contato@soundj.com.br">contato(a)soundj.com.br </a><br> <br> </p> <p align="center"><font face="Verdana, Arial, Helvetica, sans-serif" size="3" color="#000000"><b><font size="4"><a href="http://www.soundj.com.br">www.soundj.com.br </a> </font> </b> </font></p> </div> </TD></TR></table></TD></TR></TBODY></TABLE><BR> <TD width=5 bgColor=#e8e8d0> </TD> <TD vAlign=top width=125 bgColor=#e8e8d0> <BR> </TD> <TD width=5 bgColor=#e8e8d0> </TD> </TBODY> <TABLE cellSpacing=0 cellPadding=3 width="100%" border=0> <TBODY> <TR vAlign=top bgColor=#000000> <TD align=middle valign="middle"> <DIV class=side style="COLOR: #cccc99"> <CENTER> www.soundj.com.br - detonando a barreira do som </CENTER></DIV></TD></TR></TBODY></TABLE><BR></BODY></HTML>

1 0

Freeing NFS locks
by Edward Hibbert 30 Mar '02

30 Mar '02

I have a situation where I have a host which is not pingable, but lock_dump shows it as having a lot of NFS locks active. Two questions: - Is there anything I can do to free up the locks (just for that host)? - Why doesn't the filer spot that the host has died, and free the locks automatically? Thanks, Edward.

2 1

Re: Vol/qtree/dir/file snapshots (was Re: DataONTAP 6.2) ORACLE D ATABASES
by ScottUCE＠aol.com 29 Mar '02

29 Mar '02

Joe: Cheap 7x9gb FC7 NetApp shelves could make a great place to build a root volume on your customers' existing filers ........ and, coincidentally, we happen to have dozens of them! :-) I'd be happy to get around 800.00 or 900.00 for a fully populated FC7 shelf and would provide a one-year advance parts exchange warranty, to boot! :-) Scott Fischmann Union Computer Exchange, Inc. 6233 Idylwood Lane Minneapolis, MN 55436 Phone: 952 935 7282 FAX: 952 935 5056 scott(a)unioncomputer.com In a message dated 3/29/2002 11:13:54 AM Central Standard Time, joe.luchtenberg(a)data-line.com writes: > I think Chris' point has more merit than you give credit, Quentin. There > are many issues to consider, including segregating the root volume, parity > disks, costs of additional shelves/cabinetry/head units, etc. Granted the > cost of disk capacity does not scale linearly. However, if you're not > using > the additional capacity in a volume (30GB database on a volume of 5-6 72GB > drives, as in Chris' scenario) - and there may be very good reasons for > this > - then big drives are definitely not the most cost-effective way to scale > capacity. > Qtree-level SnapMirror and/or file-level SnapRestore may solve some of > these > issues related to capacity management, allowing you to put more databases > on > the same volume. Even still, it would be nice to have an internal 2x9GB > volume (maybe even with solid state disks!) to serve as root, rather than > "wasting" 72GB drives and shelf slots. > > Just musing... > > Joe > > > Joe Luchtenberg > Dataline, Inc. > > Email: joe.luchtenberg(a)data-line.com > Phone: 757-457-0504 (direct line) > 757-858-0600 (front desk) > 757-285-1223 (mobile) > Fax: 757-858-0606 > > Please visit us at www.data-line.com > > > > > -----Original Message----- > > From: Quentin Fennessy [mailto:quentin.fennessy@amd.com] > > Sent: Friday, March 29, 2002 8:29 AM > > To: Chris Lamb > > Cc: Melvin, Grant; 'Noll, Kevin'; 'Toasters (E-mail)' > > Subject: Re: Vol/qtree/dir/file snapshots (was Re: DataONTAP > > 6.2) ORACLE > > DATABASES > > > > > > > > Chris asked: > > > Of course, one just begs to ask: WHY is it that we > > continue this absurd > > > notion that bigger is always better? Who the hell needs a > > 72GB BOOT DISK? > > > Sure, maybe when Windows(tm) 2004 comes out... :-) > > > > This is a detail that is unnecessary to sweat. Large drives > > don't have to be > > full. The cost of capacity is dropping -- at a given time in > > product life, a > > 72GB disk is not 8x the cost of a 9GB drive. It may well be > > 1x the price, > > this 1/8x the cost! > > > > Leave the disk space empty if its use is not appropriate. > > > > If you need extra spindles for performance, buy them. Don't > > get caught in the raw capacity trap. > > > > I cannot imagine that it is economical to continue to sell > > relatively smaller disks, when for the same outlay the > > disk manufacturers can provide more capacity. The factories > > can provide X disks (or disk platters) per week. They will > > optimize appropriately. And they would go out of business > > if they did not, because the competition will! > > > > As a system administrator we (you and I) all have to exercise > > judgement on > > how to best manage these resources. If your boss or your > > customers override > > your judgement then something should change. But it won't be the > > manufacturing economics of disk drives! > > > > > > > Yes, it is a fundamental law of computing that files and > > databases will > > > always expand to fill the available disk space, but why is > > it that you > > > can't even buy a 9GB drive anymore? A 20-30GB database, even if you > > > double or triple it in size, is still going to fit on *one* > > shelf with > > > 9- or 18GB drives. > > > > > If I had a 30GB database, I'm sure my DBA would agree - > > striping 5-6 9's > > > together makes way, way more sense than throwing piles of > > higher-cost 36's > > > or 72's at it, only to waste massive amounts of space in an > > effort to keep > > > performance up. Of course, our database grows at over 30 > > million rows per > > > week, so adding 36's makes sense for us. :-) Still! I > > echo the call for > > > using appropriately-sized drives where it makes sense. :-) > > > > > All of my production servers have ridiculously huge boot > > drives because > > > that's the only way Sun (or anyone else) sells them these > > days. So I > > > mirror / & /var, interleave swap, and even after sizing > > things to some > > > absurd degree, there's usually a chunk of 8-10GB of free > > space - 'cuz all > > > the good stuff lives on the filers. Having that local disk > > space there > > > just means that someone is going to want to USE it, and > > that's bad - it > > > means I'd have to actually back up those machines, and I > > *hate* backups. > > > (In the exceedingly rare case where both drives of a > > mirrored boot volume > > > are corrupted or destroyed, it's always going to be faster > > to re-Jumpstart > > > and cfengine the machine from scratch than to restore from > > tape anyway. > > > Local data just messes up all that beautiful automation. :-) > > > > > A long time ago I was going to recommend that filers come > > with a pair of > > > internal boot drives - like a mirrored pair of 4GB or 9GB drives > > > _strictly_ for use as the boot volume, with some space for > > logs, etc. > > > There's plenty of room inside the big filer heads for a > > pair of drives. > > > But the move to Flash RAM cards in the newest machines is > > even better - > > > fewer moving parts. :-) > > > > -- > > Quentin Fennessy Quentin.Fennessy(a)amd.com > > Office: 512.602.3873 > > Cell: 512.694.7489 >

1 0

RE: Vol/qtree/dir/file snapshots (was Re: DataONTAP 6.2) ORACLE D ATABASES
by Joe Luchtenberg 29 Mar '02

29 Mar '02

I think Chris' point has more merit than you give credit, Quentin. There are many issues to consider, including segregating the root volume, parity disks, costs of additional shelves/cabinetry/head units, etc. Granted the cost of disk capacity does not scale linearly. However, if you're not using the additional capacity in a volume (30GB database on a volume of 5-6 72GB drives, as in Chris' scenario) - and there may be very good reasons for this - then big drives are definitely not the most cost-effective way to scale capacity. Qtree-level SnapMirror and/or file-level SnapRestore may solve some of these issues related to capacity management, allowing you to put more databases on the same volume. Even still, it would be nice to have an internal 2x9GB volume (maybe even with solid state disks!) to serve as root, rather than "wasting" 72GB drives and shelf slots. Just musing... Joe Joe Luchtenberg Dataline, Inc. Email: joe.luchtenberg(a)data-line.com Phone: 757-457-0504 (direct line) 757-858-0600 (front desk) 757-285-1223 (mobile) Fax: 757-858-0606 Please visit us at www.data-line.com > -----Original Message----- > From: Quentin Fennessy [mailto:quentin.fennessy@amd.com] > Sent: Friday, March 29, 2002 8:29 AM > To: Chris Lamb > Cc: Melvin, Grant; 'Noll, Kevin'; 'Toasters (E-mail)' > Subject: Re: Vol/qtree/dir/file snapshots (was Re: DataONTAP > 6.2) ORACLE > DATABASES > > > > Chris asked: > > Of course, one just begs to ask: WHY is it that we > continue this absurd > > notion that bigger is always better? Who the hell needs a > 72GB BOOT DISK? > > Sure, maybe when Windows(tm) 2004 comes out... :-) > > This is a detail that is unnecessary to sweat. Large drives > don't have to be > full. The cost of capacity is dropping -- at a given time in > product life, a > 72GB disk is not 8x the cost of a 9GB drive. It may well be > 1x the price, > this 1/8x the cost! > > Leave the disk space empty if its use is not appropriate. > > If you need extra spindles for performance, buy them. Don't > get caught in the raw capacity trap. > > I cannot imagine that it is economical to continue to sell > relatively smaller disks, when for the same outlay the > disk manufacturers can provide more capacity. The factories > can provide X disks (or disk platters) per week. They will > optimize appropriately. And they would go out of business > if they did not, because the competition will! > > As a system administrator we (you and I) all have to exercise > judgement on > how to best manage these resources. If your boss or your > customers override > your judgement then something should change. But it won't be the > manufacturing economics of disk drives! > > > > Yes, it is a fundamental law of computing that files and > databases will > > always expand to fill the available disk space, but why is > it that you > > can't even buy a 9GB drive anymore? A 20-30GB database, even if you > > double or triple it in size, is still going to fit on *one* > shelf with > > 9- or 18GB drives. > > > If I had a 30GB database, I'm sure my DBA would agree - > striping 5-6 9's > > together makes way, way more sense than throwing piles of > higher-cost 36's > > or 72's at it, only to waste massive amounts of space in an > effort to keep > > performance up. Of course, our database grows at over 30 > million rows per > > week, so adding 36's makes sense for us. :-) Still! I > echo the call for > > using appropriately-sized drives where it makes sense. :-) > > > All of my production servers have ridiculously huge boot > drives because > > that's the only way Sun (or anyone else) sells them these > days. So I > > mirror / & /var, interleave swap, and even after sizing > things to some > > absurd degree, there's usually a chunk of 8-10GB of free > space - 'cuz all > > the good stuff lives on the filers. Having that local disk > space there > > just means that someone is going to want to USE it, and > that's bad - it > > means I'd have to actually back up those machines, and I > *hate* backups. > > (In the exceedingly rare case where both drives of a > mirrored boot volume > > are corrupted or destroyed, it's always going to be faster > to re-Jumpstart > > and cfengine the machine from scratch than to restore from > tape anyway. > > Local data just messes up all that beautiful automation. :-) > > > A long time ago I was going to recommend that filers come > with a pair of > > internal boot drives - like a mirrored pair of 4GB or 9GB drives > > _strictly_ for use as the boot volume, with some space for > logs, etc. > > There's plenty of room inside the big filer heads for a > pair of drives. > > But the move to Flash RAM cards in the newest machines is > even better - > > fewer moving parts. :-) > > -- > Quentin Fennessy Quentin.Fennessy(a)amd.com > Office: 512.602.3873 > Cell: 512.694.7489 > > >

1 0

Re: Vol/qtree/dir/file snapshots (was Re: DataONTAP 6.2) ORACLE DATABASES
by Quentin Fennessy 29 Mar '02

29 Mar '02

Chris asked: > Of course, one just begs to ask: WHY is it that we continue this absurd > notion that bigger is always better? Who the hell needs a 72GB BOOT DISK? > Sure, maybe when Windows(tm) 2004 comes out... :-) This is a detail that is unnecessary to sweat. Large drives don't have to be full. The cost of capacity is dropping -- at a given time in product life, a 72GB disk is not 8x the cost of a 9GB drive. It may well be 1x the price, this 1/8x the cost! Leave the disk space empty if its use is not appropriate. If you need extra spindles for performance, buy them. Don't get caught in the raw capacity trap. I cannot imagine that it is economical to continue to sell relatively smaller disks, when for the same outlay the disk manufacturers can provide more capacity. The factories can provide X disks (or disk platters) per week. They will optimize appropriately. And they would go out of business if they did not, because the competition will! As a system administrator we (you and I) all have to exercise judgement on how to best manage these resources. If your boss or your customers override your judgement then something should change. But it won't be the manufacturing economics of disk drives! > Yes, it is a fundamental law of computing that files and databases will > always expand to fill the available disk space, but why is it that you > can't even buy a 9GB drive anymore? A 20-30GB database, even if you > double or triple it in size, is still going to fit on *one* shelf with > 9- or 18GB drives. > If I had a 30GB database, I'm sure my DBA would agree - striping 5-6 9's > together makes way, way more sense than throwing piles of higher-cost 36's > or 72's at it, only to waste massive amounts of space in an effort to keep > performance up. Of course, our database grows at over 30 million rows per > week, so adding 36's makes sense for us. :-) Still! I echo the call for > using appropriately-sized drives where it makes sense. :-) > All of my production servers have ridiculously huge boot drives because > that's the only way Sun (or anyone else) sells them these days. So I > mirror / & /var, interleave swap, and even after sizing things to some > absurd degree, there's usually a chunk of 8-10GB of free space - 'cuz all > the good stuff lives on the filers. Having that local disk space there > just means that someone is going to want to USE it, and that's bad - it > means I'd have to actually back up those machines, and I *hate* backups. > (In the exceedingly rare case where both drives of a mirrored boot volume > are corrupted or destroyed, it's always going to be faster to re-Jumpstart > and cfengine the machine from scratch than to restore from tape anyway. > Local data just messes up all that beautiful automation. :-) > A long time ago I was going to recommend that filers come with a pair of > internal boot drives - like a mirrored pair of 4GB or 9GB drives > _strictly_ for use as the boot volume, with some space for logs, etc. > There's plenty of room inside the big filer heads for a pair of drives. > But the move to Flash RAM cards in the newest machines is even better - > fewer moving parts. :-) -- Quentin Fennessy Quentin.Fennessy(a)amd.com Office: 512.602.3873 Cell: 512.694.7489

1 0

Re: DataONTAP 6.2
by mds＠gbnet.net 29 Mar '02

29 Mar '02

On Thu 28 Mar, 2002, Brian Tao <taob(a)risc.org> wrote: > On Thu, 28 Mar 2002, Steve Losen wrote: > > > > Does ONTAP link the snapshotted blocks back into the live filesystem > > or does it just copy the file from the snapshot creating a new file > > in the live filesystem? > > I believe the former is correct (if the operation is analogous to > volume SnapRestore). The advantage here is that I can now tell my > DBAs they can roll back selected .dbf's, each 2GB in size, in a matter > of seconds. How long would it otherwise take you to copy each 2GB > file out of snapshots over NFS? 2 minutes? 3 minutes? :) Key advantage isn't speed, it's viability. On full filers a snaprestore in-place (by linking blocks from an old consistency point back into the live structures) means your very large file only takes space equivalent to its contents, which can make the difference between possible and not possible. This is another feature I asked for years ago, back when we were moving from FAS1400s through F[23][123]0s to F540s. My how time passes. > -- > Brian Tao (BT300, taob(a)risc.org) > "Though this be madness, yet there is method in't" > >-- End of excerpt from Brian Tao -- -Mark ... an Englishman in London ...

1 0

RE: multiple SQL servers on mirrored database
by Sam Schorr 29 Mar '02

29 Mar '02

I would suggest using SQL Server's replication functionality. Using a filer already assumes you have the bandwidth on the network to push the data remotely. Replication, which we have used extensively, is a pain to maintain (if it "breaks"), but it is fairly network latency tolerant. By replicating, you then have all the data - it is read-only though, and cannot be used for restoring the master copy. So, it is not a replacement for using Snapmirror/SnapRestore. Hope that is useful. -----Original Message----- From: Chris Good [mailto:chris@g2.nu] Sent: Thursday, March 28, 2002 10:29 AM To: toasters(a)mathworks.com Subject: Re: multiple SQL servers on mirrored database ""Zekeriya Eskiocak"" <zeskiocak(a)prolink.com.tr> wrote in message news:LNECLOKLKNCMJCNPDJEGKELECDAA.zeskiocak@prolink.com.tr... > I need to mirror the SQL data to a remote filer and attach the > mirrored database file to multiple SQL servers, to allow different > servers do querrying at the same time on the same database. Is this > deployment possible > with SQL Server either 7.0 or 2000? Has anyone done a similar config? Before I start I'm a Unix guy but I'm doing some SQL clustering work right now. AIUI SQL server isn't happy out of the box running on a filer. With netapp drivers its ok. Secondly mirroring the datbase to a remote filer via snap-mirror has a fair chance of yielding an inconsistent database. Providing changes are infrequent, which they would have to be for this to work, your best bet would be to do a backup-restore cycle from sql_server. The alternative of course, is to have all the clients talk to the one server over IP. Chris

1 0

DataONTAP 6.2
by Uros Lampret 28 Mar '02

28 Mar '02

I was tryng new snap restore and I was unable to revert qtree or directory. Only vol or single file. I'm I missing something? Uros

4 5

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