toasters

toasters@lists.teaparty.net

13517 discussions

RE: Data Ontap 7.2
by Glenn Walker 12 Aug '06

12 Aug '06

Blake, Flexshare - is this the 'guardrail' technology that enables QoS of particular datasets? Or is that 'future' at the moment? Glenn -----Original Message----- From: Blake Golliher [mailto:thelastman@gmail.com] Sent: Friday, August 11, 2006 11:46 PM To: Glenn Walker Cc: markallen(a)micron.com; toasters(a)mathworks.com Subject: Re: Data Ontap 7.2 We are testing it as well. FlexShare looks to be some killer technology we are excited to look at. But the mutliproc changes I think are key to this release. Which almost makes me want to wait until 7.2.2 or 7.2.3 before thinking about it seriously. Because if it's good now, wait until they perfect it! -Blake On 8/11/06, Glenn Walker <ggwalker(a)mindspring.com> wrote: > > > > > Not yet tested, but they did fix CIFS running on only 1 proc at a time (now > multithreaded and shouldn't be an issue with competing for resources from > WAFL anymore). Looking forward to that, especially with changenotify and > other issues that can cause problems on older systems! > > > > Glenn > > > > ________________________________ > > > From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On > Behalf Of markallen(a)micron.com > Sent: Friday, August 11, 2006 11:43 AM > To: toasters(a)mathworks.com > Subject: Data Ontap 7.2 > > > > > I noticed that Netapp GA'd 7.2 on the 3rd of August. I did a bug fix report > and noticed that a lot of CIFS bugs were fixed between the GD release 7.04 > and 7.2. I also noticed the same thing when I compared 7.1.1 and 7.2. I've > also heard that CIFS performs a lot better on multiproc systems with this > OS. Has anyone tested this out under a load and does the OS provide better > CIFS performance without any reliability side affects or impact to other > protocols such as NFS? I have it installed on a test system but I don't > really have a load on it yet. > > Thanks > > -Mark >

1 0

RE: Data Ontap 7.2
by Glenn Walker 12 Aug '06

12 Aug '06

Not yet tested, but they did fix CIFS running on only 1 proc at a time (now multithreaded and shouldn't be an issue with competing for resources from WAFL anymore). Looking forward to that, especially with changenotify and other issues that can cause problems on older systems! Glenn ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of markallen(a)micron.com Sent: Friday, August 11, 2006 11:43 AM To: toasters(a)mathworks.com Subject: Data Ontap 7.2 I noticed that Netapp GA'd 7.2 on the 3rd of August. I did a bug fix report and noticed that a lot of CIFS bugs were fixed between the GD release 7.04 and 7.2. I also noticed the same thing when I compared 7.1.1 and 7.2. I've also heard that CIFS performs a lot better on multiproc systems with this OS. Has anyone tested this out under a load and does the OS provide better CIFS performance without any reliability side affects or impact to other protocols such as NFS? I have it installed on a test system but I don't really have a load on it yet. Thanks -Mark

2 1

Data Ontap 7.2
by markallen＠micron.com 11 Aug '06

11 Aug '06

I noticed that Netapp GA'd 7.2 on the 3rd of August. I did a bug fix report and noticed that a lot of CIFS bugs were fixed between the GD release 7.04 and 7.2. I also noticed the same thing when I compared 7.1.1 and 7.2. I've also heard that CIFS performs a lot better on multiproc systems with this OS. Has anyone tested this out under a load and does the OS provide better CIFS performance without any reliability side affects or impact to other protocols such as NFS? I have it installed on a test system but I don't really have a load on it yet. Thanks -Mark

1 0

RE: CIFS homedir offline file synchronization
by Glenn Walker 11 Aug '06

11 Aug '06

One other thing to be aware of (ran into it today as I was reconfiguring my personal offline cache): If the share where the data resides does not provide the user with access, even if their personal directory does, then synchronization will fail. In that case, you'd have to have each user access their own share (essentially using the homedir functionality) or make it so that each user has privileges to the share itself (assuming read will be enough). Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Christopher Mende Sent: Thursday, August 10, 2006 5:02 PM To: toasters(a)mathworks.com Subject: RE: CIFS homedir offline file synchronization Thanks for your response Marty & Glenn, This KB looks like it should tackle this issue. Windows can't synchronize files into the cache for a share that essentially doesn't exist -- the share is only accessible when authenticated as that particular user. But not sure if it's practical to stamp primary SIDs on the desktops ... the users are relatively mobile. I'm far from a strong Windows admin (Unix background) so this is a bit of learning for me. I may suggest to create a top-level share, homedirs$ and reference each user's directory as \\filer\homedir$\%username% instead of \\filer\%username% (using the CIFS.HOMEDIR functionality). That way the share always exists ... and Windows can blindly sychronize stuff that doesn't need to be. :-D C Christopher Mende Systems Engineer Infinity Solutions Ltd P O Box 3323, Auckland Ph: +64 9 921 8039, Mob: +64 21 227 7590 Fax: +64 9 309 4142 www.infinitysolutions.co.nz > -----Original Message----- > From: Marty Wise [mailto:Marty.Wise@jlab.org] > Sent: Thursday, 10 August 2006 11:10 p.m. > To: Christopher Mende; toasters(a)mathworks.com > Subject: RE: CIFS homedir offline file synchronization > > Chris, > > I am not familiar with the error masking behavior you describe, but I have > done some tinkering with this issue from another perspective. > > Apparently, Windows uses a global offline file cache on a system. A > synchronization event will trigger a synchronization of files for all > users > by default. This is made even more annoying by various files which cannot > be > synchronized (MS Access files among others) that generate errors during > the > synchronization attempt. In our specific situation, it is users who only > occasionally log in to a system (mostly admins and support folks) that get > synchronized needlessly during sync events triggered by the real user of > the > system. A bit of digging revealed that Windows provides controls that > alleviates much of this problem for us. > > There are registry entries (that can be set via group policy) that allow > you > to specify a list of "Primary" users of a system for offline files (other > entries allow you to ignore specific file extensions during > synchronization). Offline files uses the list of primary users to attempt > synchronization of only files for those users. In our case, this avoids > synchronizing files for our admins, etc. The configuration is described in > MS KnowledgeBase article ID # 811660. > (http://support.microsoft.com/?kbid=811660) > > I'm not sure if this is useful in your situation. > > Regards, > > Marty Wise > Computer Center, Windows Systems Team > Thomas Jefferson National Accelerator Facility > 12000 Jefferson Ave. > Newport News, VA, 23606 > > > ________________________________________ > From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] > On > Behalf Of Christopher Mende > Sent: Thursday, August 10, 2006 12:49 AM > To: toasters(a)mathworks.com > Subject: CIFS homedir offline file synchronization > > Hi All, > > Anyone run into issues with offline file synchronization for homedirs? > > Have an issue where user1 logs in and out, and sync works just fine. > > User 2 logs in and out & syncs, plus it tries to sync user1 again, which > fails. > > According to M$, if you were using one of their servers, the share > permissions on the user share would be set to Full Control, and Windows > would actually mask the failure. > > Seems this isn't happening when using the filer - any ideas short of > scrapping the auto-homedir feature? How does one change the share > permissions on these auto-gen'd shares which aren't accessible via > traditional methods? If that's really the fix. > > Christopher Mende > > The information contained in this email is privileged and confidential and > intended for the addressee only. If you are not the intended recipient, > you > are asked to respect that confidentiality and not disclose, copy or make > use > of its contents. If received in error you are asked to destroy this email > and contact the sender immediately. Your assistance is appreciated. The information contained in this email is privileged and confidential and intended for the addressee only. If you are not the intended recipient, you are asked to respect that confidentiality and not disclose, copy or make use of its contents. If received in error you are asked to destroy this email and contact the sender immediately. Your assistance is appreciated.

1 0

CIFS homedir offline file synchronization
by Christopher Mende 10 Aug '06

10 Aug '06

Hi All, Anyone run into issues with offline file synchronization for homedirs? Have an issue where user1 logs in and out, and sync works just fine. User 2 logs in and out & syncs, plus it tries to sync user1 again, which fails. According to M$, if you were using one of their servers, the share permissions on the user share would be set to Full Control, and Windows would actually mask the failure. Seems this isn't happening when using the filer - any ideas short of scrapping the auto-homedir feature? How does one change the share permissions on these auto-gen'd shares which aren't accessible via traditional methods? If that's really the fix. Christopher Mende The information contained in this email is privileged and confidential and intended for the addressee only. If you are not the intended recipient, you are asked to respect that confidentiality and not disclose, copy or make use of its contents. If received in error you are asked to destroy this email and contact the sender immediately. Your assistance is appreciated.

2 1

RE: CIFS homedir offline file synchronization
by Christopher Mende 10 Aug '06

10 Aug '06

