toasters

toasters@lists.teaparty.net

13515 discussions

Looking for drive space utilization reports
by Jay Newton 05 Jul '01

05 Jul '01

I am trying to find a good tool, preferrably Windows-based, that can help me gather statistics on space utilization. I need this for our F840 Filer we currently use, but I would like to be able to use it to look at space usage elsewhere. I'm needing statistics on how much drive space is used, the type of data using it, and which users are putting it there. Anyone out there have any ideas? Jay Newton Systems Engineer Chesapeake Operating 6112-114 (405)810-2683 (405)879-9578 fax

1 0

AW: DS14 disk shelves
by Poellmann, Christoph ISY 1 05 Jul '01

05 Jul '01

I'd like to refresh a question which has been raised end of may. See below. Is there anyone out there who uses the new DS14 shelves? Any bad experiences (or good ones of course)? I have to decide now wether to increase capacity with 7x72GB in FC9 or with 14x36Gb in DS14. The 36 GB disk approach with DS14 would fit much better in our administration model, but there are the fears: to be one of the first to use them, no field experience etc. Christoph -- INA * Herzogenaurach * Germany fon: 09132 824691 * mobile fon: 0173 5768452 > -----Ursprüngliche Nachricht----- > Von: Scott Mikusko [mailto:guerilla@concentric.net] > Gesendet am: Dienstag, 29. Mai 2001 21:42 > An: toasters(a)mathworks.com > Betreff: DS14 disk shelves > > > > Anyone out there in toasterland have any of the new DS14 disk shelves? > Trying to get some idea of performance and impressions on the > new units > with people. > > These are the new fibre channel disk shelves that house 14 drives from > Netapp. Seen some basic spcs on them, but wondered if anyone has > installed and run these on any F700/800 series units. > > -Scott > >

1 0

RE: 36F disk
by Andrew Siegel 05 Jul '01

05 Jul '01

> How about anytime you want to repeat your same email again, just writing > "yada yada software license yada yada transferable yada yada leasing company > yada yada union computer exchange yada yada" and we'll know what you mean to > say. That's really rude. The guy is doing us *all* a favor by reminding us that NetApp double dips on the software licensing fee when a machine is is sold on the secondary market. This bears periodic repetition.

2 1

Re: 36F disk
by ScottUCE＠aol.com 05 Jul '01

05 Jul '01

Debbie: Your concern regarding the usability of your NetApp disk drives on other systems notwithstanding, your best investment protection on your NetApp system would be to ask your NetApp salesperson for software license transferability before you buy your next machine (NFS, CIFS, Snap products, etc.) Further, in the event you decide to lease a filer, you might want to select a leasing company that has NetApp's permission to freely transfer software licenses on the resale of used NetApp systems -- they should be able to provide you significantly better rates. Regards, Scott Fischmann Union Computer Exchange, Inc. 6233 Idylwood Lane Minneapolis, MN 55436 Phone: 952 935 7282 FAX: 952 935 5056 scott(a)unioncomputer.com In a message dated 7/3/01 12:49:37 PM Central Daylight Time, Debbie.Lane(a)intermec.com writes: > Can a 36F Fibre Channel disk be used in a system that is not NetApp? I am > asking because the decision to buy or lease was based on the belief that if > at some point we wanted to discontinue using NetApp the disks could be used > elsewhere. > > Thanks for your help. > > --Debbie

2 1

FTP
by Peter Gauthier 04 Jul '01

04 Jul '01

Running 536r2 and 61r1 on my filers and I'm unable to get FTP working, the error is exactly like bug 33218. I have set up my qtree secuiry on vol0 to unix and it made no difference. The other message I get back is: 530 /netservice/ftp: no such file or directory. Then these two directories do exsis and permissions are 777 rwx,rwx,rwx. My passwd file is setup as showen in the man pages and the ftpd.enable is on. Anybody have any tricks

2 1

RE: An idea on migrating NTFS data
by Tom "Mad Dog" Yergeau 03 Jul '01

03 Jul '01

