toasters April 2004

toasters@lists.teaparty.net

55 participants
57 discussions

NetApp DR Tape Solutions
by Ben Rockwood 15 Apr '04

15 Apr '04

Hello Toasters. I've got 2 940 Filers with 5TB of capacity each currently, with the expectation that it will grow significantly over time. We're using snapmirror from one filer to the other in order to provide redunancy and this also servers as our "backup". I think it's time to move to a more substantial solution, namely for DR purposes. The options, due to budget, are NearStore or tape. Obviously the best solution would be to snapmirror to a NearStore and then to do tape backups from the spinning copy, but we can't afford that sort of solution right now. Tape, to me, seems the more prudent solution, because it allows for offsite of the data (in case of fire, WW3, etc) and we can maintain multiple independant copies of the data to guard against logical corruption of the data, if it occured. If logical corruption occurs we need to catch the problem before the snap to the NearStore happens or we're screwed, right? So tape has the advantage given our constraints. So the question becomes which media to use. 9940B is out immediately due to cost ($40K/drive is insane). Which leaves LTO Gen2 at 200G native and S-AIT at 500G Native. Naturally I'm liking the S-AIT option because I can do offsites with a signficantly lower media count, despite the fact that the media cost is higher. And, because my data is primarily web content (HTML flattext and GIF/JPG images) I should be a pretty decent compression ratio. This brings me to the big question. Has anyone managing Filers used S-AIT yet? It's really an argument between Helical Scan tape technology (wear rate, failures, etc) vs the stable and proven Linear technology of LTO Gen2. Despite the drawbacks associated with all the problems inhearent to Helical Scan, the 500G native, and possible 2.66:1 (I expect that with my data 2:1 is adiquate) compression ration the advantages to S-AIT for Filer backup is really hard to ignore. My estimates right now in the pro-con area between the 2 formats looks like this: Total Capacity of each Filer as currently configured: 5.2TB Media Consumption per Filer: LTO Gen2: Backup of Full Capacity without Compression: 26 Tapes (approx) S-AIT: Backup of Full Capacity without Compression: 10 Tapes (approx) So assuming I get around 2:1 compression which is reasonable, I can do full capacity backups in 5 tapes per filer with S-AIT vs 13 with LTO! That means if I want to keep 4 complete backups at any given time, I need a library with an insane media count, because we're looking at 26x4x2=208 slots, and bring that down to 130 or so with compression. With S-AIT I need less than 50 not considering compression. And to that, with compression I might be able to cram all 5TB onto 4 tapes, which means I can buy a 4 drive library and stream to all 4 tapes similatiously without a media change in the middle. Anyway, obviously I'm feeling scared about S-AIT but cannot ignore the awsome potential it has for bulk data. Can anyone please share their insights or opinions? Is anyone currently using S-AIT for filers? Thanx. benr.

1 0

Linux NFS cache problem?
by Jun Ohata 15 Apr '04

15 Apr '04

Hi all, Has anyone encounter the problem like this? 1. If a user replace a file (which on the Filer) using cp command using Solaris 8 machine such as; # cp newfile oldfile 2. Then, on Linux server(NFS Client) A , reading the file, the file is new one. 3. But on another Linux server B, reading same file above, the file is stil OLD. We experienced many times on many files and Linux servers. I suspect some linux cache behavior (attribute caching?), but This situation still remain after a few days... [Our mount options] rw,nosuid,bg,soft,rsize=8192,wsize=8192,timeo=11,retrans=5 [Our Linux (all)] kernel 2.4.20, based on RHL 7.3 [Filer] F825, NetApp Release 6.3.3D2 I've read Technical report written by Chuck Lever(TR3183), noct and/or noac options may help, but I don't know why such long time Linux does not see a new file. Anyone? Thanks, -- Jun Ohata ohhata(a)tnes.nec.co.jp

4 4

diatribes f1nd a ch1ck racketeers
by Shuhei 15 Apr '04

15 Apr '04

1 0

unregister
by Wil Ng 13 Apr '04

13 Apr '04

---------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind ASL to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------------------------------------------------------------

1 0

WINING NOTIFICATION
by ELGORDO LOTERIA PRIMITIVA 12 Apr '04

12 Apr '04