Thanks for your response Marty & Glenn, This KB looks like it should tackle this issue. Windows can't synchronize files into the cache for a share that essentially doesn't exist -- the share is only accessible when authenticated as that particular user. But not sure if it's practical to stamp primary SIDs on the desktops ... the users are relatively mobile. I'm far from a strong Windows admin (Unix background) so this is a bit of learning for me. I may suggest to create a top-level share, homedirs$ and reference each user's directory as \\filer\homedir$\%username% instead of \\filer\%username% (using the CIFS.HOMEDIR functionality). That way the share always exists ... and Windows can blindly sychronize stuff that doesn't need to be. :-D C Christopher Mende Systems Engineer Infinity Solutions Ltd P O Box 3323, Auckland Ph: +64 9 921 8039, Mob: +64 21 227 7590 Fax: +64 9 309 4142 www.infinitysolutions.co.nz > -----Original Message----- > From: Marty Wise [mailto:Marty.Wise@jlab.org] > Sent: Thursday, 10 August 2006 11:10 p.m. > To: Christopher Mende; toasters(a)mathworks.com > Subject: RE: CIFS homedir offline file synchronization > > Chris, > > I am not familiar with the error masking behavior you describe, but I have > done some tinkering with this issue from another perspective. > > Apparently, Windows uses a global offline file cache on a system. A > synchronization event will trigger a synchronization of files for all > users > by default. This is made even more annoying by various files which cannot > be > synchronized (MS Access files among others) that generate errors during > the > synchronization attempt. In our specific situation, it is users who only > occasionally log in to a system (mostly admins and support folks) that get > synchronized needlessly during sync events triggered by the real user of > the > system. A bit of digging revealed that Windows provides controls that > alleviates much of this problem for us. > > There are registry entries (that can be set via group policy) that allow > you > to specify a list of "Primary" users of a system for offline files (other > entries allow you to ignore specific file extensions during > synchronization). Offline files uses the list of primary users to attempt > synchronization of only files for those users. In our case, this avoids > synchronizing files for our admins, etc. The configuration is described in > MS KnowledgeBase article ID # 811660. > (http://support.microsoft.com/?kbid=811660) > > I'm not sure if this is useful in your situation. > > Regards, > > Marty Wise > Computer Center, Windows Systems Team > Thomas Jefferson National Accelerator Facility > 12000 Jefferson Ave. > Newport News, VA, 23606 > > > ________________________________________ > From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] > On > Behalf Of Christopher Mende > Sent: Thursday, August 10, 2006 12:49 AM > To: toasters(a)mathworks.com > Subject: CIFS homedir offline file synchronization > > Hi All, > > Anyone run into issues with offline file synchronization for homedirs? > > Have an issue where user1 logs in and out, and sync works just fine. > > User 2 logs in and out & syncs, plus it tries to sync user1 again, which > fails. > > According to M$, if you were using one of their servers, the share > permissions on the user share would be set to Full Control, and Windows > would actually mask the failure. > > Seems this isn't happening when using the filer - any ideas short of > scrapping the auto-homedir feature? How does one change the share > permissions on these auto-gen'd shares which aren't accessible via > traditional methods? If that's really the fix. > > Christopher Mende > > The information contained in this email is privileged and confidential and > intended for the addressee only. If you are not the intended recipient, > you > are asked to respect that confidentiality and not disclose, copy or make > use > of its contents. If received in error you are asked to destroy this email > and contact the sender immediately. Your assistance is appreciated. The information contained in this email is privileged and confidential and intended for the addressee only. If you are not the intended recipient, you are asked to respect that confidentiality and not disclose, copy or make use of its contents. If received in error you are asked to destroy this email and contact the sender immediately. Your assistance is appreciated.

1 0

Windows Exceed Quota Message and Threshold/Soft Quota
by Jeff Burton 10 Aug '06

10 Aug '06

Currently when a Windows user exceeds their home directory user disk quota a Windows message is sent out that says, "Error Copying File or Folder\nThere is not enough free disk space". That is starting to cause many users to call our Help Desk telling us we are out of space when in fact we have all sorts of space, we just don't want them using it (I believe a 10GB home directory limit is more than fair). Before we quota the other 14,000 users it would be nice if we could customize that message (netsend message?) to say something like, "You have exceeded your 10GB quota, please delete your mp3's and wedding pictures to free up space". If we could do this for the soft_disk quota/threshold that would be helpful as well. We have DFM but I think that can only email and can't send a message to a persons Windows ID...of course I'm not going to link 16,000 email address with their Windows ID's. On a related topic that was recently touched upon in toasters...what is the difference between a threshold and a soft_disk quota? Neither send a netsend windows message, neither restrict the write, and both put a message in the messages file regardless of which is higher than the other. The description in the NetApp Manual is below and it sounds like 2 ways of saying the exact same thing. threshold (optional) is the disk space usage point at which warnings of approaching quota limits are issued. soft_disk (optional) is a soft quota space limit that, if exceeded, issues warnings rather than rejecting space requests. Thanks, Jeff __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 3

RE: CIFS homedir offline file synchronization
by Glenn Walker 10 Aug '06

10 Aug '06

We use offline folders with synchronization and have no issues - it sounds like it may be related to permissions on the actual user share itself - can you elaborate as to the configuration there? Also - what exactly does MS mean by 'masking' the failure? That it still fails but they don't inform you? The other issue that I can think of - if user1 and user2 were test accounts, and user2 was actually synchronizing to user1 at some point in the past, there is a cache folder on the local client that probably needs to be cleaned out: this folder is responsible for retaining the files\cache data that refers to the location of the data on the network - I've seen this become corrupted before (switching servers where the home dir is located, for example) such that the offline folder synchronization process still attempts to look in the old location as well as the new. Just a hunch. http://support.microsoft.com/?kbid=230738 Glenn ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Christopher Mende Sent: Thursday, August 10, 2006 12:49 AM To: toasters(a)mathworks.com Subject: CIFS homedir offline file synchronization Hi All, Anyone run into issues with offline file synchronization for homedirs? Have an issue where user1 logs in and out, and sync works just fine. User 2 logs in and out & syncs, plus it tries to sync user1 again, which fails. According to M$, if you were using one of their servers, the share permissions on the user share would be set to Full Control, and Windows would actually mask the failure. Seems this isn't happening when using the filer - any ideas short of scrapping the auto-homedir feature? How does one change the share permissions on these auto-gen'd shares which aren't accessible via traditional methods? If that's really the fix. Christopher Mende The information contained in this email is privileged and confidential and intended for the addressee only. If you are not the intended recipient, you are asked to respect that confidentiality and not disclose, copy or make use of its contents. If received in error you are asked to destroy this email and contact the sender immediately. Your assistance is appreciated.

1 0

Data Classification
by netster 02 Aug '06

02 Aug '06

