toasters

toasters@lists.teaparty.net

13523 discussions

RE: ESTALE
by Strange, Steve 06 Sep '00

06 Sep '00

Deletion-handling of open files in NFS V2 and V3 (such as it is) is handled at the NFS client. The NFS server isn't aware of which clients have a file open, or how many processes on those clients have a particular file open (I'm assuming no NFS locking here). If a process on NFS client "A" has a file open, then another process on that same client deletes the file, the NFS client sends a "RENAME" to the NFS server, instead of a "REMOVE", so that the file sticks around until that first process closes the file (at least this is the case for NFS clients with which I'm familiar). The file is renamed to ".nfsXXXX", or something of that ilk, but the NFS file handle remains the same, so the first process can continue to read/write/etc. However, if a process on a different NFS client, "B", deletes the file, client "B" has no way of knowing that the file is open by a process on client "A". So client "B" will go ahead and remove the file completely, resulting in ESTALE the next time the process on client "A" attemts an operation on the file. Do you have just one NFS client accessing the file in question? What NFS client are you using? Hope this chatter is of some use. Cheers, Steve > -----Original Message----- > From: Edward Hibbert [mailto:EH@dataconnection.com] > Sent: Wednesday, September 06, 2000 4:39 AM > To: toasters(a)mathworks.com > Subject: ESTALE > > > Does anyone know under precisely what circumstances NetApp > returns ESTALE? > > I have a file open in my application to which I have just > done a write; I > issue another write very shortly thereafter and I get ESTALE back. > > Now, I believed that ESTALE was returned when a file handle > was presented > where the file had really been deleted and the inode for the > file was reused > for a new file. But since my process has the file open, even > if it's been > deleted by some other process (which is possible), I don't > think I should > get ESTALE returned. > > So this means I don't understand what is going on. But > perhaps you do :-). > > > Edward Hibbert. >

1 0

NetApp 9gb FC/AL drives available for sale
by ScottUCE＠aol.com 06 Sep '00

06 Sep '00

A leasing company has SEVEN 9gb FC/AL fiber disk drives (NetApp Model X219F) available; NetApp no longer offers these drives. They are asking $4,500.00 for the seven drives, shelf/power supply and cabling. Please contact me if you have any interest. Scott Fischmann Union Computer Exchange, Inc. 6233 Idylwood Lane Minneapolis, MN 55436 (612) 935-7282 (612) 935-5056 - FAX www.unioncomputer.com

1 0

ESTALE
by Edward Hibbert 06 Sep '00

06 Sep '00

Does anyone know under precisely what circumstances NetApp returns ESTALE? I have a file open in my application to which I have just done a write; I issue another write very shortly thereafter and I get ESTALE back. Now, I believed that ESTALE was returned when a file handle was presented where the file had really been deleted and the inode for the file was reused for a new file. But since my process has the file open, even if it's been deleted by some other process (which is possible), I don't think I should get ESTALE returned. So this means I don't understand what is going on. But perhaps you do :-). Edward Hibbert.

1 0

RE: Budtool woes
by Clawson, Simon 05 Sep '00

05 Sep '00

Hi! Thanks for the info! Scary stuff this backup! I have just checked the logs to find that the backup ran for 32 hours this weekend! Anyway, How have you achived the spliting of your file system? I think this is going to cause us problems due to the rather unitelligent autoloader we use to drive the backup...any advise on this? Simon -----Original Message----- From: Marion Hakanson [mailto:hakanson@cse.ogi.edu] Sent: 01 September 2000 18:24 To: Clawson, Simon Cc: toasters(a)mathworks.com Subject: Re: Budtool woes > . . . > I am bacing up a single volume filer with nearly 200GB of data - my backup > is constanlty failing due to the process running out of time..anyone seen > this? Is there a way round it? Can I increse the allowable time? Can I split > the backup into several levels? > . . . Simon, I see that you've probably solved your timeout problem, but you've probably got another problem as well. I've just upgraded to bt-4.6.1a, and the Release Notes state that it does not support backups that get split across more than 3 tapes. I'll spare you the details right now, since you can go look at my original posting to "toasters" on this topic: http://teaparty.mathworks.com:1999/toasters/6612.html Apparently a large backup of this type will work fine, but you may not be able to do recoveries from it, under certain mysterious circumstances (which I've not yet experienced, thankfully). The workaround is to break up that single backup into backups of subdirectories of that large volume (you don't have to breakup the volume itself). Solaris ufsdump can do this, but doesn't support incremental (non-full) dumps of subdirectories; Fortunately (by the tests I've done here), NetApp's dump (both console/cmd-line and NDMP) can do both fulls and incrementals of subdirectories. I've since noticed that NetApp themselves recommend against backing up large volumes (>100GB) in a single "dump" run. Here's where: http://now.netapp.com/NOW/knowledge/docs/ontap/rel536r2/html/sag/dump7.htm Luckily for us, our large volume (185GB, currently) is broken up into about ten qtrees & a couple other directories. I think the 10-12 dumps actually complete slightly faster than the previous single large dump. BTW, how's it going in your search for a BudTool replacement? A PDC engineer told me that the new Legato Networker 6.0 NDMP support will only do backups to either a NetApp-attached library, or to another NDMP enabled system (and _not_ to a Networker media server). It doesn't support a split-library configuration at all (which is what we have our BudTool/NetApp setup doing). Because of that, they want to sell me Veritas NetBackup instead. I've got a few other leads in the works, and I'd be happy to compare notes on what you've found so far. Good luck and regards, -- Marion Hakanson <hakanson(a)cse.ogi.edu> CSE Computing Facilities