<< Here's an even simpler idea: use global groups to assign permissions. >> You can't do that in a large multi-domain enterprise. Take for example a growing company that uses a new domain for each country. (Back in NT4 days this would be typical and even today with Win2K sites, for security boundary reasons a company might still use a different domain for different countries/depts./areas/whatever.) Files are shared among the different sites. FolderRoot | |-----Folder1 | | | |-------Folder1.1 | |-----Folder2 | | | |-------Folder2.1 | | | | |---Folder2.1.1 | |-----Folder3 ( | | | |-------Folder3.1 Let's say you grant a local group, FilerUsers, access to Folder1. The groups "US-Users, UK-Users, DE-Users" belong to FilerUsers so groups from all three countries can access it Folder 1.1 has some sensitive information in it and only US-Users should be able to access it, FilerUsers access is removed and US-Users access is granted. Now, let's say the same scenario applies to Folder2 and Folder2.1, but instead, Folder2 has access granted to the global groups US-Users, UK-Users and DE-Users. Folder2.1 only has US-Users access. Now, along comes, oh, Canada office. To add access appropriate to folder 1 and all subfolders, you just add CA-Users to the FilerUsers local group. Done. Poof. That's it. Nothing else to do. Folder2, you have to reset ALL the ACLs on Folder2 and all subfolders. Uh-oh. Problem. How do you know which files and folders have more restrictive ACLs? In this example there is only one sub folder with customized ACLs, but in real life, there could be a very large number of files and folders. You just totally ruined the ACLs on all of them in order to give CA-Users access. With Win2K-style ACLs and the inheritance model they use, the problem might be a little less of a problem, but only slightly less. I can go into scenarios where the new inheritance wouldn't help but using local groups would (That's why I've got the extra folders up there, but I'm too lazy to keep going at this point!) So, Local Groups are an evil necessity. I've found a product called "SuperCACLS" from Trusted Systems to be very helpful in dealing with problems like this and it's a lot cheaper than the comparable Alita product. But, it does take forever to walk large directory structures and is not ideal. Tom -----Original Message----- From: Conner, Neil [mailto:neil@mbari.org] Sent: Tuesday, July 03, 2001 6:05 PM To: 'Jeffrey Krueger'; toasters(a)mathworks.com Subject: RE: An idea on migrating NTFS data Here's an even simpler idea: use global groups to assign permissions. Cheers, Neil -----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, July 03, 2001 2:37 PM To: toasters(a)mathworks.com Subject: An idea on migrating NTFS data We are about to migrate a bunch of data between different filers, among which is some NTFS security style data. The only non-slam-dunk about it is NTFS local groups. Background: We use the Microsoft recommended method of assigning rights to filesystems, that is UGLR (phonetic == Uglier). Users belong to ... Global groups, which belong to ... Local groups, which are assigned access to ... Resources. The problem is that Local groups have a non-global SIDs between machines. That is, each filer assigns its own local SID's to local groups in its /etc/lclgroups.cfg on the root volume. That SID gets moved with the ACL data to the destination, but the destination machine can't resolve its membership with its local groups. The traditional approach to fixing this is using a tool from Aelita or subinacl to traverse the entire destination filesystem (post-migration) and replacing any occurrence of the old SID with that of a new SID for a local group on the destination filer. This is all fine and good, but could take forever. -------- THE IDEA -------- Here's my idea on a better way to do this. Simply shutdown CIFS on the destination machine pre-move and create analogous local group entries with SIDs that match the source. NetApp tech support might not like the idea too much, but it would mean that the same global groups would belong to that SID and thus no filesystem traversing or ACL modification! Ta Da! Unfortunately, we are copying data from more source machines than there are destination machines and we are not copying data per filer - that is some data from filer1 will go to filerA, some to filerB, etc. This means that for my scheme to work, we'd need globally unique local group SID's. Since it appears that ONTAP starts assigning local group SID's at 65536 sequentially, we have lots of conflicting local groups with those lower numbered SID's. To still use the original concept, I had the idea of copying the membership of all the groups on the source filers into new local groups with globally unique SID's. Then run one of the ACL tools to create analogous ACE's for the new group wherever it finds the old one. (This is all done pre-migration) After the migration we simply create local groups on the destination machine with SID's of the new, analogous rights granted group. Has anyone tried something like this before?? Can anyone see any problems with this approach?? How about an alternative approach?? Again, the idea is to prevent the requirement of a filesystem traversal during migration. Thanks in advance!! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 Storage Lead (NAS/SAN) Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

1 0

RE: An idea on migrating NTFS data
by Mike Sphar 03 Jul '01

03 Jul '01

There's a reason MS recommends using local groups. For one thing, under NT, you can't add a group to a global group. I believe they changed this with Win2k, but if the original poster has not yet updated their infrastructure to win2k they may still need to use local groups. This was one of the things MS hammered into you during MCSE training years ago. I don't know if they've changed their tune now. -----Original Message----- From: Conner, Neil [mailto:neil@mbari.org] Sent: Tuesday, July 03, 2001 3:05 PM To: 'Jeffrey Krueger'; toasters(a)mathworks.com Subject: RE: An idea on migrating NTFS data Here's an even simpler idea: use global groups to assign permissions. Cheers, Neil -----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, July 03, 2001 2:37 PM To: toasters(a)mathworks.com Subject: An idea on migrating NTFS data We are about to migrate a bunch of data between different filers, among which is some NTFS security style data. The only non-slam-dunk about it is NTFS local groups. Background: We use the Microsoft recommended method of assigning rights to filesystems, that is UGLR (phonetic == Uglier). Users belong to ... Global groups, which belong to ... Local groups, which are assigned access to ... Resources. The problem is that Local groups have a non-global SIDs between machines. That is, each filer assigns its own local SID's to local groups in its /etc/lclgroups.cfg on the root volume. That SID gets moved with the ACL data to the destination, but the destination machine can't resolve its membership with its local groups. The traditional approach to fixing this is using a tool from Aelita or subinacl to traverse the entire destination filesystem (post-migration) and replacing any occurrence of the old SID with that of a new SID for a local group on the destination filer. This is all fine and good, but could take forever. -------- THE IDEA -------- Here's my idea on a better way to do this. Simply shutdown CIFS on the destination machine pre-move and create analogous local group entries with SIDs that match the source. NetApp tech support might not like the idea too much, but it would mean that the same global groups would belong to that SID and thus no filesystem traversing or ACL modification! Ta Da! Unfortunately, we are copying data from more source machines than there are destination machines and we are not copying data per filer - that is some data from filer1 will go to filerA, some to filerB, etc. This means that for my scheme to work, we'd need globally unique local group SID's. Since it appears that ONTAP starts assigning local group SID's at 65536 sequentially, we have lots of conflicting local groups with those lower numbered SID's. To still use the original concept, I had the idea of copying the membership of all the groups on the source filers into new local groups with globally unique SID's. Then run one of the ACL tools to create analogous ACE's for the new group wherever it finds the old one. (This is all done pre-migration) After the migration we simply create local groups on the destination machine with SID's of the new, analogous rights granted group. Has anyone tried something like this before?? Can anyone see any problems with this approach?? How about an alternative approach?? Again, the idea is to prevent the requirement of a filesystem traversal during migration. Thanks in advance!! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 Storage Lead (NAS/SAN) Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

1 0

RE: An idea on migrating NTFS data
by Conner, Neil 03 Jul '01

03 Jul '01

Here's an even simpler idea: use global groups to assign permissions. Cheers, Neil -----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, July 03, 2001 2:37 PM To: toasters(a)mathworks.com Subject: An idea on migrating NTFS data We are about to migrate a bunch of data between different filers, among which is some NTFS security style data. The only non-slam-dunk about it is NTFS local groups. Background: We use the Microsoft recommended method of assigning rights to filesystems, that is UGLR (phonetic == Uglier). Users belong to ... Global groups, which belong to ... Local groups, which are assigned access to ... Resources. The problem is that Local groups have a non-global SIDs between machines. That is, each filer assigns its own local SID's to local groups in its /etc/lclgroups.cfg on the root volume. That SID gets moved with the ACL data to the destination, but the destination machine can't resolve its membership with its local groups. The traditional approach to fixing this is using a tool from Aelita or subinacl to traverse the entire destination filesystem (post-migration) and replacing any occurrence of the old SID with that of a new SID for a local group on the destination filer. This is all fine and good, but could take forever. -------- THE IDEA -------- Here's my idea on a better way to do this. Simply shutdown CIFS on the destination machine pre-move and create analogous local group entries with SIDs that match the source. NetApp tech support might not like the idea too much, but it would mean that the same global groups would belong to that SID and thus no filesystem traversing or ACL modification! Ta Da! Unfortunately, we are copying data from more source machines than there are destination machines and we are not copying data per filer - that is some data from filer1 will go to filerA, some to filerB, etc. This means that for my scheme to work, we'd need globally unique local group SID's. Since it appears that ONTAP starts assigning local group SID's at 65536 sequentially, we have lots of conflicting local groups with those lower numbered SID's. To still use the original concept, I had the idea of copying the membership of all the groups on the source filers into new local groups with globally unique SID's. Then run one of the ACL tools to create analogous ACE's for the new group wherever it finds the old one. (This is all done pre-migration) After the migration we simply create local groups on the destination machine with SID's of the new, analogous rights granted group. Has anyone tried something like this before?? Can anyone see any problems with this approach?? How about an alternative approach?? Again, the idea is to prevent the requirement of a filesystem traversal during migration. Thanks in advance!! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 Storage Lead (NAS/SAN) Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

1 0

An idea on migrating NTFS data
by Jeffrey Krueger 03 Jul '01

03 Jul '01

We are about to migrate a bunch of data between different filers, among which is some NTFS security style data. The only non-slam-dunk about it is NTFS local groups. Background: We use the Microsoft recommended method of assigning rights to filesystems, that is UGLR (phonetic == Uglier). Users belong to ... Global groups, which belong to ... Local groups, which are assigned access to ... Resources. The problem is that Local groups have a non-global SIDs between machines. That is, each filer assigns its own local SID's to local groups in its /etc/lclgroups.cfg on the root volume. That SID gets moved with the ACL data to the destination, but the destination machine can't resolve its membership with its local groups. The traditional approach to fixing this is using a tool from Aelita or subinacl to traverse the entire destination filesystem (post-migration) and replacing any occurrence of the old SID with that of a new SID for a local group on the destination filer. This is all fine and good, but could take forever. -------- THE IDEA -------- Here's my idea on a better way to do this. Simply shutdown CIFS on the destination machine pre-move and create analogous local group entries with SIDs that match the source. NetApp tech support might not like the idea too much, but it would mean that the same global groups would belong to that SID and thus no filesystem traversing or ACL modification! Ta Da! Unfortunately, we are copying data from more source machines than there are destination machines and we are not copying data per filer - that is some data from filer1 will go to filerA, some to filerB, etc. This means that for my scheme to work, we'd need globally unique local group SID's. Since it appears that ONTAP starts assigning local group SID's at 65536 sequentially, we have lots of conflicting local groups with those lower numbered SID's. To still use the original concept, I had the idea of copying the membership of all the groups on the source filers into new local groups with globally unique SID's. Then run one of the ACL tools to create analogous ACE's for the new group wherever it finds the old one. (This is all done pre-migration) After the migration we simply create local groups on the destination machine with SID's of the new, analogous rights granted group. Has anyone tried something like this before?? Can anyone see any problems with this approach?? How about an alternative approach?? Again, the idea is to prevent the requirement of a filesystem traversal during migration. Thanks in advance!! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 Storage Lead (NAS/SAN) Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

1 0

RE: NT And SQL with Network Appliance
by Joe Luchtenberg 03 Jul '01

03 Jul '01

Wow! Can I give you as a reference account to interested NetApp prospects?! Reminds me of the post about 8 months ago (?) from a longtime toaster admin who was griping about something then qualified it with a comment to the effect of, "Don't get me wrong, you can take my filer when you rip it from my cold, dead fingers!" -----Original Message----- From: Gagnon, Steven (P.) [mailto:sgagnon3@visteon.com] Sent: Tuesday, July 03, 2001 3:45 PM To: 'lgartner(a)rpu.org'; 'toasters(a)mathworks.com' Subject: NT And SQL with Network Appliance Hi Lori, Doug Wellbaum asked me to answer some concerns you may have. You may contact me personally if you have any more questions. We have 2 databases running on the filer on the SQL (ver. 6.5) end. Both of them are 500MB. Relatively small but effective. We have encountered no problem with the filer. I haven't used the filer yet in a disaster recovery plan, but I'm sure I would have no issue. Best practice is to use SnapShots or Snap Mirror for added protection. I would consider running your SQL backups (log files) just a few minutes before a snap shot occurs, then in case of disaster, you have to most up to date information and can get your database back on line within minutes. Create a separate ID for the filer and give it Admin privileges. Have it log on as a service. Do not use your Administrator account as if you change your password you will get suspect databases. -- This is from the trenches, things where you go, Ooops! when you are learning for the first time... Make sure it is on a different volume than your data storage. I have never experienced any down time with the filer. We have had it for over a year so far. It's a F740. We have two of them. The other serves UNIX and Oracle. Oracle embraces NetApp. Still wondering why Microsoft is so far behind the ball on this one??? It is as reliable as the hard disk you are using, with snap shot it becomes more reliable and faster than SCSI. As for service from NetApp. It is A1. I have never seen any other company with such dedicated people. You've have already experienced this, I'm sure... They were here late in the evening, early in the morning. Their telephone support is top notch. They will not let you go until your problem is solved, and their expertise is number one. I have 100GB for file storage. This works great too. You can call me if you have any other questions. Thanks Steven Steven Gagnon Visteon Canada Inc. Tel: (905) 475 8510 Ext. 4207 NT / SQL System Administrator Pager: (416) 753 3132 Markham, Ontario, Canada FordNet: 854-4207 Fax: (905) 470 3296 "Man's mind, once stretched by a new idea, never regains its original dimensions." -Oliver Wendell Holmes

1 0

Using a Filer 740 with DFS (Distributed File System)
by Grey, Michael 03 Jul '01

03 Jul '01

I'm having a problem with the filer only supporting 256 characters as a combination of the path and file name. I have an NT Server currently running DFS with local attached storage. I would like to migrate the data from NT to the filer while still keeping the NT Server running DFS as the entry point into the filer. When trying to migrate files with a length greater then 256 characters I receive an error message that the file name or extension is too long. Would anyone happen to know of a workaround for this issue. The Filer is a F740 with 1TB disk space with release 6.1 Regards, Michael Grey Toronto Transit Commission Information Technology Services Client / Server Technical Support 416-393-6791 michael.grey(a)ttc.ca

1 0

NT And SQL with Network Appliance
by Gagnon, Steven (P.) 03 Jul '01

03 Jul '01

Hi Lori, Doug Wellbaum asked me to answer some concerns you may have. You may contact me personally if you have any more questions. We have 2 databases running on the filer on the SQL (ver. 6.5) end. Both of them are 500MB. Relatively small but effective. We have encountered no problem with the filer. I haven't used the filer yet in a disaster recovery plan, but I'm sure I would have no issue. Best practice is to use SnapShots or Snap Mirror for added protection. I would consider running your SQL backups (log files) just a few minutes before a snap shot occurs, then in case of disaster, you have to most up to date information and can get your database back on line within minutes. Create a separate ID for the filer and give it Admin privileges. Have it log on as a service. Do not use your Administrator account as if you change your password you will get suspect databases. -- This is from the trenches, things where you go, Ooops! when you are learning for the first time... Make sure it is on a different volume than your data storage. I have never experienced any down time with the filer. We have had it for over a year so far. It's a F740. We have two of them. The other serves UNIX and Oracle. Oracle embraces NetApp. Still wondering why Microsoft is so far behind the ball on this one??? It is as reliable as the hard disk you are using, with snap shot it becomes more reliable and faster than SCSI. As for service from NetApp. It is A1. I have never seen any other company with such dedicated people. You've have already experienced this, I'm sure... They were here late in the evening, early in the morning. Their telephone support is top notch. They will not let you go until your problem is solved, and their expertise is number one. I have 100GB for file storage. This works great too. You can call me if you have any other questions. Thanks Steven Steven Gagnon Visteon Canada Inc. Tel: (905) 475 8510 Ext. 4207 NT / SQL System Administrator Pager: (416) 753 3132 Markham, Ontario, Canada FordNet: 854-4207 Fax: (905) 470 3296 "Man's mind, once stretched by a new idea, never regains its original dimensions." -Oliver Wendell Holmes

1 0

RE: 34F+ & 36F impact on snapmirror
by Debbie.Lane＠intermec.com 03 Jul '01

03 Jul '01

The 36 GB BCS drive (34F+) is .5GB smaller than the 36GB ZCS (36F) drive. Sorry I can't help with the other questions. -----Original Message----- From: NicholosC(a)maxis.net.my [mailto:NicholosC@maxis.net.my] Sent: Thursday, June 21, 2001 9:19 PM To: toasters(a)mathworks.com Subject: 34F+ & 36F impact on snapmirror All, Had an original F740 with two full shelves of 36F disks. Added a new F740 (for snapmirror purpose) with the same configuration but it came with the new 34F+ disks. Configured the new filer with the identical volume configuration for snapmirror. Original filer was running 5.3.7r3 while the new filer is running 6.1r1 because of the requirement of 34F+ disks. My issues are: (1) Anybody has the information on the "right-size" of the 34F+ disk? My understanding is that 36F has 34,500 KB. The yellow flyer says that 34F+ has lesser capacity but that does not help very much, how much lesser? (2) Because of the lesser capacity (I guess), the target volume can not be snapmirrored. I have to rearrange the volume configuration making the target volumes by one disk more than the source volume, only after that the snapmirror went through. The intention of the snapmirror is for disaster recovery. In the event that the source filer is not available, the target filer will be changed from snapmirrored status to regular volume. When the original source filer is ready for operation again, what is the best practice to move the data back? (3) Snapmirror back on the reverse direction would not work because now the original source filer volume is smaller than the original target volume. (4) Would vol copy falls into the same restriction of target volume has to be equal or larger? In my case, they could not be equal because of one is using 36F and the other is using 34F+. Thanks in advanced for your comments/suggestions. Nic

1 0

RE: Snapmirror, Snapshots and DF output
by Brookes, Matt 03 Jul '01

03 Jul '01

Hi FPS France, :) You're probably experiencing bug 18560 http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=18560. The destination volume displays the default snap reserve of 20%. This is fixed in DataONTAP 6.0 and above, whereby the snap reserve set on the source volume is propagated to the destination. See NOW for current GA release - 6.0.1R3 at the time of writing. Regards, Matt. ________________________________________________________________ Matthew Brookes mailto:mbrookes@netapp.com Systems Engineer http://www.netapp.com Network Appliance Tel: +353 1 4064600 Unit 36, Rathfarnham Gate Fax: +353 1 4064601 Dublin 14, IRELAND Mob: +353 87 8575127 > -----Original Message----- > From: FPS France [mailto:fpsfrance@fps.fr] > Sent: 03 July 2001 17:10 > To: toasters(a)mathworks.com > Subject: Snapmirror, Snapshots and DF output > > > FPS France > > Hi, > > We had installed a snapmirror configuration with the following > particular trick : snap reserve volX 5 as the costumer would limit the > snapshot space consuption. > Now the snapmirror service works fine, the costumer > outlined something > strange in the DF output from each Filers. > Each Filer has a root volume mirrored on the other Filer. > As u can see > below, sources volumes are vol0 and mirrors volumes are mir_vol0. > From my calculation (less or more), I can check that for > vol0's volumes, > we had a snapshots reserved space around 5%, but in mir_vol0's we have > roughtly four times the snap space consuption more than the > source volume > (31.8 vs 7.9 and 15.6 vs 3.9 : 5% vs 20%). Before making those volumes > snapmirror destinations we took care to modify the snap > reserve to 5%. So > why do we got those outputs ? Any idea ? Any experience with > the df command > snap reserve 5 and snapmirror ? > All of this run on 5.3.7R3, F740. > > Netapp 1 : > << > ===== DF ===== > Filesystem kbytes used avail capacity > Mounted on > /vol/vol0/ 150937460 137664288 13273172 91% > /vol/vol0/ > /vol/vol0/.snapshot 7944076 1473572 6470504 19% > /vol/vol0/.snapshot > /vol/mir_vol0/ 62593232 155988 62437244 0% > /vol/mir_vol0/ > /vol/mir_vol0/.snapshot 15648304 510236 15138068 3% > /vol/mir_vol0/.snapshot > >> > > Netapp2 : > << > ===== DF ===== > Filesystem kbytes used avail capacity > Mounted on > /vol/vol0/ 74329460 155988 74173472 0% > /vol/vol0/ > /vol/vol0/.snapshot 3912076 510236 3401840 13% > /vol/vol0/.snapshot > /vol/mir_vol0/ 127105232 137664288 0 108% > /vol/mir_vol0/ > /vol/mir_vol0/.snapshot 31776304 1473572 30302732 5% > /vol/mir_vol0/.snapshot > >> >

1 0

36F disk
by Debbie.Lane＠intermec.com 03 Jul '01

03 Jul '01

Can a 36F Fibre Channel disk be used in a system that is not NetApp? I am asking because the decision to buy or lease was based on the belief that if at some point we wanted to discontinue using NetApp the disks could be used elsewhere. Thanks for your help. --Debbie

1 0

RE: Snapmirror, Snapshots and DF output
by Fox, Adam 03 Jul '01

03 Jul '01

2 things stand out in your message. 1. Reducing snap reserve does not contain snapshot usage. Snapshots will take up as much space as they need regardless of snap reserve size. What snap reserve does is contain the active file system blocks to a certain amount of space. This is an important concept in SnapShot planning. 2. It would be good to see the output of a snap reserve command from each filer. Something looks a little off. Becuase it seems that you adjusted the snap reserve AFTER the snap mirror occured because as I read it below, your sources are larger than your destinations and that is not possible with SnapMirror. 3. A sysconfig -r would also be useful just to match eveything up. While some volumes of different sizes work with SnapMirror, the simplest way to implement SnapMirror is to simply set up each source and destination the same way (if possible) so that it's easy to compare sizes properly. I realize that this isn't always possible, but if you have the opportunity to do it, it makes life easier. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com > why do we got those outputs ? Any idea ? Any experience with > the df command > snap reserve 5 and snapmirror ? > All of this run on 5.3.7R3, F740. > > Netapp 1 : > << > ===== DF ===== > Filesystem kbytes used avail capacity > Mounted on > /vol/vol0/ 150937460 137664288 13273172 91% > /vol/vol0/ > /vol/vol0/.snapshot 7944076 1473572 6470504 19% > /vol/vol0/.snapshot > /vol/mir_vol0/ 62593232 155988 62437244 0% > /vol/mir_vol0/ > /vol/mir_vol0/.snapshot 15648304 510236 15138068 3% > /vol/mir_vol0/.snapshot > >> > > Netapp2 : > << > ===== DF ===== > Filesystem kbytes used avail capacity > Mounted on > /vol/vol0/ 74329460 155988 74173472 0% > /vol/vol0/ > /vol/vol0/.snapshot 3912076 510236 3401840 13% > /vol/vol0/.snapshot > /vol/mir_vol0/ 127105232 137664288 0 108% > /vol/mir_vol0/ > /vol/mir_vol0/.snapshot 31776304 1473572 30302732 5% > /vol/mir_vol0/.snapshot > >> >

1 0

Snapmirror, Snapshots and DF output
by FPS France 03 Jul '01

03 Jul '01

FPS France Hi, We had installed a snapmirror configuration with the following particular trick : snap reserve volX 5 as the costumer would limit the snapshot space consuption. Now the snapmirror service works fine, the costumer outlined something strange in the DF output from each Filers. Each Filer has a root volume mirrored on the other Filer. As u can see below, sources volumes are vol0 and mirrors volumes are mir_vol0. From my calculation (less or more), I can check that for vol0's volumes, we had a snapshots reserved space around 5%, but in mir_vol0's we have roughtly four times the snap space consuption more than the source volume (31.8 vs 7.9 and 15.6 vs 3.9 : 5% vs 20%). Before making those volumes snapmirror destinations we took care to modify the snap reserve to 5%. So why do we got those outputs ? Any idea ? Any experience with the df command snap reserve 5 and snapmirror ? All of this run on 5.3.7R3, F740. Netapp 1 : << ===== DF ===== Filesystem kbytes used avail capacity Mounted on /vol/vol0/ 150937460 137664288 13273172 91% /vol/vol0/ /vol/vol0/.snapshot 7944076 1473572 6470504 19% /vol/vol0/.snapshot /vol/mir_vol0/ 62593232 155988 62437244 0% /vol/mir_vol0/ /vol/mir_vol0/.snapshot 15648304 510236 15138068 3% /vol/mir_vol0/.snapshot >> Netapp2 : << ===== DF ===== Filesystem kbytes used avail capacity Mounted on /vol/vol0/ 74329460 155988 74173472 0% /vol/vol0/ /vol/vol0/.snapshot 3912076 510236 3401840 13% /vol/vol0/.snapshot /vol/mir_vol0/ 127105232 137664288 0 108% /vol/mir_vol0/ /vol/mir_vol0/.snapshot 31776304 1473572 30302732 5% /vol/mir_vol0/.snapshot >>

1 0

deleting a qtree
by Leonard, Roger 03 Jul '01

03 Jul '01

is there any way to delete a qtree? i typo'ed one and now want to remove it. thanks Roger D. Leonard

2 1

RE: Vol copy max speed ? alternatives ?
by Fox, Adam 02 Jul '01

02 Jul '01

> - so we used ndmp through tapes because we were not sure > enought of the > NdmpCopy reliability - may I find a tool to validate NdmpCopy > in our lab ? > :) > I've had this question asked before and my answer was simple. All the ndmpcopy does is call our native dump and restore programs on the filer (or filers if you are copying filer to filer). The host running ndmpcopy is not involved in the tranfer other than telling each host what to do, the data path is within the same filer or filer to filer. So if you trust our dump and restore commands, then you should trust ndmpcopy since underneath the covers they are the same thing. Don't misunderstand. The way you did it was fine. But if you were willing to trust dump and restore with tapes, you should be able to trust ndmpcopy since they are making the same calls. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com