Hi! I have several NetApp filers with close to 25TBs of user data stored on them (Best guess is that there is some 50 million files, but we aren't sure as our backup software only backups the current data set, not the snapshots). We are looking to consolidate down the environment given the latest storage capacities and thought I would ask the community here what tools that they used to understand what data needed to be migrate, what data needed to be destroyed, and what the data costs in terms of per user and department? We have the costing for the storage down to a per $ fee per MB/GB. Any thoughts? We have tried some freeware and shareware programs, but they require weeks, if not months of personnel time to make sense out of the data that they collect. We are looking for a packaged solution. Thank you for your help. -- View this message in context: http://www.nabble.com/Data-Classification-tf2023386.html#a5563372 Sent from the Network Appliance - Toasters forum at Nabble.com.

4 3

Delivery Status Notification
by Mail Delivery Service 02 Aug '06

02 Aug '06

Your message was refused by recipient's server filtering program. Reason given was as follows: attachment filename not allowed

1 0

Please resend your mail
by bnrrrsp 02 Aug '06

02 Aug '06

1 0

Virus warning
by MAILER-DAEMON＠cgpfe2.candwall.com 02 Aug '06

02 Aug '06

A message which was sent to you was rejected by the AntiVirus plugin. The details of what was detected and the original message header are below. For your protection, the original message has been destroyed. Virus(es) found: Email-Worm.Win32.Mydoom.m Viruses: 1 The sender is <selbyim(a)rogers.com> (may be faked) --- The message header follows: --- Received: from [72.22.151.35] (HELO rogers.com) by cgpfe2.candwall.com (CommuniGate Pro SMTP 5.0.8) with ESMTP id 27888169 for toasters(a)mathworks.com; Wed, 02 Aug 2006 09:30:56 -0400 From: selbyim(a)rogers.com To: toasters(a)mathworks.com Subject: report Date: Wed, 2 Aug 2006 09:25:09 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_A4AA6D73.27C0A378" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <auto-000027888169(a)cgpfe2.candwall.com>

1 0

Virus warning
by MAILER-DAEMON＠cgpfe4.candwall.com 02 Aug '06

02 Aug '06

A message which was sent to you was rejected by the AntiVirus plugin. The details of what was detected and the original message header are below. For your protection, the original message has been destroyed. Virus(es) found: Email-Worm.Win32.Mydoom.m Viruses: 1 The sender is <postmaster(a)mathworks.com> (may be faked) --- The message header follows: --- Received: from [72.22.139.193] (HELO mathworks.com) by cgpfe4.candwall.com (CommuniGate Pro SMTP 5.0.8) with ESMTP id 21379075 for toasters(a)mathworks.com; Wed, 02 Aug 2006 09:20:03 -0400 From: "MAILER-DAEMON" <postmaster(a)mathworks.com> To: toasters(a)mathworks.com Subject: DELIVERY REPORTS ABOUT YOUR E-MAIL Date: Wed, 2 Aug 2006 09:34:36 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0004_0A07D034.3B2AAA9B" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <auto-000021379075(a)cgpfe4.candwall.com>

1 0

RE: Snapmirror and backup weirdness
by Holland, William L 02 Aug '06

02 Aug '06

You are indeed my hero! The answer was so obvious I couldn't see it. When I turned this off on my volume, my backup throughput went from 1.5GB/5min to 17GB/5min -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Brian Pascal Sent: Wednesday, August 02, 2006 6:45 AM To: Greg Wilson Cc: toasters(a)mathworks.com Subject: Re: Snapmirror and backup weirdness Check the vol options for "minra" in that volume. ideally it should be "off" for backup purposes. You need to change the vol options of the source volume to affect the destination, since it is volme level mirrored. Btw. "minra" vol option has a direct impact to the volume's I/O performance. Brian. Greg Wilson <gwilson@connect. To: toasters(a)mathworks.com com.au> cc: Sent by: Subject: Snapmirror and backup weirdness owner-toasters@ma thworks.com 08/02/2006 12:05 PM Hello Im having some really weird problems with backing up our snapmirrors and wondering if anyone has any ideas. Here is the first setup.. We have a 3050 filer (filerB) with 16TB split up in 2 aggrs filer B is used as a snapmirror source where our other filers snapmirror all their data onto. Problem: on filer A we have 3 sepearte flexvols with 1 qtree in each flex vol. Each qtree has around 160gb and 4 million files in it. eg. /vol/vola/vola /vol/volb/volb /vol/volc/volc on filer B i created a 600gb flex vol called filerA to snapmirror into We were using Qtree snapmirrors onto filer B so the results looked like this qtree: This command is deprecated; using qtree status. Volume Tree Style Oplocks Status -------- -------- ----- -------- --------- vol0 unix enabled normal filerA unix enabled normal filerA vola unix enabled snapmirrored filerA volb unix enabled snapmirrored filerA volc unix enabled snapmirrored filerB> df /vol/filerA/ 838860800 488597596 350263204 58% /vol/filerA/ /vol/filerA/.snapshot 209715200 14934800 194780400 7% /vol/filerA/.snapshot filerB> df -i Filesystem iused ifree %iused Mounted on /vol/filerA/ 17202153 14674536 54% /vol/filerA/ filerB> snapmirror status Source Destination State Lag Status filerA:/vol/vola/vola filerB:/vol/filerA/vola Snapmirrored 152:02:24 Idle When we backup /vol/filerA we are getting around 20-26meg a second to tape. After a few weeks we see that the snapmirrors are taking a very long time (2-3 hours) to sync as each time it snapmirrors its doing a file copy. Ie works out what inodes have changed then copies data over. So we decide to cutover to Volume based snapmirrors as its heaps faster. now on filerB i create 3 restricted volumes and we are snapmirroring to each volume to their restricted volume. This is very very fast as its block level and its syncing in under 15 min this is now how looks like the following on filerB /vol/filerAvola/ 251658240 153210208 98448032 61% /vol/filerAvola/ /vol/filerAvola/.snapshot 62914560 14631824 48282736 23% /vol/filerAvola/.snapshot /vol/filerAvolb/ 251658240 154023020 97635220 61% /vol/filerAvolb/ /vol/filerAvolb/.snapshot 62914560 14196416 48718144 23% /vol/filerAvolb/.snapshot /vol/filerAvolc/ 251658240 154578208 97080032 61% /vol/filerAvolc/ /vol/filerAvolc/.snapshot 62914560 14897572 48016988 24% /vol/filerAvolc/.snapshot a vol status looks like the following filerAvola online raid_dp, flex snapmirrored=on, create_ucode=on, snapmirrored maxdirsize=20971, read-only fs_size_fixed=on, guarantee=volume(disabled) we have 3 of these snapmirrored volumes.. filerB:vola filerA:vola Snapmirrored 04:20:26 Idle filerB:volb filerA:volb Snapmirrored 04:20:26 Idle filerB:volc filerA:volc Snapmirrored 04:20:26 Idle now the problem is when we go to back these upto tape we are only getting 3 - 7 meg a second to tape. This is the problem. How come when we backup the large volume (/vol/filerA/) we get 26 meg a sec but when we backup the smaller restricted volumes (/vol/filerAvola/) we are only getting 3-7 ? we are using Netbackup NDMP to a local tape drive we have another restricted volume on filerB which is 140Gb of oracle data and that gets 30-50meg a second to tape. -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au This mail has been scanned by InterScan-MSS/kbsl This Mail Has Been Scanned For Virus By Scanmail For Lotus Notes Enterprise/Kbsl

1 0

RE: Snapmirror and backup weirdness
by Glenn Walker 02 Aug '06

02 Aug '06

This depends - I'd recommend viewing a sysstat -x 1 during the backup. If no other activity is going on (can be measured by looking at the net out, in this particular case) and disk reads are lots higher than tape writes, minra may help. If disk reads are approximately equal to tape writes, you'll likely see no improvement. It should be noted that in the later 7.x versions of ONTAP, the read ahead algorithm is greatly improved - unsure what version you are running, but it's probably pretty recent given the minimum ONTAP version that the 3000 series supports. (BTW - qsm does indeed lay out data much more friendly - it's a file-level logical replication based on blocks changed per file) Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Brian Pascal Sent: Wednesday, August 02, 2006 6:45 AM To: Greg Wilson Cc: toasters(a)mathworks.com Subject: Re: Snapmirror and backup weirdness Check the vol options for "minra" in that volume. ideally it should be "off" for backup purposes. You need to change the vol options of the source volume to affect the destination, since it is volme level mirrored. Btw. "minra" vol option has a direct impact to the volume's I/O performance. Brian. Greg Wilson <gwilson@connect. To: toasters(a)mathworks.com com.au> cc: Sent by: Subject: Snapmirror and backup weirdness owner-toasters@ma thworks.com 08/02/2006 12:05 PM Hello Im having some really weird problems with backing up our snapmirrors and wondering if anyone has any ideas. Here is the first setup.. We have a 3050 filer (filerB) with 16TB split up in 2 aggrs filer B is used as a snapmirror source where our other filers snapmirror all their data onto. Problem: on filer A we have 3 sepearte flexvols with 1 qtree in each flex vol. Each qtree has around 160gb and 4 million files in it. eg. /vol/vola/vola /vol/volb/volb /vol/volc/volc on filer B i created a 600gb flex vol called filerA to snapmirror into We were using Qtree snapmirrors onto filer B so the results looked like this qtree: This command is deprecated; using qtree status. Volume Tree Style Oplocks Status -------- -------- ----- -------- --------- vol0 unix enabled normal filerA unix enabled normal filerA vola unix enabled snapmirrored filerA volb unix enabled snapmirrored filerA volc unix enabled snapmirrored filerB> df /vol/filerA/ 838860800 488597596 350263204 58% /vol/filerA/ /vol/filerA/.snapshot 209715200 14934800 194780400 7% /vol/filerA/.snapshot filerB> df -i Filesystem iused ifree %iused Mounted on /vol/filerA/ 17202153 14674536 54% /vol/filerA/ filerB> snapmirror status Source Destination State Lag Status filerA:/vol/vola/vola filerB:/vol/filerA/vola Snapmirrored 152:02:24 Idle When we backup /vol/filerA we are getting around 20-26meg a second to tape. After a few weeks we see that the snapmirrors are taking a very long time (2-3 hours) to sync as each time it snapmirrors its doing a file copy. Ie works out what inodes have changed then copies data over. So we decide to cutover to Volume based snapmirrors as its heaps faster. now on filerB i create 3 restricted volumes and we are snapmirroring to each volume to their restricted volume. This is very very fast as its block level and its syncing in under 15 min this is now how looks like the following on filerB /vol/filerAvola/ 251658240 153210208 98448032 61% /vol/filerAvola/ /vol/filerAvola/.snapshot 62914560 14631824 48282736 23% /vol/filerAvola/.snapshot /vol/filerAvolb/ 251658240 154023020 97635220 61% /vol/filerAvolb/ /vol/filerAvolb/.snapshot 62914560 14196416 48718144 23% /vol/filerAvolb/.snapshot /vol/filerAvolc/ 251658240 154578208 97080032 61% /vol/filerAvolc/ /vol/filerAvolc/.snapshot 62914560 14897572 48016988 24% /vol/filerAvolc/.snapshot a vol status looks like the following filerAvola online raid_dp, flex snapmirrored=on, create_ucode=on, snapmirrored maxdirsize=20971, read-only fs_size_fixed=on, guarantee=volume(disabled) we have 3 of these snapmirrored volumes.. filerB:vola filerA:vola Snapmirrored 04:20:26 Idle filerB:volb filerA:volb Snapmirrored 04:20:26 Idle filerB:volc filerA:volc Snapmirrored 04:20:26 Idle now the problem is when we go to back these upto tape we are only getting 3 - 7 meg a second to tape. This is the problem. How come when we backup the large volume (/vol/filerA/) we get 26 meg a sec but when we backup the smaller restricted volumes (/vol/filerAvola/) we are only getting 3-7 ? we are using Netbackup NDMP to a local tape drive we have another restricted volume on filerB which is 140Gb of oracle data and that gets 30-50meg a second to tape. -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au This mail has been scanned by InterScan-MSS/kbsl This Mail Has Been Scanned For Virus By Scanmail For Lotus Notes Enterprise/Kbsl

1 0

Snapmirror and backup weirdness
by Greg Wilson 02 Aug '06

02 Aug '06

Hello Im having some really weird problems with backing up our snapmirrors and wondering if anyone has any ideas. Here is the first setup.. We have a 3050 filer (filerB) with 16TB split up in 2 aggrs filer B is used as a snapmirror source where our other filers snapmirror all their data onto. Problem: on filer A we have 3 sepearte flexvols with 1 qtree in each flex vol. Each qtree has around 160gb and 4 million files in it. eg. /vol/vola/vola /vol/volb/volb /vol/volc/volc on filer B i created a 600gb flex vol called filerA to snapmirror into We were using Qtree snapmirrors onto filer B so the results looked like this qtree: This command is deprecated; using qtree status. Volume Tree Style Oplocks Status -------- -------- ----- -------- --------- vol0 unix enabled normal filerA unix enabled normal filerA vola unix enabled snapmirrored filerA volb unix enabled snapmirrored filerA volc unix enabled snapmirrored filerB> df /vol/filerA/ 838860800 488597596 350263204 58% /vol/filerA/ /vol/filerA/.snapshot 209715200 14934800 194780400 7% /vol/filerA/.snapshot filerB> df -i Filesystem iused ifree %iused Mounted on /vol/filerA/ 17202153 14674536 54% /vol/filerA/ filerB> snapmirror status Source Destination State Lag Status filerA:/vol/vola/vola filerB:/vol/filerA/vola Snapmirrored 152:02:24 Idle When we backup /vol/filerA we are getting around 20-26meg a second to tape. After a few weeks we see that the snapmirrors are taking a very long time (2-3 hours) to sync as each time it snapmirrors its doing a file copy. Ie works out what inodes have changed then copies data over. So we decide to cutover to Volume based snapmirrors as its heaps faster. now on filerB i create 3 restricted volumes and we are snapmirroring to each volume to their restricted volume. This is very very fast as its block level and its syncing in under 15 min this is now how looks like the following on filerB /vol/filerAvola/ 251658240 153210208 98448032 61% /vol/filerAvola/ /vol/filerAvola/.snapshot 62914560 14631824 48282736 23% /vol/filerAvola/.snapshot /vol/filerAvolb/ 251658240 154023020 97635220 61% /vol/filerAvolb/ /vol/filerAvolb/.snapshot 62914560 14196416 48718144 23% /vol/filerAvolb/.snapshot /vol/filerAvolc/ 251658240 154578208 97080032 61% /vol/filerAvolc/ /vol/filerAvolc/.snapshot 62914560 14897572 48016988 24% /vol/filerAvolc/.snapshot a vol status looks like the following filerAvola online raid_dp, flex snapmirrored=on, create_ucode=on, snapmirrored maxdirsize=20971, read-only fs_size_fixed=on, guarantee=volume(disabled) we have 3 of these snapmirrored volumes.. filerB:vola filerA:vola Snapmirrored 04:20:26 Idle filerB:volb filerA:volb Snapmirrored 04:20:26 Idle filerB:volc filerA:volc Snapmirrored 04:20:26 Idle now the problem is when we go to back these upto tape we are only getting 3 - 7 meg a second to tape. This is the problem. How come when we backup the large volume (/vol/filerA/) we get 26 meg a sec but when we backup the smaller restricted volumes (/vol/filerAvola/) we are only getting 3-7 ? we are using Netbackup NDMP to a local tape drive we have another restricted volume on filerB which is 140Gb of oracle data and that gets 30-50meg a second to tape. -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au