2 1

RE: Splitting large volumes
by Krause, Oliver 04 Sep '00

04 Sep '00

If you used the "-level 0" option when doing the initial transfer then subsequent incrementals do the expected: If you delete a file on the source and do a incremental it is also gone on the destination. Don't omit "-level 0" for doing the level 0 dump if you want this working that way. Oliver > -----Original Message----- > From: Cliff.Dobbs(a)arm.com [mailto:Cliff.Dobbs@arm.com] > Sent: Montag, 4. September 2000 17:12 > To: toasters(a)mathworks.com > Subject: Re: Splitting large volumes > > > > Folks, > > I can't seem to find any info on what ndmpcopy does when a > file is removed > from the source filer after a level 0 dump. > > Does it remove the said file from the destination filer ( as > per rdist -R) > or do you end up with loads of files which the users thought they had > deleted :-( > > Cheers > > > Cliff Dobbs Systems Administrator ARM Ltd > Tel: +44 1223 400430 Fax: +44 1223 400410 e-mail: Cliff.Dobbs(a)arm.com > > > > > > > The easiest solution, that also demands minimal downtime is > > using ndmpcopy/rsync altogether... > > > > This will work only if you have free volumes on the new machine... > > > > > > 1. Copy a baseline copy of the seperate parts of your current > > volume to the target volumes, using ndmpcopy/rsync/tar/whatever > > (ndmpcopy will be the fastest probably). > > This can be done while users are working, a few hours/days > > before the migration downtime is planned. > > 2. In something like a few hours before the downtime, use > > the utility "rsync" and/or ndmpcopy to copy incrementally > > the changes since the baseline. > > 3. DOWNTIME - while in downtime, just do a final syncing, again > > using ndmpcopy incremental/rsync, and change the > relevant settings: > > NIS maps, filer's /etc/exports, /etc/quotas... > > > > In theory, this is the way to go and is what we ended up > doing when we > copied a volume to a new volume about a couple weeks ago. We > did a level > 0 dump/restore with ndmpcopy while the filer was up and during the > downtime we picked up the changes with rsh filer dump | rsh > filer restore. > We didn't use rsync because we didn't want to lose any CIFS file > attributes. > > Let me warn you about some problems we ran into. We've submitted bug > reports where appropriate. > > 1) We are running 5.3.5R2P2 and there is a known bug in > incremental NDMP > where it fails to dump files that should be dumped because > NDMP dump only > looks at the mtime and not the mtime and the ctime. To work > around the > bug, which is only in NDMP dump, we used "rsh filer dump | rsh filer > restore". We ran into some serious problems where the > restore would stop > working and drop into an infinite loop. This would happen > often, but not > always. I'm talking to netapp about this one. > > 2) We discovered a bug where a level 0 subtree dump skips files dated > before 00:00:00 Jan 1, 1970 GMT, i.e., files with negative timestamps. > Don't ask me how they got there, they are user files and we > had over 500 > of them. This problem does not happen with a full volume dump, just a > subtree. So I suggest either doing a full volume dump or > running a find > to locate all such files and "touch" them to a time after 1970. > > 3) Very minor bug -- one of our users has the unix uid 65535, > which has > the bit pattern 0xffff which is -1 in a 16 bit signed int. After the > restore, this user's files were all owned by root instead of 65535. > Nearby uids both above and below worked correctly. > > 4) Our original filesystem was created under DOT 5.0.2 and > the filer was > upgraded at least twice since. We run a mixed NFS and CIFS > environment. > In some of the older versions of DOT were some bugs in the > WAFL directory > format. One bug allowed two different files to be created in the same > directory with the exact same name. Even though our version of DOT no > longer has this bug, our volume still had three such pairs of > files on it. > The full dump/restore had no problems with these files, but the > incremental restore -r could not cope and failed without restoring > anything. If you can find these file pairs the fix is simple. Just > rename one of the files. You have no control over which one > of the two > the filer picks, but afterward, you can see both files. This is a > particularly insidious problem because any incremental dump > of a volume > with duplicate filenames CANNOT BE RESTORED with "restore > -r". You will > be forced to use "restore -x" which is less than desirable. > Dump does not > issue any errors, either. It's only when you restore that > you discover > the problem. > > You can locate duplicate files like this: > > find dir -print | sort > out1 > sort -u out1 > out2 > diff out1 out2 > > MORAL: Before a big volume copy, do some dry runs to be sure > you won't > run into problems during your downtime. Be sure to test both the full > dump/restore and incremental dump/restore. We discovered > many of these > problems during the two weeks leading up to our downtime. > Even still, we > hit a couple snags during the downtime that cost us at least 2 hours. > > One final tip: Before running restore -r on an incremental dump, > be sure to save a copy of the restore_symboltable file since > restore -r modifies it. If the restore modifies the file and then > fails, you can't rerun the "restore -r" unless you put back the > original file. Even then you may have problems, and will need to > use "restore -x". > > > Steve Losen scl(a)virginia.edu phone: 804-924-0640 > > University of Virginia ITC Unix Support > > >

