toasters

toasters@lists.teaparty.net

2 participants
13520 discussions

Re: Toasters list mail identification
by Tom Yates 24 Jul '98

24 Jul '98

On Fri, 24 Jul 1998, Nigel Metheringham wrote: > Is there any chance that some header can be added into the mail sent out > on the toaster's list to make it easier to identify by a mail handler. > Currently I have to depend on the envelope sender, which is not ideal but > normally works, but why is the sender <fubar(a)mathworks.com>, and why did > it suddenly change from <madhatta(a)mathworks.com>? it changed because the chap who's moderating it here changed, since this is my last day >snif<. this has been asked for once before, but i've never really felt like putting the time into busting majordomo apart and finding out if it, or sendmail, is bolting the envelope From together, and how to fix it. consensus seems to be that the envelope To and envelope From are there for the MTA's benefit, not yours; they are only reliable information for mail transport and delivery. otoh, there's now a new list moderator, who may well feel differently, and may be prepared to solve that problem, or add another identifying header to all toasters mail so you can filter on that. kendall, what sayest thou? Tom Yates - Unix Chap - The Mathworks, Inc. - +1 (508) 647 7561 MAG#65061 DoD#0135 AMA#461546 1024/CFDFDE39 0C E7 46 60 BB 96 87 05 04 BD FB F8 BB 20 C1 8C

1 0

RE: Veritas NetBackup
by Kelly Wyatt 24 Jul '98

24 Jul '98

We tried to restore to an alternate filer, and, as expected, it did not work. We were able to restore to an alternate location on the same filer. Now we are wondering if we can load a specific tape into the drive, go to the specific segment and try a manual restore. Has anyone else tried this? Kelly ------- Kelly Wyatt, saskww(a)wnt.sas.com <mailto:saskww@wnt.sas.com> Integrated Solutions Consulting SAS Institute Inc. / SAS Campus Drive / Cary, NC 27513 (919) 677-8000 X4279 (Voice) / (919) 677-4444 (FAX) http://www.sas.com <http://www.sas.com>

1 0

Re: Veritas NetBackup
by sirbruce＠ix.netcom.com 24 Jul '98

24 Jul '98

On 07/24/98 12:59:02 you wrote: > >On recent comments about Veritas requiring the same restore host: > >I believe this restriction was removed in the latest release (3.1.1?) >and that the restriction was purely down to hostname. I must have misread; I thought he was talking about some new NDMP restore package from Netapp, not something particular to Veritas. Bruce

1 0

Re: Toasters list mail identification
by Jason D. Kelleher 24 Jul '98

24 Jul '98

In message <E0yzhVI-0003Um-00(a)pearl.localnet>, Nigel Metheringham writes: > >pde(a)listserv.music.sony.com said: >} Erm. >} To: toasters(a)mathworks.com > >Which also means that your reply, sent directly to me, would be filed as >mailing list mail, rather than a direct message to me.... >[assuming that the To: included Cc:] What are you using to filter your mail? Can't you just file the mail into your list folder if it contains "toasters(a)mathworks.com" and not "Nigel.Metheringham(a)theplanet.net"? You're using exmh as your mailer, so I'd guess you are on a *nix system. If you don't have procmail installed, grab it, install it, read the docs, and finally beat your head against the wall lamenting all the time you've wasted without it. The procmail recipe would be something like this: :0 H : * ^TO.*toasters(a)mathworks.com * !^TO.*Nigel.Metheringham(a)theplanet.net $MAILDIR/toaster-list If you want to get really fancy, you can use a weighted scoring technique to throw out all the "me too"s and "subscribe" messages that have been comming through lately. :0 H : * ^TO.*toasters(a)mathworks.com * !^TO.*Nigel.Metheringham(a)theplanet.net { # This will trash mail whose ratio of quoted lines # to original lines exceeds 1:2. :0 Bh * 20^1 ^> * -10^1 ^[^>] /dev/null # If the message contains the word "subscribe" all by itself # on a line in the body, trash the message unless there are # at least 15 non-blank lines in the message. :0 B * 15^0 ^[ ]*subscribe[ ]*$ * -1^1 [^ ]+ /dev/null # Anything left, leave in a folder for later. :0: $MAILDIR/toaster-list } >[probably need to take this thread off the list before I get seriously >flamed :-) ] > > Nigel. I'll risk just this one follow-up. Your question might not have been "on topic", but people might find this useful. --- Jason D. Kelleher kelleher(a)susq.com Susquehanna Investment Group 610.617.2721 (voice) 401 City Line Ave, Suite 220 610.617.2916 (fax) Bala Cynwyd, PA 19004-1122

1 0

Toasters list mail identification
by Nigel Metheringham 24 Jul '98

24 Jul '98

Is there any chance that some header can be added into the mail sent out on the toaster's list to make it easier to identify by a mail handler. Currently I have to depend on the envelope sender, which is not ideal but normally works, but why is the sender <fubar(a)mathworks.com>, and why did it suddenly change from <madhatta(a)mathworks.com>? Nigel. -- [ Nigel.Metheringham(a)theplanet.net - Systems Software Engineer ] [ Tel : +44 113 207 6112 Fax : +44 113 234 6065 ] [ Real life is but a pale imitation of a Dilbert strip ]

4 4