1 0

RE: F85 Vs 740
by Tom "Mad Dog" Yergeau 02 Jul '01

02 Jul '01

Look at it this way. The F85 is a replacement for the F720. The F820 is a replacement for the F760. What's the replacement for the F740? I don't see one yet. So my guess is NetApp plans to keep the F740 around for a while. I'd go for it. It's a better box in a lot of ways than the F85 (NetApp-designed hardware compared to COTS hardware, clusterable, a tad more scalable, FC drives instead of SCSI drives, etc). Tom -----Original Message----- From: Steve Losen [mailto:scl@sasha.acc.virginia.edu] Sent: Friday, June 29, 2001 11:05 AM To: toasters(a)mathworks.com Subject: Re: F85 Vs 740 The 740 is an older model and the F85 is brand new. Since the end of availability dates have already been announced for the 720 and 760, I would want to have some idea how much longer Netapp will support the 740 as compared to the F85. Bear in mind that the 700 series uses a DEC Alpha processor and the new 800 series and F85 are Intel. Soon the 740 will be the only Alpha based filer that Netapp still sells. On the other hand, if you need something fast, and it's not clear how soon you can get a F85, then a 740 might look more attractive, especially if you are getting a nice discount because of the F85 unavailability. > > I'm a NetApp newbie looking for feedback from experience users of these > boxes. > > I just ordered a F85, but because of non availability of F85's was offered a > 740 instead. > I'm not as concerned w/ scalability as I am w/ performance. > The data that it will host is under a 100GB now and should grow much beyond > 200GB. > The F85 that I ordered has 12 36GB drives which I figure will leave me w/ > ~280GB of usable space. > > There are 120 NT 4 workstations and a handful of UNIX boxes on this network. > The majority of the data will be CIFS, some NFS and HTTP. I plan on moving > all of the users home folders and shared data to the filer. > The connectivity of the servers and filer will be at 100Mb and the > workstations are at 10Mb. > > Any feedback would be appreciated. > > Mark > > Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