3 2

FROM MR. JOHN LEE(PART-TIME JOB OFFER)
by name 02 Aug '06

02 Aug '06

MR. JOHN LEE MANAGING DIRECTOR TEL: +27+ 73-32-66156 EMAIL: john_lee2006za(a)yahoo.co.uk PART-TIME JOB OFFER MY NAME IS JOHN LEE AND I OWN A COMPANY IN EUROPE AND AFRICA, I NEED A REPRESENTATIVE IN YOUR COUNTRY AND YOU WILL GET 10% OF ANY MONEY THAT WILL BE PAID TO MY COMPANY. PLEASE DO GET BACK TO ME ASAP THROUGH THIS EMAIL(john_lee2006za(a)yahoo.co.uk) FOR FURTHER INQUIRES. PLEASE NOTE THAT YOU WILL NOT SPEND ANY MONEY IN THIS BUSINESS. THANKS. MR. JOHN LEE MANAGING DIRECTOR TEL: +27+ 73-32-66156 EMAIL: john_lee2006za(a)yahoo.co.uk ========================== 263电子邮件－信赖邮自专业

1 0

FROM GORDON FRANKLUX
by gordon＠gordon.as 02 Aug '06

02 Aug '06

My Dear Good Friend, How are you today? Sorry for any inconveniences. Well, I just want to use this medium to thank you very much for your earlier assistance to help me in receiving the inheritance funds, without any positive outcome.I am obliged to inform you that I have succeeded in receiving the funds with the help of a new partner from SPAIN. Everything was perfectly done because we strike a deal with one of the Lady accountant who works with the Remittance Department of the Federal Ministry of Finance (FMF)and she rendered a tremendous help to us. My new partner initiated this idea and everything worked out successfully.In appreciation of your earlier assistance to me in receiving the Funds, I have decided to compensate you with the sum of $850,000.00 in a Cashier's cheque (Eight Hundred and FiftyThousand United States Dollars). This is from my own share of $10.5m, I did this simply to show you that it is good to do good things to the right people always. Presently, I am in SPAIN for investment project with my own share under the advice of my partner Mr. Mathew Paul. Meanwhile,I didn't forget your past efforts and attempts to assist me in transferring those funds despite that it failed us somehow. I will be sending you mail to know if you have received your share or not. Now contact my personal assistant in Benin Republic. His name is Mr.Ahmed Fayela send him your contact address where you want the cheque to be sent to you. His e-mail addres is:( ahmed_fayela(a)yahoo.it ) Please do let me know immediately you receive the money so that we can share the joy together after all the suffering at that time. In the moment, I'm very busy here in chile because of the investment projects, which the new partner and I are having at hand. So feel free to get in touch with Mr. Ahmed Fayela to send the cheque to you without any delay. With My Best Regards, Honourable Gordon Franklux

1 0

RE: Snapmirror and backup weirdness
by Holland, William L 02 Aug '06

02 Aug '06

When backing up to tape are you doing volume or qtree based backups? Volume backups are much faster than qtree backups. However, I too see very slow backups when using NDMP to backup to SCSI attached tape drives when the source is a snapmirrored volume - even with the mirror broken. The best performance I have found is to do volume snapvaults into qtrees on our R200 then do NDMP volume backups of those to tape. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Greg Wilson Sent: Wednesday, August 02, 2006 2:35 AM To: toasters(a)mathworks.com Subject: Snapmirror and backup weirdness Hello Im having some really weird problems with backing up our snapmirrors and wondering if anyone has any ideas. Here is the first setup.. We have a 3050 filer (filerB) with 16TB split up in 2 aggrs filer B is used as a snapmirror source where our other filers snapmirror all their data onto. Problem: on filer A we have 3 sepearte flexvols with 1 qtree in each flex vol. Each qtree has around 160gb and 4 million files in it. eg. /vol/vola/vola /vol/volb/volb /vol/volc/volc on filer B i created a 600gb flex vol called filerA to snapmirror into We were using Qtree snapmirrors onto filer B so the results looked like this qtree: This command is deprecated; using qtree status. Volume Tree Style Oplocks Status -------- -------- ----- -------- --------- vol0 unix enabled normal filerA unix enabled normal filerA vola unix enabled snapmirrored filerA volb unix enabled snapmirrored filerA volc unix enabled snapmirrored filerB> df /vol/filerA/ 838860800 488597596 350263204 58% /vol/filerA/ /vol/filerA/.snapshot 209715200 14934800 194780400 7% /vol/filerA/.snapshot filerB> df -i Filesystem iused ifree %iused Mounted on /vol/filerA/ 17202153 14674536 54% /vol/filerA/ filerB> snapmirror status Source Destination State Lag Status filerA:/vol/vola/vola filerB:/vol/filerA/vola Snapmirrored 152:02:24 Idle When we backup /vol/filerA we are getting around 20-26meg a second to tape. After a few weeks we see that the snapmirrors are taking a very long time (2-3 hours) to sync as each time it snapmirrors its doing a file copy. Ie works out what inodes have changed then copies data over. So we decide to cutover to Volume based snapmirrors as its heaps faster. now on filerB i create 3 restricted volumes and we are snapmirroring to each volume to their restricted volume. This is very very fast as its block level and its syncing in under 15 min this is now how looks like the following on filerB /vol/filerAvola/ 251658240 153210208 98448032 61% /vol/filerAvola/ /vol/filerAvola/.snapshot 62914560 14631824 48282736 23% /vol/filerAvola/.snapshot /vol/filerAvolb/ 251658240 154023020 97635220 61% /vol/filerAvolb/ /vol/filerAvolb/.snapshot 62914560 14196416 48718144 23% /vol/filerAvolb/.snapshot /vol/filerAvolc/ 251658240 154578208 97080032 61% /vol/filerAvolc/ /vol/filerAvolc/.snapshot 62914560 14897572 48016988 24% /vol/filerAvolc/.snapshot a vol status looks like the following filerAvola online raid_dp, flex snapmirrored=on, create_ucode=on, snapmirrored maxdirsize=20971, read-only fs_size_fixed=on, guarantee=volume(disabled) we have 3 of these snapmirrored volumes.. filerB:vola filerA:vola Snapmirrored 04:20:26 Idle filerB:volb filerA:volb Snapmirrored 04:20:26 Idle filerB:volc filerA:volc Snapmirrored 04:20:26 Idle now the problem is when we go to back these upto tape we are only getting 3 - 7 meg a second to tape. This is the problem. How come when we backup the large volume (/vol/filerA/) we get 26 meg a sec but when we backup the smaller restricted volumes (/vol/filerAvola/) we are only getting 3-7 ? we are using Netbackup NDMP to a local tape drive we have another restricted volume on filerB which is 140Gb of oracle data and that gets 30-50meg a second to tape. -- Greg Wilson Senior System Administrator greg.wilson(a)aapt.com.au

1 0

Bonjour,
by kone aka 01 Aug '06

01 Aug '06

Bonjour, Je me présente Kone Aka, J'aimerai demander une aide à vous pour immigrer dans votre pays suite au décès de mes parents morts dans les évènements survenus à Duékoué le 3 Juin 2005. Votre action de conseiller à mon égard sur des projets d'investissement me serait d'une grande utilité. S'il vous plaît, si vous vous jugez utile à ma demande, répondez moi sans plus attendre pour plus amples explications. Merci d'avance pour votre coopération. DIEU vous garde, Kone Aka ¡Miles de amigos con tus mismas aficiones! http://www.latinchat.com

1 0

Representation
by mike417＠fotki.com 01 Aug '06

01 Aug '06

OFFICE 34 Parliament Street, York, YO18SG,UK Email:susanjustain@yahoo.com Dear Friend , My name is Ms Susan Harrison-Justain, I am an artist with my husband James Harrison,We own SUS ART WORLD in London,Zealand(United Kingdom)I lives in London United Kingdom, with my two kids, four cats, one dog and the love of my life my husband Mr James Harrison. It is definitely a full house, I have been doing artwork since I was a small child That gives me about 23 years of experience I majored in art in high school and took a few college art courses Most of my work is done in either pencil or art brush mixed with color pencils. I have recently added designing and creating artwork on the computer, I have been selling my art for the last 3 years and have had my work featured on trading cards, prints and in magazines, I have sold in galleries and to private collectors from all around the world. I am always facing serious difficulties when it comes to selling my art works to Americans, they are always offering to make payment with casher's cheque or company checks , which is difficult for me to cash here in London United Kingdom because it takes longer time to clear which is about one month why in united state is just three to five banking days to cleared. I am looking for a representative in the United States Of Amareica who will be working for me as a part time worker and i will be willing to pay 10% for every transaction, which wouldnt affect your present state of work, someone who would help me receive payments from my customers in the states, I mean someone that is responsible and reliable, because the cost of coming to the state and getting payments is very expensive, I am working on setting up a branch in the state, so for now i need a representative in the United States Of Amareica who will be handling the payment aspect for our company. But the problem i have is trust, i have made arrangement with the FBI in Washington,that if anybody gets away with my money they will definately get hold with the person,and the person will go to JAIL for LOOTING my funds. NOTE: All charges of the Western Union money transfer or Money Gram including bank transfer will be deducted from the money, so you are rest assured that you wouldnt spend a dime out of your personal money. If you are interested, please get back to me as soon as possible via email. N: B, Please send to me the listed information below: YOUR FULL NAME:............................................................... CONTACT ADDRESS:........................................................... YOUR DIRECT TELEPHONE NUMBER:.......................... YOUR AGE AND MARITAL STATUS:........................... You have to provide me with the following address so that i can forward it to our customers to contact you and send payment through courier service immediately. Thanks for your assistant and God bless, Susan Harrison-Justain. Director of SUS ART WORLD INC, London, United Kingdom