1 0

Re: Splitting large volumes
by Cliff.Dobbs＠arm.com 04 Sep '00

04 Sep '00

Folks, I can't seem to find any info on what ndmpcopy does when a file is removed from the source filer after a level 0 dump. Does it remove the said file from the destination filer ( as per rdist -R) or do you end up with loads of files which the users thought they had deleted :-( Cheers Cliff Dobbs Systems Administrator ARM Ltd Tel: +44 1223 400430 Fax: +44 1223 400410 e-mail: Cliff.Dobbs(a)arm.com > The easiest solution, that also demands minimal downtime is > using ndmpcopy/rsync altogether... > > This will work only if you have free volumes on the new machine... > > > 1. Copy a baseline copy of the seperate parts of your current > volume to the target volumes, using ndmpcopy/rsync/tar/whatever > (ndmpcopy will be the fastest probably). > This can be done while users are working, a few hours/days > before the migration downtime is planned. > 2. In something like a few hours before the downtime, use > the utility "rsync" and/or ndmpcopy to copy incrementally > the changes since the baseline. > 3. DOWNTIME - while in downtime, just do a final syncing, again > using ndmpcopy incremental/rsync, and change the relevant settings: > NIS maps, filer's /etc/exports, /etc/quotas... > In theory, this is the way to go and is what we ended up doing when we copied a volume to a new volume about a couple weeks ago. We did a level 0 dump/restore with ndmpcopy while the filer was up and during the downtime we picked up the changes with rsh filer dump | rsh filer restore. We didn't use rsync because we didn't want to lose any CIFS file attributes. Let me warn you about some problems we ran into. We've submitted bug reports where appropriate. 1) We are running 5.3.5R2P2 and there is a known bug in incremental NDMP where it fails to dump files that should be dumped because NDMP dump only looks at the mtime and not the mtime and the ctime. To work around the bug, which is only in NDMP dump, we used "rsh filer dump | rsh filer restore". We ran into some serious problems where the restore would stop working and drop into an infinite loop. This would happen often, but not always. I'm talking to netapp about this one. 2) We discovered a bug where a level 0 subtree dump skips files dated before 00:00:00 Jan 1, 1970 GMT, i.e., files with negative timestamps. Don't ask me how they got there, they are user files and we had over 500 of them. This problem does not happen with a full volume dump, just a subtree. So I suggest either doing a full volume dump or running a find to locate all such files and "touch" them to a time after 1970. 3) Very minor bug -- one of our users has the unix uid 65535, which has the bit pattern 0xffff which is -1 in a 16 bit signed int. After the restore, this user's files were all owned by root instead of 65535. Nearby uids both above and below worked correctly. 4) Our original filesystem was created under DOT 5.0.2 and the filer was upgraded at least twice since. We run a mixed NFS and CIFS environment. In some of the older versions of DOT were some bugs in the WAFL directory format. One bug allowed two different files to be created in the same directory with the exact same name. Even though our version of DOT no longer has this bug, our volume still had three such pairs of files on it. The full dump/restore had no problems with these files, but the incremental restore -r could not cope and failed without restoring anything. If you can find these file pairs the fix is simple. Just rename one of the files. You have no control over which one of the two the filer picks, but afterward, you can see both files. This is a particularly insidious problem because any incremental dump of a volume with duplicate filenames CANNOT BE RESTORED with "restore -r". You will be forced to use "restore -x" which is less than desirable. Dump does not issue any errors, either. It's only when you restore that you discover the problem. You can locate duplicate files like this: find dir -print | sort > out1 sort -u out1 > out2 diff out1 out2 MORAL: Before a big volume copy, do some dry runs to be sure you won't run into problems during your downtime. Be sure to test both the full dump/restore and incremental dump/restore. We discovered many of these problems during the two weeks leading up to our downtime. Even still, we hit a couple snags during the downtime that cost us at least 2 hours. One final tip: Before running restore -r on an incremental dump, be sure to save a copy of the restore_symboltable file since restore -r modifies it. If the restore modifies the file and then fails, you can't rerun the "restore -r" unless you put back the original file. Even then you may have problems, and will need to use "restore -x". Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