1 0

win2000 conections
by David C Baumgardner 02 Jul '01

02 Jul '01

Hello fellow toasters, I just got my first win2000 box. I have ten network drives connected to my NetApp. The CIFS sessions on the NetApp (5.3.6r2)is showing ten separate sessions. My NT4.0 boxes show only one connection with ten shares. Anyone know what is going on with the win2000 box? is this normal? David Baumgardner CAD/CAM Administrator Container Engineering 419.247.8274

1 0

Re: Vol copy max speed ? alternatives ?
by FPS France 02 Jul '01

02 Jul '01

FPS France Just to let everyone interested in know : - we firstly would make the migration with snapmirror but we figured out that migrating 14x18Gb disks to 7x36Gb disk was impossible (a 13x18G volume - with one 18G spare beside - is tiny larger than a 6x36G volume - just 9G greater :) - so we used ndmp through tapes because we were not sure enought of the NdmpCopy reliability - may I find a tool to validate NdmpCopy in our lab ? :) - when the migration was successful, we installed Snapmirror and obtain a throughput of 20Mb/s :) systems were 5.3.7R3 and models, two F740. Thank you for all your mail. CU ----- Original Message ----- From: "Van Agt, Cyril" <cvanagt(a)netapp.com> To: "Fox, Adam" <Adam.Fox(a)netapp.com>; "'FPS France'" <fpsfrance(a)fps.fr> Cc: "Mohler, Jeff" <jeff.mohler(a)netapp.com> Sent: Thursday, June 28, 2001 12:40 AM Subject: RE: Vol copy max speed ? alternatives ? Correct. Good use of the WWW ; and a refresh for you old French... ;-) Cyril PS : FPS is a NetApp Partner in France. -----Original Message----- From: Fox, Adam Sent: jeudi 28 juin 2001 00:46 To: Van Agt, Cyril; 'FPS France' Cc: Mohler, Jeff Subject: RE: Vol copy max speed ? alternatives ? I think this is a close English translation (thanks to Altavista's babelfish service) In English: Me I saw SnapMirror making of the 55 MB/s between two F840 via Gigabit. But I do not have experience with of F630 I think that SnapMirror is the best solution in any event. I think that SnapMirror can " be rented " for a migration... Call me if you wish to discuss it. For Jeff and I who aren't up on our French. :) -- Adam > -----Original Message----- > From: Van Agt, Cyril > Sent: Wednesday, June 27, 2001 6:29 PM > To: 'FPS France' > Cc: Mohler, Jeff; Fox, Adam > Subject: RE: Vol copy max speed ? alternatives ? > > > Moi j'ai vu SnapMirror faire du 55 MB/s entre deux F840 via Gigabit. > Mais je n'ai pas d'expérience avec du F630 :-) > > Je pense que SnapMirror est la meilleure solution de toute façon. > Je pense que SnapMirror peut se "louer" pour une migration... > Appelez-moi si vous désirez en discuter. > > Cyril Van Agt > ============================================================== > Cyril Van Agt mailto:cvanagt@netapp.com > Systems Engineer http://www.netapp.com/ > Network Appliance France Phone: +33 1.55.20.18.48 > 42, quai du Point du Jour Fax: +33 1.55.20.18.01 > F-92100 BOULOGNE Cell: +33 6.08.85.38.85 > ============================================================== > > > -----Original Message----- > From: Mohler, Jeff [mailto:jeff.mohler@netapp.com] > Sent: mercredi 27 juin 2001 23:24 > To: Fox, Adam; 'FPS France'; toasters(a)mathworks.com > Subject: RE: Vol copy max speed ? alternatives ? > > > Myself..I havent seen col copy/ndmpcopy/snapmirror do much > over 18-22Mb/sec depending on platform. > > If I had a free hour Id love to go into my Lab and prove > myself wrong, but I wont be able to until at least tomorrow > if anyone is interested in some data between some 880s. > > -----Original Message----- > From: Fox, Adam [mailto:Adam.Fox@netapp.com] > Sent: Wednesday, June 27, 2001 1:46 PM > To: 'FPS France'; toasters(a)mathworks.com > Subject: RE: Vol copy max speed ? alternatives ? > > > I guess I'm not sure what a 'perfect' 10BT connection speed is > and so the comparisons confuse me. > > By my calculations: > > 10Mb 1MB 1GB 60s 60 min > ---- ------- ------ ------- --------- = 4.39 GB/hr. > 1s 8Mb 1024MB 1 min 1 hr > > This is 10BT at it's maximum throughput...not counting for > protocols, etc. > > So let's look at 36 GB/hour using the same method: > > 36GB 1024 MB 8Mb 1 hr 1 min > ----- ------------ ------ ------- ---------- = 81.92 Mb/s > 1 hr 1 GB 1MB 60 min 60 sec > > So you're a little under a "perfect" 100BT from my calcuations. > Not great, but not as bad as I read it to be..and 18X better > than 10BT. > > If the purpose is to reduce downtime (perfectly resonable) then > perhaps you need something that can do incremental changes > instead of doing it in one shot. > > ndmpcopy can help. It's free and has incremental support even if > it's a little slower, if you can reduce the size of your last > incremental, it won't hurt as much if the data you are trying to > move while you are down is smaller. > > SnapMirror is *great* for this. The only downside is it is not > free. You'll need to work out a deal with your rep if you feel > this is really the way you want to go. > > Just some thoughts. > > -- Adam Fox > NetApp Professional Services, NC > adamfox(a)netapp.com > > > > -----Original Message----- > > From: FPS France [mailto:fpsfrance@fps.fr] > > Sent: Thursday, June 21, 2001 11:20 AM > > To: toasters(a)mathworks.com > > Subject: Vol copy max speed ? alternatives ? > > > > > > Hi everyone, > > > > We are looking for a high rate migration operation which > > could let us move a > > volume from a disk shelf to another. > > In a first place, we think of using the vol copy command. We > > thaught we > > could easily manage a strong volume copy rate but it appeared > > the rate is > > buggy limited to 36Gb/hour (as if the Filer was copyinbg over > > a 'perfect' > > 10Bas-T interface) : > > http://now.netapp.com/Knowledgebase/solutionarea.asp?id=3.0.72 > 95526.2875209& > resource= > In looking around we found papers dealing with others > interface kinds : > http://now.netapp.com/Knowledgebase/solutionarea.asp?id=3.0.72 95507.2875209 The limit are 25GB/hr over 100Base-T interface, and 28GB/hr over FDDI so less than a 'perfect' 10Base-T interface. (on a F630 Filer :) Reasons given by the NetApp support is the CPU has a bunch of work in calculating optimizations of read and write operations. But I would be sure we are really not strunglled by any other limitations. So here are our two questions : - (just to be sure) did anyone succed in using the vol copy command once and go beyond these limits ? -what is your opinion about that alternative : plug the Filer on a private Giga-ethernet network and make a manual copy (copy -R mnt/nac/vol0 /other_place ) of the whole volume from a shelf to the other. Do you think we could obtain real high rate transfers while keeping the integrity of the volume ? (the volume is a root volume with the "/etc" directory), no special tricks needed (if I use Windows, may I expect ACL modifications) ? I thank you in advance.