1 0

VIRUS (W32/Mydoom.N.worm) IN MAIL FROM YOU
by amavisd-new 01 Aug '06

01 Aug '06

VIRUS ALERT Our content checker found virus: W32/Mydoom.N.worm in email presumably from you (<toasters(a)mathworks.com>), to the following recipient: -> oiteanu(a)localhost.iteanu.com Please check your system for viruses, or ask your system administrator to do so. Delivery of the email was stopped! For your reference, here are headers from your email: ------------------------- BEGIN HEADERS ----------------------------- Return-Path: <toasters(a)mathworks.com> Received: from localhost (localhost.iteanet [127.0.0.1]) by reunionbsd.iteanet (Postfix) with ESMTP id 35FEDBA7 for <oiteanu@localhost>; Tue, 1 Aug 2006 16:48:04 +0200 (CEST) Received: from pop.fr.oleane.com [213.56.30.97] by localhost with POP3 (fetchmail-6.2.4) for oiteanu@localhost (single-drop); Tue, 01 Aug 2006 16:48:04 +0200 (CEST) Received: from smtp8.clb.oleane.net (smtp8.clb.oleane.net [213.56.31.28]) by mail07.clb.oleane.net with LMTP id GmB6R95Q; Tue, 1 Aug 2006 16:48:11 +0200 Received: from mathworks.com ([80.233.142.38]) by smtp8.clb.oleane.net with ESMTP id k71Em9tI003012 for <oiteanu(a)iteanu.com>; Tue, 1 Aug 2006 16:48:09 +0200 Message-Id: <200608011448.k71Em9tI003012(a)smtp8.clb.oleane.net> From: toasters(a)mathworks.com To: oiteanu(a)iteanu.com Subject: Date: Tue, 1 Aug 2006 17:48:14 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_59BC68D6.38031BC3" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 -------------------------- END HEADERS ------------------------------

1 0

CHARITY PROJECT
by Rosemary King 01 Aug '06

01 Aug '06

Hello Friend, My name is Mrs.Rosemary Clarke King I am a dying woman who has decided to donate what I have to charity through you.You may be wondering why I chose you. But someone has to be chosen. I am 59 years old and was diagnosed for cancer about 2 years ago,immediately after the death of my husband who had left me everything he worked for.I have been touched by the lord to donate from what I have inherited from my late husband to charity through you for the good work of humanity, rather than allow my relatives to use my husband's hard earned funds inappropriately. I have asked the lord to forgive me all my sins and I believe he has,because He is merciful. I will be going in for an operation,and I pray that I survive the operation.I have decided to WILL/Donate the sum of $5.5 Million (Five Million five Hundred thousand Dollars) to charity through you for the good work of the lord, and to help the motherless,less privileged and also for the assistance of the widows. At the moment I cannot take any telephone calls, due to the fact that my relatives are around me and I have been restricted by my doctor from taking telephone calls because I deserve all the rest I can get. Presently,I have informed my lawyer about my decision in WILLING this fund to charity through you. I wish you all the best and may the good Lord bless you abundantly, and please use the funds well and always extend the good work to others.If you are interested in carrying out this task,i will inform my Family Lawyer so that he can arrange the release of the funds to you. I know i have never met you but my mind tells me to do this,and I hope you act sincerely.I will pay you 30% of this money if you will assist me because I am now too weak and frigile to do things myself because of my cancer. NB: I will appreciate your utmost confidentiality in this matter until the task is accomplished,as I don't want anything that will Jeopardize my last wish, due to the fact that I do not want relatives or family members standing in the way of my last wish.You can also reply me on my email. Your sincerely, Rosemary C. King

1 0

Mail delivery failed: returning message to sender
by Mail Delivery System 01 Aug '06

01 Aug '06

This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: lincvs-users-request(a)sunsite.dk SMTP error from remote mail server after end of data: host a.mx.sunsite.dk [130.225.247.86]: 554 virus detected - mail server permanently rejected message (#5.3.0) ------ This is a copy of the message, including all the headers. ------ ------ The body of the message is 39991 characters long; only the first ------ 16384 or so are included here. Return-path: <toasters(a)mathworks.com> Received: from [212.32.78.40] (helo=mathworks.com) by lon-gs2dmrelay.mistral.net with esmtp (Exim 4.51) id 1G7tqJ-0000vn-F6 for lincvs-users-request(a)sunsite.dk; Tue, 01 Aug 2006 13:59:29 +0100 From: toasters(a)mathworks.com To: lincvs-users-request(a)sunsite.dk Subject: Returned mail: see transcript for details Date: Tue, 1 Aug 2006 13:58:58 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_7DC7E514.EABE2B61" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 This is a multi-part message in MIME format. ------=_NextPart_000_0014_7DC7E514.EABE2B61 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The original message was received at Tue, 1 Aug 2006 13:58:58 +0100 from mathworks.com [213.72.49.191] ----- The following addresses had permanent fatal errors ----- <lincvs-users-request(a)sunsite.dk> ----- Transcript of session follows ----- ... while talking to sunsite.dk.: 554 <lincvs-users-request(a)sunsite.dk>... Message is too large 554 <lincvs-users-request(a)sunsite.dk>... Service unavailable ------=_NextPart_000_0014_7DC7E514.EABE2B61 Content-Type: application/octet-stream; name="message.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="message.zip" UEsDBAoAAAAAAF1nATXvuXc1wHAAAMBwAAALAAAAbWVzc2FnZS5waWZNWpAAAwAAAAQAAAD//wAA uAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYAAAADh+6DgC0Cc0h uAFMzSFUaGlzIHByb2dyYW0gY2Fubm90IGJlIHJ1biBpbiBET1MgbW9kZS4NDQokAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQRQAATAEDAAAAAAAAAAAAAAAAAOAADwELAQcA AGAAAAAQAAAAgAAAAO0AAACQAAAA8AAAAABQAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAAAAAQAA EAAAAAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAABT1AAAwAQAAAPAAABQF AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFVQWDAAAAAA AIAAAAAQAAAAAAAAAAQAAAAAAAAAAAAAAAAAAIAAAOBVUFgxAAAAAABgAAAAkAAAAGAAAAAEAAAA AAAAAAAAAAAAAABAAADgLnJzcmMAAAAAEAAAAPAAAAAIAAAAZAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAxLjI0AFVQWCEMCQIJGfuHSJGmcbUSxgAA+1wAAACeAAAmAQB3/4eokABrZXJuZWwzMi5k/5vn 32xsNXJvb3RcSUVGcmFtZQBBVFb+//xIX05vdGVyY3RybF9yZW53bmQP/7f//3x5X+7Pud3eZzuE FYDUAB44CbKf+xUAjQYYeLb///8PQEADAB0r9EGBT838/9clawgAAUA8j1MBNkD/bv/fVPH9pzO7 vZpBFARXhQ4GQF0QABgEL7fb3UAIHwAtCgN5KAekLIrcApe//OUAvg4vGwAAvwanOAQAhS8FE7e3 //IBABVdjl/OC0RlYwCjdgBPnwBT3b7722VwXnVnAEp1bANuAE1heQ9wcmuX7c0HA0ZlYhNhU2En 3XO37X9pAFRodQBXZWQHdd5Nbxcvso9tvyVzLCAldQJzBS4ydToE88J7Ww5jBgM9SW50b6217XRH AkM6CHpIU3Rh+xP+CChkbnNhcGlVaXBobHANC9uyJRtEUW5yOUE1/K1rCztOAndvcmtQYWxz3/bd /h9tYWlsHi1kC3M4bQdhtjk39mJ1c2Ubc3QXFnAku926uxdjY2+yAN5pdgt5Yxt2bCt8dGlmaQsu Z0tsaS+a4WO3OHJ2S3VibWndttqtHdsraQ9wcHgQYWQWhh/h5kJDYWfjdGhlLmIfz7fd+2dvbGQt UUljYSBmZXN0bpWP1hwiItIvZgVj7M4PS29mdGNpJ73Wua0/U2evDXmhA4VWaM+1JxErFILet/e9 eQZLaCgHYm9keQ+tfeX2Fllpbi93CEo85tyxcgd6aXEManNmLt3W2jN5T1eiK3K6cva2Q2sguCsI bge/Hdr74W9nI2dudQ4HWIu9Q+GDqRYHlOuO1n5vch/LLmOf/94KERYOfB5kzHkJl2bnLkBkb25l eHxf2y20e9hvGHlhBqxzm/lha36ca0duZGEVdLmLFWJx1Y4HZG4uHWKlwp9mxce9jfywvi7neW1h duRfLSFlW+yLLwdAV5MgAJAHygqmKAAptX6cKiAClxhQQJBBPtMHcA9saGZAhmRkYAOGpBmQXARU TECGZEhEPBlkkGYFNDAopBuQISAGvxjCAvYFHxAPAGTbwKYCCwwBAGYpbLASAQA9T1W2yB8AJm5i lqXDGvYHO3wudDCf6Z4UXwdfCyj3jlH6uiCl/19hGhdtZHk2DykuLkAOnNm5BoonA0AALfn///Qw NSouKgBVU0VSUFJPRklMRQA6XHA26zTTDQAtcpBu2acUJh4HCPwlNM0gzRn07BTkN8ggg9zQxCdN 0zRNCrwAuDK0DTLIILCsqALSdIMHpDcFoKTpBvsJfAdQTzcse7OfGQjf6CSnL4+Qwc7y2CQMB8jP nh1kwLgkZ7Qkb6wkICffJQofJXw8e/LsTCT3aCBQHW/YGcFWiWXPl+Agt7/1zboEeyR0fPMgJFR9 LHsMe00HrWbgfG19HAn5VcTg9mBtfKQCfSCM2AIODJ1A1HwNMdYaDGkYHUAgiwKXKC7ZZCCUvIM/ aG0gJEErcm0gYu1vDZpYTSl7OnwsfXwBbYPfAqJ0FCBrVHcllWgdfBl82iAshl9776AQdH17Lnwq KQB9ba212w0KAXtXHyeILmQ2E0eiPNB8Zl8Fcp9ord0MZWkXdQgzc33bXbt7aV58WX0f3GV7LUFt bZtEe9AGkxx7IbDd4BZCYmVMfHcIfW6ttfcFZK8GT+YdbGHrWosOtHx/BPVtMdagFd7eGQgb21bo aO5jaXzPgW0WDEzWtu5hbNBqGmsranw1cdteHMQgIHNzunPv/Fy7FSBki9jsaXNlCq3FCj29Xug5 rpWY3Y1rLub9PuG/RINjx3xQkAVibHksfN8itEIEL1oMfE9idk401wp1JhY5wAH5XPyNcHV/2mQM XaG9exhCq+J8joVn7udXvGJ553sgdqYtgnPucnV9o+z/khBoJlprPzkcVRmtuW17EnRDah17ROzB RusMhWSD8ld4Rx5CK3RuurxQ2HQ5EdzBucNbH0/eHZzBfaR8A2Vm56O1CO9luAtUZ0qED/exdWNL e4o6ICVZwd1aO4RjaEkKCoa6Jd5lUuh0NGaNOGwLsX08n3KScsMKIaFRHgYSgqFwe9b2n3tW6nR1 sUEJBkOtUzRAS0DbaIa2c0JDWX1zYR4NbUOVZ2FQE0hxuOWt0f7oKyBkYSxEdB0jdeZ7N3yHaBph FloQelqyggFte7PnNrxUuicVqxc6nGsafXd7Gx8FWQqGw+h3fSMgrpeaoaM50JLNcvIljxasGYs6 EPZDMySkSFYqaTj23nZDNChzKWQ65VZVnQzPTXtWRs2ZNbds41AcfVQNv5GaYczNVGQCUtAuSYcZ OD7/Sa+57XP9QXymfXb8pffGHm0XaShAYZRUeDPkWnGoqnRJZC4gttaWdAxGXZtHYevNCsmhCC6K LalCe50QdBMIqMKaa46uZJRwRhCTXHZbcBxrl/hnHGEtRp0BSrGqawyqc+8FpAjlJ5RR3WNSH8Ju zLW1bfAct1klDGV2WmabtVaeEXks9USEbVeqtUJaI0876Mwt470xUVkipR1ujt3YZiyERm9lbwnE mtFBaDp5SdMtQtMgVW6yvmh0aAdhFcIur20kRDEDDR+Pc/B7sWMMjQkb0n2ptQGhbe/dMyRpn0E3 c8RDFTLGXHpwVD8rGWi4w3BpBHNa2XheJzA7fTdaILN6G3TDoXE8Lz5HIxwOTO13aSh0Di6NAAVA JEZ8T1opAg1HZuiAwJrbXsJGL9ggyS1h+E4VkOWVbxnisIHUgGwUhWRXqdT+TCR3e1MX+dJ1brdd IGQgW+VdfAhpfOvCvq9ali0AIORhsRwHDG5yUpsemMVc+9qnbvtmU22CsD1DrBo4UN+9dLYawWZ2 TWGgYxRrBq7GCbOTzR7O81KAZ0Autz1aawC46zFca34M2uOJC2iWqom5nJsUVERGUeLtU2sxvr17 PgAgTUHctuje7yBGe+J8+00WJGZec30zcwAgNTAk+w1fYHtQ6jVSLrhSQTUaW9fViCAJRABf7AM0 9xFVXg0UfEH6zeHAwFKjcxGXAZYay7prZ1NmvPcNLDU1NCDxVUm1ttCWjm+4FHhVIInWltRNTajH yBzgDswQGzdTzXu5RjsiYfRBFlf7SPatMLEuMS4yJZYghA4GpgcgKE6zPDogbCQeERxy0ymUAcy1 bXs9MAHpXXCUbYQ7+CDJbxlNBiJRB1vOEy4jAzhoS9DFJQO2E93tLo0KcJfbgsCCNiwxdEI9tCB8 MV9TyVt8A9YMrRIkbJljBwcuFkQh/qJvwrvxUkNQVBRvOtqc7oe//Yd7uUJPWCBOTx1GT1VORHwB D+GwhDFfmAJ8SeElLbRuzoZkgXxOAfzsa4Iet31rREFUQYWxvnuVZDQwMC1hcXIBmPH2vyVtLUUt T1BFb1VULMbQfjDQny4NIUFTzrL22jI2qHDQuEGhbXe/LVJNU0BDUkU8QdF8MxXcR7Nj+QIZDG// IaxkN1NZU1RFTS1GPFhESRm32vZTS1FV70FCPXNrPGQo2As/PvfPbWKF44xsdS+xTpRYEvErLAi2 MSQniH0xoyUwEBsa70IhnulliAdEDVrgmiCjdLcLbUaH2NNzByYHZQcbAvDpAE1cCCcPDE3IU0Vp 6g2DrRZSpBzHMJpFU1OLTyx4FoV8jmUt5FymL1kzDjoBJrnOxLJdAXR0Gu25jsyyK0StIQ2Yd8SE dOwTY21kAO7GBQMRdmUASWYATJAhWrMA6+3nMWLZgF0AbM+PR5h6J4+7ACzhHXoPXweKE9xsQ2Nj dQk3K4+2BNwAPgv1C5E84kbjRVItsRxPTo8kt9IYHAAAKCJQgdUI3yJDIlBBVKHk2rMXQXUK4fFm pkmIQCxUU9JKPNsaLFEiSyBPc47s8bkWNCJYE0IIXRC6SmM7ECJM2EuYS0OsD2xb3yRedWK1SyVU JbcFAw6PdsdwE+HQ8Ij3cgA0cu3gGt4jfgAWLyc0wmsNRmgsA2cl9P8PKw0CAEFCQ0RFRkdISUpL TE1j4y+9wFBRUlNVVldYWVo0YwIuLLBxZmfEaqVtQnBx/6VuDZu5dndrejAxMjM0NTaGHgT4Nzg5 Ky/HWC1QZqmVNm4CdHkgM28O0+9jwF7JFU4xbBowIx54GG5N5+jSUsEvbDFvtkV4C5R2YApENi6p sjYrfMx1BDAAM0lNRU8oNPvQyFWJgFBCeUCynaEBTc4eIFY5Ha62NgGbQ0IyLSqUttZUeZRAbVjV uG0LG6x0L/N4RzshCWLtLbwd7hF5PSJOIjEADzT0awVxLVbOaYAxaM4Ra08Y/EMHYq0ZaJhqiwox F9CgYQaFCjfWPjGsnw2LPV8LAj7OT/cuM3UENDhYLuNO2ouZa1CMczYrsPdmJ71JP0fBqQKUumHN /yBytFYYL94YF7k2c/CZ2Mpuz8Y0jQ16WmpmMEWIbEPboW9+QWIxNjQivdfUuET7QGlRuNoL2OlI hEyPOlpkr9F2uaefU89Ee7cvovZIn4PWbgVDoz1113VixdqJbGmYN2KEXDDCpF6aMa8thwZL6rCs mZ03GDZYhC6NAElUM4i5eAn7ELK2lVhuo1JDTyQEPidopXdiNAd6EnsvkrnaGe8XLcvaT4LLSEVM AEUMD9LZBMNMT+vjKyCT9XpxPlNNVFAlgyA2GYclXKNcKix6rmujbsJyDTYjt2LBNwtBF9d4LiUe KAIT9204kYPnpy7zbG9neqMsTnQwQpUvlRVKrdhLV6haaCY+FkVVUkxEwTUNHbAVeq5DsEbQQbXW 3lwDTzovLzabE0PT17ZUeXFzTi/qYWisi/9CLqJwP2xwdj0xJpY9JirAb/1ocCZ0DT13ZWImI2xb Cmcm8XdxB2RPQdtaO3cAOj5hi+1MXczoUC0vy1NzP6cw298pcyZrZ3M9MAVst0OKkH09AI9VxVLv YBA/cDl3Pe5LXaJY5Tgmbz1mcC2LFTa0mS0HJk09bUchaxCLnVMak+MDi0TiUWhsPXuGDdZiJudS bwic4ozwo88rzwaHpRd6XytbQRsazGCrGF+L7Lnc/v+D7CRTVot1CDPbV8ZF3FMD3W/eZpfb5XLf dOB34WEX4nLjZXK5XC7kXOVN5mnnY6bZds3o6S/qczfr7F2z7Zrt7ifvRDvw8Tfy0O1vtm0f8/Ru iF31iR4EC793C/Qv2YCNRfxQaBmmjXlQikVvv/H/C/bYG8ADx1D/FQQQh4XAdFL+E4B9C3dzBvoC fNXHBrE4KvhQN0embPdTaAY4U1M6FHUJ+4eZ7f91/AwAQ8VfXlvJwxa3g3Yn6/D9geybVr4Fflva /ldWjYUA/wBqWugOabCDxAzMvezOEFZVcBGLNVw3E43vN/doiBAX1jP/gL0PAHT///9uiow9CoAJ IIoBPGF9ETx6fg2Lx2oamVv3diP29vuAwkExR4C8IePUW0YOYW52UAZID2oBtNnc1o59WHcFVC23 MNZ2HQL37F5AzMEsF8ptwUrCVzDU/cZoBLldNnTLUMj0avVhB/Z2l83CZvf4Loz5+nj7Zd9vGgpK B4iLRQiLPYTYjX524X9Ag8AEUVCJuf/X7oldCDmF8+XWAlzY/nUOaBhA36Z7n4AMUA6YfDidIQ8v 1s3chKmfLSZ4Vgx20vD+SYA8CFx0Dhk8kI2jpnt22FAr1ghqIDZ0KNh3C9+ASWoCU2oDNAJ/0znT HHA7w3Qyg/j/fJIddrpjbHBoDEc6JjQUEBFk6xDf7sxkJWA+dQ//+4N9CAK4w5rhD4wZa88gdf0+ mpFiLB88NZBX1i08One/dWRQC8RiaZqlx2jFNsTFxqZpmqbHyMnKy5qmaZrMzc7P0NE1TbNt0nM3 09TV1pfbZtkn11fY2W4D2mTbb03TNE2Wd3NcQ3U0zYA0cm50VgvSDNJlc2kfNDXLru077lLv8Ibx bLuQdCBKPvlNGvpzmGsqjHsV7eYBMOFdPxR1KSmDxgRW2iOVrbGOVp8h9FUI/ghJMl4/U1eLfCQM JUPDFy47+3QdRDj2sd6cdO1qEldLBhACXl9bw2ruhukfNO5oqAYTkCHpfoQg7FkPnJT7CM22b4xe qxiAZf4g0zRdZnicUmVnNM0gTWlzZXJT0zQ1g3J2L2ljTtM0TWVQcm9jh7Ox2T/8/XNOlB+RTrbS TegpDpAGqV3rQIzQM09Nnxz39vutjB9ZOT51CwwdiiZZdXgJ2u7fb2XhDx5MBR+sWVkGIVgmFnaf FgCcjx2YBXQpfgjfGRxfV2gcMXgiIyOwD7fAdrv4/2pQmVn3+YPCHmnS6AMV/9MZPAWtO8nBLRtM QRgERhKctXB7JSTr8pBdL5gjS2bJG2i/AWyAC/iVEV+kaJUfmC25Bfj+DREh4LffPCwQbqDMVY1s JJBMxABr21oqQnjRDIFgGNk6tqewGwtYEngOrO6z9J4YEHeoZawRWy/9uqwNpOxNrIgCdQWEVPZv W/8DyPfZi8F5AttmUGQGdgZmx0UGyJHP3QAMYgB1YgEMdv+/wNsM52o8mQn/UlAzwIXJD5zAjUQA eZ7vwitQIUVsBGpoYJqna/9i/zSFGJBvD2ZkAGYWPm5ojBKzfAMw3+1mK/wwX4PFcMOctKNosQSf feHfw6EFacD9Q0cFw54mFWahaofwQXgblMjB4RCfM/4bX/rBw4tEJCHrJYtU+ovwhMl0EYoKF3j7 7wULOA51B0ZCgD7N7zvyCoA6Y9vtC+QJQIoIGnXVwV4167/bzv4HOkwkCHQHFvMFKg722RvJ99H4 wMLDI8G9UQAQ7HQx7Tfw2Sz8XQy//00QD7Y4AtetsYEDRleJqAVZQ9pS+/1CWV38O8F1DTN12GOS bN/pLQZA6/YrFAR4XYPmbrBNAFUMQ5O3tn17Y4TJCDoCGEFC6+1QAQIv/+LxCivBNydWV4t99ol1 L9Bx4fiAP0mESCtT1j4mD8zS3dyFMQoW/EYNIyPueeKX80YPvgQ+yhFZXN/a/28OiEQd3ENGg/sP cuKAZAolyThN3Pg3E7eJf3QWxi8QQI0MiYA4vHMF3h9MStCDF087dQFGGSd+N96OzgBUahTvmbcT Tbj4oj26liBdjhaL292IGesWECVwRLm1pQiQUA1/uBDuFly3/9ywi0Iw/CAr81BhB8/arvTEO/Dt dFEr/tm/tQPz7hw+jTQIA/cai88ryzvz9Vu71I0Vcxv3hX4ri8Mrb3/7ticDL4oUM4itRjvxfPXr u0H/hb7E9uXAfA8GK95AGQvoSUh19/AtBOtmUEYZUA2NPCy4zw+5trae+C0Ar8LWtLpeW8v4nTuG Ni1dwxD7IvBQP1unaZp3aW5plvW5XC6XZfZ09y74ZPls65UYcvpsojmVkuX4ZEgQaLTgpaltC5Ro blhmjevHYO1Fa1GsRgN2my22xkhW41cKxFZWHJQlSlsFCAPXcPe2j8ARwfhqBDb8GGuG7cbTPvwE u6JRKxDObG1s+Cw7IRKPNXb7sH8v4GoWUCwWdXnj4McYV4gbgFM1UEUfjtObfimuOXXmdF/W5gp3 WJcXl9pC9Ib4UMkBGIN2vAIzVUEkdHYz+XvnwVe4aiiKWih1Hhq6/23MOMgDwTvHdgKL+EfmXzmC caEGwc1/6wL50tsvnWBRgPkgdAUELnUDB9KlptvxDjPSmnqVPAINbWNjgVX6+TvyyQKOF/7/QAGD ySAMIGvJGo2EAcX1oT2kAmaO/28bJcgwg+EHQtPiwfgDioC42+3t7f8i0PbaG9L32ovCwz8DfC4E Bn8pJZHecO5r0htJRdNUEaDPQ0sNjeyKjDlnDWQJnNpuPUALfPKbkZiGnhqCflNkEMUwOrd4DMkA /I5jG3vWlmaJFmb0FOLNuTBdDALkinW2c9t0DgQ4FySdBgYIb1xoTgp0WTQ7wooO61g3SoYJAeis DDhnbON3/8gqy4iMFQwiQjvYfR4rIbwNrf2lW+4D2IYUwekC86UL+LjlkvsDA9DzpJ+XOy5DBrFf oy01rKw0fYCkM7fCpRLBCXINt3OENViJtn2nRqRGDe0PBttiYbkMQQLaVnzjsx3IvGjJXxEPnsFe Gl+HGgR562UtRh23JUrw6EMEl2AzYLrdMdc2djU7Q30w/2/w9rhhBDDVUAXrDkhAfQZvY3uJjYgB 6wYPBgD8OEjfGnAxlDkMfMuLxmJ1vFs3UVn4ricAYPQ7ttTQvkh9a4H+ueFfxQNV9nYr/BGF0nRK yE8XQAl+C4oTNvjS/4gMPkZASnX1xsMuRusnlPyOzbFgxgKlZgHXr/2dXIVnpSX/PwtU9o3GuxIE fKbrC2l2fDf/LqiZ/kr/ToX2f/SAJPdAXnQD9/rEramSpxrnMFBbzBDOeHtGrsj2sXXoXhsoBVrp r6BqDFgNyyNw23hrPAL0fQc56RYrdb/YhaFFU3KL3lApJoXBbvCL2Fk7F1l8H3MA1G1b20YKA07W wTX4CAZus4DrKPRU4OsDOosOWHAvtdLJFAHdeAEZ2FwQvdzuonzNEmFgfwmNQwoaFEzX3jWcAkne UmESoUPp6UMS2AXr7gyDwwYO4g0K5EN3Wy1hj0vDV+g+f2G+AwNmgCSA+tAxIUD39viF/6vsdEMY V4xAU+PYtZVFWYvh5BR2sPCw2D/s74MgLGm6tG3GBQn07IkB+otaau5uO9+MIv+zFf1fz9ETRv4M R1NVa20eLMHSM+1mEAXHQ0/4YI9Sfdg73XU8LfG5tQILdBEzAZdQEa4NNvo7/YnRJEsZDmOh7quD 7xAIiQoUdLbObW6LGFE5Cw8YQGjM/Z3+VesBVZvZtCREEAZuh+EX1SgVRvOFjhC2u7u1at+gMF5d OFBVCjxVBnVvJ8rHZF90JEBTRAg/O7NJVDGOXARVUxvPVip2Vchupljoct9s3YXtLygnNDvuD4Ys B/tLS2oOAkZXg+YPg/4DyuveVnMhAf75DyAahF/MbQ1ziA1/mfR9ZW4zsX0qMVmJjSTIMN+Sd1fo liEcAxgRsRDrBPxntu4l4YO/CjcBNp8N3pwsTQgPkQwDD4KDtyPha70ZVfTwcXR2cXuPdRVW1YHH EJjbiwdrOYLUPRhbPMbZYrz1dolGcQeNbsGL/UCSSZdqJeErXBJWQ+tyGw7rFPYciawmBgc5x6+j GCEwrIs/Ygdtv+2xnkEkJSDlEoMSGDeg2y7ZHv8PFAoUGiX+H8QILw2LhLbHkVOehS5kZZEkeVxE wYvR6GENYEsauGI9/ntdW4HEd3tv7VwmA1hU+XIreHahrs7inBYRAiRqZDdytQ3NmEaRfNY9sSc6 uNGur77QLVbkn4SrH7U7xVHjO8V0USG35CRo7A8iHBZaozQQNEkPKt4NuUrmX+jrcFf3Fg7fOsBs HnReU7uDln/yAOEFRHVKU4o6U77BXRh0RxyldI1GCGj/ODxdnyt3GKXU7Vf9sJXoAgOPN+5Wdalb z6KVO2z42lscU6AL1mzB3FfCkQVzyc2agAfFD1HRAK9lX034yIb40gxZf89CvLIdo74AQDHq2iLY 063O9ARRLbynEdLXT4YrTiF3/9FoBUR162GNdwTRWGo166RCVzrkwpJWjne2na7mgBEK6JMVo9zW eGRMESiLQH1JABvW0AUHo3EVtY1CAxj4gRkt+1n90wRrwFgG9Zv7leVk4Tr5g3r/dGLR/XYxLjEt BekJ744MC6EE+cOLq6ltRhe2+FdIgAOA6tCuhS5AMjyuujNIbYd0U2cQXiQBd5DBDwwzig7W9G0c YBXinVkTH2xbo2N7dcW7LMAcDNvimc0wCB0XRjI3XOKWBXXj2Ylc2Tw8QLGSy950PyhUFN5/Fax3 eJeIBCtDWTwZFrrBSr1vQJg3jFRrie16T/kEKwE3IN2DH9jrUMQrQA/CzhaymBUqhQvdjuQrBl4r QNxLJdy21XmtYSsVi4OzwLY3aBFx9+s+PgY9Z4kjexOKBjwbpitqsneJgOR0Dy3NWdd4DdC2ub22 hrWw7Ze2vNMm606NPC4oB7qbHdkbPA65JyN6d9tILgdzP7ZOea/q2vAuLgFc7HwK1kCWHBhGvAP2 xlHD0KJBI42UBguw0LA0gEYnATeyIN1lh8aF25mhhgYZiNy7ZeEDQ0cON9kfA4AjAAzL3x02MDIT EDyNRDcBgDgclUFOaMcZEAXtgW7MOvDmNesVECeE2DZcc8cUJoTeaqO2UUcPlD5VrQQ3akld+iVw EGAwegu1+Wx6BQtc+12ice1TRcY5HRKjdARwFsqGBTlDNffRC1up6wtMB/+OEzw61rol5xwcSIQq f+TivXvwGFMoi8srDRSs3VvQvDGjeLJJjO8zbre5VYiP5ruAE714In4GbvhTi8WLz1oyQFmJLnSx d2AZeZ0YlMQZzT0yyAaDKn9+Fe6zbbxS10oHCQh/2e297HRnkYoNYfghBdFye+sqQSC7MHwL/Tl/ xRoOD4qIeQMA5SOx/1vKh0ChGWvAZJn3+VUVgr+NfoIMfrk9DDLrHWef/G2cIFUVBnwJPOsHCEZq YQnHfeEHwcN5XRdMmcEvASBg6wWu0UtNohJrBjrDogoh5ngWvDUBJxTiH3TIRszAhINHLmzC1EaB qzR83pxQkNtbGOkXnF/iuA5W/0YXzKAwg9rixl23SjFI+5o5HhrSr1Cp3zidHHQet5gJWoDGs0Et K85SXI0P+0I3R0A4BPONhBVDJ3kbLNgBb1lAhffEUqurAVdE+M8WPxPmuqsgwK81RkeB+2ymk/7a Kaw1dXG7DRb2ZtB0I7jQs2c56LCT2Fay5EhkE+UTuhwVeiSEQm7mdnQzRCyR+CyRE0IsGRBGUXv6 0AKd+cswK8Q4FlD64ONWecpR/GsOU4sguRMN3/j2jwJb6QNIefAffg8Dx9pAo3YrEr7IdcjWxe6x VL2Lxz80RRKyCsFRJDg1CqbCMBO8AiQOVR93ATbRPSd/Eg2NjbWlYOC+MsvVKOLBom5H7Iyzghhi 8JOGVg0e3C2LdgYLh1Bobhw214aDWsjixMcPpw5qw+It2NlEPes/VxbdYhjwgGYFAJUcAYqvmbBL z4gGZIShfLmItWgdJIXRZehQk8gEeVChsyQNeP4NUB81C7U8ZywUY/47N3sT8in8/GwwEv5mz9k8 LfwNHhc9/Fkn2xaGSTT/1+Tg/rpYOPIIFhfONwRZSAaNjDxaYta2reuIsISpzW7x6mV5mPkhBkY+ zKYaqvgshIwyzAbELpUcFPf2Kj717ruPYnQnQTvKfPQLaIPACmCk+GgtDAzn9CZkqH81UkBqf1AQ VoBQZ84JeC1Qnu++w3chIlZjLXQjVmh/Rwvu53u1t5yDxXj0/pRkwRU4uO37EO0rGr4KizbX6HzG A39rXbyhJlXb3b47w1d0KzlQ+2/8WAR1DjvzSotWCDtQCHMCeO7DW60MxmPmgfm9fgkcWsh2/x85 XgR0XL+Q/FdTph7NaE8NSxJ0GTJoboxOZ0kMifD2MII9T/BFCIlO9GOOsYmJMbg1jX4Qx9yzp2p6 /x8m/3ZCdZOzPx0wCFlFV18Uz7lIzkBfp/z0eidqj8Q4cGT/QATomqxRpcYv9Ona0lGzYyPxqANm IBs4mTLNPXtSmQlXaOvfPVTJQKcZvHQOLIRXwkJFx81KVs4s/JjkgICGOW0TWS0Q+zW7KlJZYoG3 V52u1M7OD2H0LsbocDK1q+4fBEhxLpjOUCgeXgkcvP1+c2XEDA9WxkYFAWPBWaP7a9AJAjQyAHYH NezMasFqAcAPU5NuW8QVIH4sdSDEfxdtlCu7uTH38Y1IBYXJb1To+nwOPSAcXgeD5DfrGiPXUtuL TgbGaA81swSu2il1tVusjRjroF12iX7roWoF5Q33QSPHBMQ4Onaz2xEmHH/jaKzAL2xs7XaD/wEP lO8p/9WhUzUzU3RJQ4B48S3cW2N1DUXg0A46CH4mV9j+gkgBO0wccuUFV91C9A2i2IH7oB+yGUI6 Y5det4F9gf1WeUdXU1n0UltTiP9mO+FUO/DdVz+hKRoIcgpoauky/NTqsAAyFD9E1UmTu0Q3StQl nBM/xJ50aA5qVS5gaCAD+GyBYDwVX7uD+wMG4YQ2nucs4FFEYn992Aw9UHLPZLNqZDJ8zffbjKPn o5AElMO53hs8wCGkzDUMEAx/iTYAnn4Wnw+2CIqJIGIjHosVbQKICIvt1aJAfzb2OXUMG8FE/+3t fIi/KBYhW4ld/Dvef2ahQjTa2MYrMBc0+MmOW8B3/NQkOkn/N4v0VgjXqlwtGQQDxq7E7hiZiwce O9hPcduSg28TK1X8A1ZLA0krJdr+rtbKCYoZiBhAQXv3RzJdYGsrWwHyi18El6LROU90da+ZD45U +naIdHZ8TQxQgH4s1Ghj5LRI7PpMMxhsX2Fe/VvMCHCb2YjTfTjWxF1q+wuNjV8BT/iNHv8tvHVd NbMVhVDPfhMERJYcFyqvlBAX2cxJXagRN59/7bkSfSO+Ec++GRQwgLoYFkBZfO3rDrcaNekUMWK3 yHxyK/z/7o1RAzvQfWU7z31hO8FXT1wGv7U22LshSBJP2Pg7wn5DteJN/DvHfj8rwQz/B3w2S22x 0S8WA847132sAY8V0RB8UxFCQYH6/lLpHkj1WvcQNzY7W+bCl8uL+zt9DIwxiYs2dRJtQl9oFBFo EBRYCLhALVbAg8QGTXW1PuNW6gDKSQAD+oDXYLAHKHAo7G0dtSjRj5p7V84Pwq5EE6RTTRVRVjp/ eyvR9JMF8FDryM52BYvOiQNKfXMiXQFN9IhfpjfCuV+iPCUIJog9CIHfWijK8OqBffQAsNlGoltw dxijU1DZ7HujXBjZF0vLdbEO7Wpjkgl5X5T2RkMfsMwix/fGH7lT5YkyjGju8WAygMx8I7EVzra/ ZM7PPwjGcwBviwMdINAfDCyDbFvvaPpEYJ74DgwWKpWFJAS8RZ8tKyg7++QDW+vYtttv/Udki09g MXZV/HA2bKNaFNtVcISXQNzuKgdNaBfxcyhORHPUUv0v3BQ+iFQF4DgcPoJGPwzrLt1y6D8MMdSD RXCCaaDwRP9NbAhWLA83JtvJYF8JZI7rCEscYGu1ge6yg3SB4TsY6zQBfNAOYBIwGPTUWmVZli0B U29mdJZlWZZ3YXJlXE1ZlmVZaWNyb3MAlpNlb2ZcV1mWZdn7QUJcV0FlWZZlQjRcV2GWZVmWYiBG aWxlUJZlWSBOYW04SMFGL/2WdVEBuUWu2p3M/qeh127PzMcCGZDMQAMWDJkV0PZ6rSJfGNA3G+Dl Jx+czP4+5llbxwWI1XsI97AAGqMN78D9JxCDfiAoD4JqWSvJ/zhGt55oqywgPa4RIgYsg3eDUkIV yEAJKvHffmvoE30HMsCI4esejUQxLWoPDfiSNIXwCSjlo3aVgIr9d7kAjhHYtmBHnwoJoM02s/H/ QluKVfE8cHUSgPpsX6sIaPy2v1miil3yPHR1Gg94LlgCVP5/mw5idUc62nVD61I8aHUF939rL+t4 PGEhCHN1F4D7cHRqPHMNt0+WtxshgPtcZHUTDWJ0/ca75048ZGI3+3h0QDU8d191EcaG27weYXUM dQefKOucLOBDqeMafmkE9hb4OWT6GX0sDRvKW+/i/UfB4RShCjgJweAU7XNILPwNFTlOIHcz6wuv CHyZKJ1tS4jGdLU6dap7Yx2fEGiYvA4CdQmPX6ASY3DqXJ5lV07YXLCL7zv+qT4Sc8AM5dxOWTk1 5Sm4g5aLHYSG5KPfs4VXcNMJjb0FUE/VBbMWP4A8OFz5GTw7EGcOFV0ReBjJcoyTaEBrpP1WfbaV KvuS/BVQdSMAkafgNdkw4Fgxu3p1AyNP6xEfzoqPmCRrrNe90Odm23A8OxsI0QB0rswwsnwRCdKc D1q+UTbZxVC+VFC3iH3JKxP2pcwgag27wIRLKIkMSCJB2FF2VkKpSkNIJ1jhF7G11FAtWXkZ+Pig sbwcTlt1ygNOGUabtBivDaZpml5n5UxvY4KmaZphbCBTZZZlWZbwdHRpbmcsW0FZc5JUZSyb5bZt RtNw1NVy1mybbdfXB9h5StnaSTrb13Vd19xG3S/eG98P4AvTNF1d4RPiTOPk5agd

1 0

Kind attention
by Yusuf Ego 01 Aug '06

01 Aug '06

Good day, Compliment of the day. I really regret any embarrassment this mail might cause you as we've never by any chance met before I want you to patiently read this offer. I am Yusuf Ego the Head of Delegation to the World Bank in West Africa. I am the linkman between the Organization for Petroleum Exporting Countries - OPEC and the petroleum sector in a West African country. Through the sale of our allocated oil quota in OPEC, I was able to make $30.5 million. I want you to assist me in investing this fund since as a civil servant I cannot have such funds and the code of conduct bureau forbids me to acquire such amount of money. Though it is my desire to go into property investments or any other area of your choice you may advice. I will compensate you for your honest guidance and assistance. If you're interested to assist in this regard, kindly confirm this message upon receipt Through any of these e-mail address only : yusufego(a)mail.bg or yusufego(a)indiatimes.com to enable me know my next line of action and give you enough details and how we will work things out. Awaiting your earliest response Regards, Yusuf Ego

1 0

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