1 0

migrating from nfs to cifs
by neil lehrer 01 Sep '00

01 Sep '00

hi, we are migrating from our sun servers to filers by doing an nfs cp -p. our user environment is primarily nt wkstations and we want to eventually convert to cifs access and to an ntfs security model. does anyone have any suggestions on how to automatically create the appropriate acls for both home and shared directories[including group aces]? thanks. -- regards +++++++++++++++++++++++++++++++++++++++++++++++++ + Neil Lehrer + + United States International Broadcasting Bureau + System Development Division + + voice 202 619-2524 + fax 202 619-3576 + nlehrer(a)ibb.gov + + " is this crisis an opportunity or just + another grab the fire extinguisher moment?" + +++++++++++++++++++++++++++++++++++++++++++++++++

1 0

SAN backups of filers
by Garrett Burke 01 Sep '00

01 Sep '00

Hi All, Anyone out there using a SAN to backup their filers to a centralised library? (See NAS Neets SANs http://www.vixel.com/whitepapers/ and http://www.netapp.com/tech_library/3080.html) We are investigating this option and would be interested in hearing about any experiences people have had? Thanks, GB -- Garrett Burke, Operations Manager Eircom Multimedia Infrastructure Internet House 26-34 Temple Bar.

1 0

RE: Budtool woes
by Clawson, Simon 01 Sep '00

01 Sep '00

Found that one. I've changed it, fingers crossed now for the weekend. Thanks Simon -----Original Message----- From: Paul Lupa (ra5507) [mailto:paul.lupa@motorola.com] Sent: 01 September 2000 12:09 To: Clawson, Simon Cc: toasters(a)mathworks.com Subject: Re: Budtool woes Simon, Please look at the file $BTHOME/bud/goserver.end.filter and look for the string BT_REQ_CMDTIMEOUT Changing it to the number of seconds that you need will solve your problem. Paul Lupa "Clawson, Simon" wrote: > > > Hi! > > We have Budtool 4.6.1, and are currently looking for a replacement. > However... > > I am bacing up a single volume filer with nearly 200GB of data - my > backup is constanlty failing due to the process running out of > time..anyone seen this? Is there a way round it? Can I increse the > allowable time? Can I split the backup into several levels? > > HELP! > > Simon > > Simon Clawson > Renoir Group Systems Administrator > Mentor Graphics Uk > Rivergate > London Road > Newbury > Berkshire > RG14 2QB > <<Clawson, Simon.vcf>>

1 0

accessing mixed-case files on Netapp
by Eric Seidman 31 Aug '00

31 Aug '00

I was directed to this mailing list as a good source of knowledge about accessing files on Netapp. I hope this question is appropriate; if not, I apologize. I am working in an environment in which a Netapp filer containing files with mixed-case names is being accessed using both CIFS and NFS. It is important that I be able to access the files using NFS in a case-insensitive manner. Unfortunately, converting all of the filenames to a consistent case is not an option. The NFS access is being done from a RedHat Linux server running Apache. I have considered writing an Apache module to parse the directory structure to determine the actual case of the filename, although this option seems too inefficient. Any suggestions would be greatly appreciated. Thank you very much for your time, eric seidman eseidman(a)cs.stanford.edu

6 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