1 0

MSSQL on NetApp System
by Lori Gartner 30 Jun '01

30 Jun '01

We are considering the purchase of a NetApp filer for our SAP system. Our SAP system is running on NT with MSSQL 7.0 database. I am told by NetApp that this is no problem - a great solution! I am told by almost every other NAS (and SAN) solution provider that Microsoft will not support me and that I should put in a SAN system and definitely NOT a NAS system. I would really like to hear from someone who is running MSSQL on a NetApp filer! Thanks in advance! Lori Gartner PS - I can not search the archives on the web because our firewall is blocking port 1999. I apologize if this has been discussed before.

2 1

RE: NDMPcopy without security
by Manley, David 30 Jun '01

30 Jun '01

> Doh. I realize you probably got this from the ONTAP NDMP source tree, Yup. Thinking about it though, I'm guessing that these env variables probably only apply to DAR and not ndmpcopy. Sorry, dave -----Original Message----- From: Jeffrey Krueger To: Jeffrey Krueger Cc: Manley, David; 'ndmp-users(a)netapp.com '; 'toasters(a)mathworks.com ' Sent: 6/29/01 5:49 PM Subject: Re: NDMPcopy without security Doh. I realize you probably got this from the ONTAP NDMP source tree, not from JNDMPcopy. Thats what I get for trying to be a smart ass. =) -- Jeff On Fri, Jun 29, 2001 at 05:43:11PM -0700, Jeffrey Krueger wrote: > Hmmm... not bad. I guess JNDMPcopy has some hidden goodies. Thanks for > the tip Dave, we'll test it out in our lab and see if it does what we > need. > > Anybody want to volunteer some official documentation on the *full* list of > NDMP environment variables implemented in ONTAP and a description of their > use? > > -- Jeff > > > On Fri, Jun 29, 2001 at 05:05:32PM -0700, Manley, David wrote: > > Hi - > > > > Not sure who is around to read your message at Netapp before the holiday, > > but if there is anyone that knows a better answer, please pass it along. > > > > grepping through what ndmp is passing by default to dump reveals: > > > > dump.java: default_env.put("NO_ACLS", "N"); > > dump.java: default_env.put("EXTRACT_ACL", "Y"); > > > > So I'd assume you could flip these, not that I've personally tried it. > > > > -dave > > > > -----Original Message----- > > From: Jeffrey Krueger > > To: ndmp-users(a)netapp.com; toasters(a)mathworks.com > > Sent: 6/29/01 4:38 PM > > Subject: NDMPcopy without security > > > > Does anyone know of an NDMP environment variable or other method to > > prevent > > NDMPcopy from restoring UNIX permissions or NTFS ACL's? > > > > We would like to migrate some data by first doing a full copy *with* > > ACL's, > > then substitute local group SID's on the destination, and finally resume > > incremental updates *without* updating our already "fixed" destination > > ACL's. > > > > The benefit of this approach is that SID substitution across a large > > qtree/volume could take a long period of time (hours/days). We'd rather > > do > > that pre-cutover when users are not impacted the during the actual > > migration when we make the source data read-only or inaccessible. > > > > Any ideas? The NDMP v3 spec doesn't mention any environment variables > > for > > this and I can't find any NetApp documentation on what NDMP environment > > variables they use and their purpose. Note: Our solution must be > > NDMPcopy > > based. > > > > Thanks! > > > > -- Jeff > > > > -- > > ------------------------------------------------------------------------ > > ---- > > Jeff Krueger, NetApp CA E-Mail: jeff(a)qualcomm.com > > Senior Engineer Phone: 858-651-6709 > > Storage Lead (NAS/SAN) Fax: 858-651-6627 > > QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com > > > > To remove yourself from the ndmp-users(a)ndmp.org mailing list, > > send mail to <majordomo(a)netapp.com> with the following > > command in the BODY of your email message: > > unsubscribe dl-ndmp-users [your email address] > > >