ELGORDO LOTERIA PRIMITIVA PIS0 36, CALLE CARLOS OTERGA, 28002 MADRID, SPAIN. TEL/FAX: +34-645-630-404. FROM:THE DESK OF THE VIC-PRESIDENT. INTERNATIONAL PROMOTION/PRIZE AWARD DEPT. REF NO: EGS/2551256007/03 BATCH NO: 15/0018/IPthD ATTENTION: RE:AWARD FINAL NOTIFICATION. We are pleased to inform you of the release of the result of the EL GROUP SWEEPSTAKE LOOTERY/INTERNATIONAL PROGRAMME played on the 15th March 2004.Your name attached to ticket number 025-11464992-750 with serial number 2113-05 drew the lucky numbers 13-15-22-37-39-45, Which consequently won the lottery in the 3rd category. You have therefore been approved for the lump sum pay out of 315,810.00 (Three Hundred and Fifteen Thousand Eight Hundred and Ten Euro Only) in cash credited to file Ref No: EGS/ 25512600/03. This is from a total cash prize shared among the thirty=0ne International Winners in this category. CONGATULATIONS!!! Your fund is now deposited with a security companyinsured on your name. Due to mixed up of some numbers and the names we ask that you keep this award from public notice until your claim has been processed and the money remitted to your account as this is part of our security protocol to avoid double claiming or unwarranted taking advantage of this programme by participants. All participants were selected through a computer ballot system drew from 25,000 names fromAsia,Australia,New Zealand, Middle East,Europe,North America as part of our International promotions programme, Which we conduct once every year. We hope your lucky name will a bigger win in the next programme.To begin your lottery claim, Please complete the PAYMENT PROCESSING FORM which will be send o you with this notification letter and you will fax a copy to a claim agent assigned to you. Mrs. Eva Perez. Foreign Operation manager EURO GLOBAL SECURITY COMPANY Tel: +34-675-118-081 Fax: +34-656-471-863. For the processing and remittance of your winning prize to a designated account of your choice. Remember, All prize money must be claimed notlatter than 28TH April 2004.After this date all fund will be returned to the MINISTERIO DE ECONOMIA HACIENDA AS UNCLAIMED. Note. In order to avoid unnecessary delays and complications. Please remember to quote your Reference Number, Batch Number and prize claim track number in every correspondence with your agent or us. Furthermore, Should there be any change of your address, do inform your claims agent as soon as possible. Congratulation again from all members of our staff and thank you for being a part of our promotions programme. Yours Sincerely. PEDRO GARZON CEO President PRIZE CLAIM TICKET NO: 31736745.

1 0

Be the dealer, win other players money japanese
by Leonard Rocha 12 Apr '04

12 Apr '04

1 0

My Impotency FINALLY solved! ild WA
by Dionne Emery 12 Apr '04

12 Apr '04

Be a winner with Apoll0! Quality enlargement from as little as just $40 a month Make a BIG difference in your life today with the power and promise of Apollo male enhancement patch. Increase size and stamina by up to 3 inches in as little as just 12 weeks! We guarantee your satisfaction or you get your payment back! Over 95% of our buyers have been astonished with the results! Click below to Learn more ORDER TODAY! http://iamtoor.com/4/1/index.php?ai=7038

1 0

Re[8]: Отдых в Сочи на майские праздники
by Tillable I. Report 09 Apr '04

09 Apr '04

РПаЎ±б l H

1 0

DFS Replication
by Alan Biren 07 Apr '04

07 Apr '04

I have a DFS environment with one Filer. I am able to set the shares for DFS, but the Filer does not support DFS Replication. Does anyone have a solution that they have working to resolve this. I'd like not to have to replace the existing DFS with VFM/StorageX. ***************************************************************************************************** If you have received this email in error please notify the the system manager or the sender immediately and do not disclosed the to anyone or make copies. ** eSafe scanned this email for viruses, vandals or malicious content ** ** To find out eSafe(TM) and other Aladdin Security Products, contact AMC Corporation at (212) 620-0700 *****************************************************************************************************

1 0

RE: SnapMirror and Qtrees
by Gole, Abhijeet 07 Apr '04

07 Apr '04

-----Original Message----- From: Odhner, Christian Sent: Wednesday, April 07, 2004 11:00 AM To: Gole, Abhijeet; c-dl-snapmirror Subject: RE: SnapMirror and Qtrees > renamed /vol/vol1/MySpace (or My_Space) for snapmirror to work. Before I > change the names of 86 qtrees and their corresponding DFS share > pointers, I'm hoping that someone can tell me that NetApp was incorrect While Colin or someone else can comment on the current state of the bug and any workarounds, I should point out that even if there is no current workaround, the customer does NOT need to change his DFS pointers. Just change the qtree names, and change the CIFS share mappings on the filer side so that the same (old) share names point to the new (no-space) qtree names. Share names and Qtree names don't have to match, so client reconfiguration of any sort can be avoided pretty easily. -Chris -----Original Message----- From: Haber, David J. [mailto:david.haber@fahc.org] Sent: Wednesday, April 07, 2004 10:34 AM To: toasters(a)mathworks.com Subject: SnapMirror and Qtrees I have been told by NetApp support that you cannot, at this time, snapmirror qtrees that have spaces in their name. That is, a qtree with the path /vol/vol1/My Space cannot be snapmirrored. It would have to be renamed /vol/vol1/MySpace (or My_Space) for snapmirror to work. Before I change the names of 86 qtrees and their corresponding DFS share pointers, I'm hoping that someone can tell me that NetApp was incorrect and there is a way to snapmirror qtrees with spaces in their names. Or, can someone at NetApp who might be readin this give me an idea when the bug (86447) will be fixed.

1 0

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 April 2004