Veritas NetBackup
by Thomson, Michael 24 Jul '98

24 Jul '98

On recent comments about Veritas requiring the same restore host: I believe this restriction was removed in the latest release (3.1.1?) and that the restriction was purely down to hostname. Cheers, Mike -- \\|||// Minds are like parachutes; (@ @) They only work when open. *---oOO-(_)-OOo------------------------------------* * Michael Thomson Email: mt53590(a)ggr.co.uk * * Unix Specialist Internal: 782 4393 * * Glaxo Wellcome External: 01438 764 393 * * Stevenage, UK Fax: 01438 763 204 * * .oooO Oooo. Mobile: 0498 725 047 * *--( )---( )-----------------------------------* \ ( ) / (Quote: Sir James Dewar) \_) (_/

1 0

Re: Backups... again
by sirbruce＠ix.netcom.com 24 Jul '98

24 Jul '98

On 07/23/98 21:32:43 you wrote: > >I have been evaluating veritas for use with backing up large filers. I >am concerned about something that I see as serious limitations with that >software: > >NDMP restores are always "in place" restores and will overwrite existing >files. This is documented in a Caution box in the NDMP book that came >with the netbackup software. Also, you cannot restore to any other >filer other than the one that you backed up. (I assume this is by name >so that a disaster recovery restore would work to any hardware you threw >at it, as long as it had the right name). Probably not. They probably mean that the configuration - hardware, drives, etc. - has to be exactly the same. I can't say this for sure, though. >Our evaluation criteria includes the ability to restore to another path >on the same filer, but according to the above, this will not work. We >still plan to try, though... > >Do others use backup software which is more flexible, or is this >something that is a (bad) side effect of using ndmp backups? Ummm, the filer also supports "regular" dump and restore, which can do a lot of things. NDMP has advantages in efficiency and such, but if you have other requirements, there's still regular dump and restore (which I assume are still supported). Bruce

2 1

Backups... again
by Kelly Wyatt 24 Jul '98

24 Jul '98

I have been evaluating veritas for use with backing up large filers. I am concerned about something that I see as serious limitations with that software: NDMP restores are always "in place" restores and will overwrite existing files. This is documented in a Caution box in the NDMP book that came with the netbackup software. Also, you cannot restore to any other filer other than the one that you backed up. (I assume this is by name so that a disaster recovery restore would work to any hardware you threw at it, as long as it had the right name). Our evaluation criteria includes the ability to restore to another path on the same filer, but according to the above, this will not work. We still plan to try, though... Do others use backup software which is more flexible, or is this something that is a (bad) side effect of using ndmp backups? Also, has anyone used a Storagetek 9730 on a filer (f630)? Thanks! Kelly -- Kelly Wyatt, saskww(a)wnt.sas.com Integrated Solutions Consulting SAS Institute Inc. / SAS Campus Drive / Cary, NC 27513 (919) 677-8000 X4279 (Voice) / (919) 677-4444 (FAX) http://www.sas.com

2 1

None
by Farouk Al-Shorafa 24 Jul '98

24 Jul '98

1 0

Re: ndmpcopy?
by Darrell Root 23 Jul '98

23 Jul '98

Ok, so the behavior acts like this: 1) On client A, which had the filesystem mounted before the ndmpcopy, the new data does not show up in directory X. 2) On client B, which mounts after the ndmpcopy starts, the data shows up. 3) On client A, after you unmount and remount, the data shows up. I have a theory based on the nfs protocol which might explain the behavior. Have your flamers ready because this could be wrong wrong wrong. Keep in mind that I've never actually read any nfs client source code...so set your expectations accordingly... When you do a ls on a directory you've never accessed before from a client, you get the data block for the directory and put it in your buffer cache. Later, if somebody does an ls on the same directory on the nfs client, the client needs to see if the buffer cache's data is valid. It does this by executing a getattr() nfs call. If the timestamp on the server has not changed, then the client will think that it's buffer cache is valid and not actually get the directory data. (this is why latex takes so long in nfsv2 even if the whole thing is in your buffer cache, depending on how much latex stuff you have you might have to do 10,000 getattr() calls to validate your buffer caches-- whereas if you're running on local disk you _know_ the buffer caches are valid). So, if the ndmpcopy is not updating the timestamp on that directory until the end, the client will happily believe that the directory's contents (as listed incorrectly in the clients buffer cache) is correct. But if you unmount and remount, that invalidates that part of the buffer cache, causing the data to magically appear. And if you mount on another client after the ndmpcopy is in progress, you don't have an incorrect buffer cache entry. This theory explains the behavior. Here are experiments to increase confidence in the theory: 1) packet trace between the server and the client, to watch for the getattr(), but not the actual read of that directory. 2) Manually create a file in the directory during the ndmpcopy from a second client (which causes the directory timestamp to update, which will mean when the first client does it's buffer cache validation with getattr() it will realize that it's buffer cache is out-of-date. 3) Check the timestamp on the directory from client 1 before the ndmpcopy, and from both clients during the ndmpcopy. Of course, this isn't important enough for me to try these experiments. If this is true, then it's a simple netapp bug which can be fixed by updating the timestamp on the target directory at the beginning of the ndmpcopy. Of course, if it's wrong then it's wrong :-) Darrell Root rootd(a)nas.nasa.gov

3 2

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