1 0

RE: NDMPcopy without security
by Manley, David 30 Jun '01

30 Jun '01

Hi - Not sure who is around to read your message at Netapp before the holiday, but if there is anyone that knows a better answer, please pass it along. grepping through what ndmp is passing by default to dump reveals: dump.java: default_env.put("NO_ACLS", "N"); dump.java: default_env.put("EXTRACT_ACL", "Y"); So I'd assume you could flip these, not that I've personally tried it. -dave -----Original Message----- From: Jeffrey Krueger To: ndmp-users(a)netapp.com; toasters(a)mathworks.com Sent: 6/29/01 4:38 PM Subject: NDMPcopy without security Does anyone know of an NDMP environment variable or other method to prevent NDMPcopy from restoring UNIX permissions or NTFS ACL's? We would like to migrate some data by first doing a full copy *with* ACL's, then substitute local group SID's on the destination, and finally resume incremental updates *without* updating our already "fixed" destination ACL's. The benefit of this approach is that SID substitution across a large qtree/volume could take a long period of time (hours/days). We'd rather do that pre-cutover when users are not impacted the during the actual migration when we make the source data read-only or inaccessible. Any ideas? The NDMP v3 spec doesn't mention any environment variables for this and I can't find any NetApp documentation on what NDMP environment variables they use and their purpose. Note: Our solution must be NDMPcopy based. Thanks! -- Jeff -- ------------------------------------------------------------------------ ---- Jeff Krueger, NetApp CA E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 Storage Lead (NAS/SAN) Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com To remove yourself from the ndmp-users(a)ndmp.org mailing list, send mail to <majordomo(a)netapp.com> with the following command in the BODY of your email message: unsubscribe dl-ndmp-users [your email address]

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters