toasters

toasters@lists.teaparty.net

13515 discussions

2 questions.
by Jaye Mathisen 27 Dec '98

27 Dec '98

Using 4.3.4 on a F540, 256MB RAM, 8MB NVRAM. I'm using the oh-so-secret method of using SQL server on a filer... Initial tests with small databases have been great. Big problem: I can't create a database device larger than 4GB's on the CIFS share. Anything up to 4 is fine, anything over, uh huh. Local drives can handle larger, but that's not where I want to be... 1) Any ideas on whats wrong here? 2) Anybody else using a filer under SQL server?

2 3

Re: 2 questions.
by guy＠netapp.com 27 Dec '98

27 Dec '98

> > If so, the problem is that we don't support files >4GB in releases prior > > to ONTAP 5.1. > --- > > And what about later versions (just because the question is so obviously > un-answered)? If we didn't support it in 5.1 or later versions, I would have said "the problem is that we don't support files >4GB" without adding "prior to ONTAP 5.1" - I assumed, apparently incorrectly, that it was obvious from the way I stated it....

1 0

Re: Routing Anomaly..fixed (and how)
by mds＠gbnet.net 24 Dec '98

24 Dec '98

On Wed 23 Dec, 1998, sirbruce(a)ix.netcom.com wrote: > The only other thing I haven't seen mentioned is number of disks. This can > be a limiting factor in performance, particularly towards the lower end. > Having more disks that you need will not make you appreciably faster, but > having too few will be very noticeable. Oh too true, especially as data on disks is becoming relatively less accessible in high-throughput applications. Brian Wong's book has a lucid explanation for why more spindles of lower capacity can make a hell of a lot more sense than fewer, bigger disks. > > In current filers, I don't know what the right ratio would be. I used to > use about 100-200ops/disk as a rule of thumb, but of course it depends on the > kid of ops. If you have an array of 21-28 disks, then I doubt that's the > limiting factor. If you only have 14, you might consider adding some more > to the filesystem and seeing if that improves your write throughput. Adding > more NVRAM is of course good if possible for your filer. I'd speculate that the new multiple RAID group feature in DOT5 also has an important performance dimension, besides the reliability aspects. For writes, and degraded reads, the fewer disks in a RAID group the higher the performance I'd expect in the RAID calculation. Now, assuming a volume has a number of RAID groups, I'd presume the WAFL filesystem will still consume blocks over all the RAID groups and make attempts to write whole stripes into each RAID group, thereby gaining the fullest bandwidth available to the platters, given the calculations that have to be done on the data. One interesting thing to note is how much the filer needs to read from disk while performing write-intensive work. If the filer isn't reading much from disk at all, then you're laying down fresh data stright from memory and the machine will be running at full tilt. If there's quite a lot of reading going on then the machine is having to work harder to lay the data down on the platters. This is more likely to happen when the volume is on the full side, has been running with some degree of churn for a while and contains relatively small files. Ie old data being removed to be replaced by new data - as in usenet news spools. So, if I was hoping for high performance for a news spool on a filer I'd be thinking of a 760 with many 9GB disks (the smallest available I believe) in an unclustered configuration. I'd also play with the RAID group sizes until I'd struck a rough balance between the costs, the performance and the resilience. I'd use Gb-ether into an Extreme switch. I'd toy with using the no-atime option, perhaps play with both NFS2 and NFS3 to see which gave best performance. And I'd use different hosts for spooling the news, and for serving the news...but that's application level stuff and far less easy to work on and comment on. >-- End of excerpt from sirbruce(a)ix.netcom.com

3 2

Re: Routing Anomaly..fixed (and how)
by sirbruce＠ix.netcom.com 24 Dec '98

24 Dec '98

The only other thing I haven't seen mentioned is number of disks. This can be a limiting factor in performance, particularly towards the lower end. Having more disks that you need will not make you appreciably faster, but having too few will be very noticeable. In current filers, I don't know what the right ratio would be. I used to use about 100-200ops/disk as a rule of thumb, but of course it depends on the kid of ops. If you have an array of 21-28 disks, then I doubt that's the limiting factor. If you only have 14, you might consider adding some more to the filesystem and seeing if that improves your write throughput. Adding more NVRAM is of course good if possible for your filer. I'd also do the standard systems reviews, making sure that your interfaces are running at the right speeds, that the routing on the filer is set up correctly (although for ethernet response packets I don't think those are routed - then again, that may have changed; it's complicated depending on the actual media type), and so on. Still, 20MB/sec with your network configuration doesn't sound bad to me. I'm not sure you'll be able to do too much better than that. If you want more, try slapping a gigabit ethernet card in the puppy. :) Bruce

1 0

Re: Routing Anomaly..fixed (and how)
by Keith Brown 23 Dec '98

23 Dec '98

>Yes, I have 32Mb of RAM, but at 50% or 10 seconds, the NVRAM flushes. I >only buffer 16Mb before it takes a data dump *grin* if I understand >correctly. You do understand correctly, but while the "flush" is occuring (actually, it's called a consistency point, or CP for short), the other 16 MB of NVRAM is still being put to good use journaling new file system modifications being made by clients. In other words, you and your filer are enjoying a full 32 MB of "benefit" from the NVRAM. In other words, it is *all* being used for something. There is no waste here! :-) >In a clustered environment, I just use that other half of NVRAM >to buffer to the other box instead of mirroring myself in case of a write >failure (power, etc). In an unclustered environment, you are using that "other half" of NVRAM now. When you cluster two systems together though, well... we have a white paper that tells you what happens much better than I can here: http://www.netapp.com/technology/level3/1004.html >Two clients, both on separate 100Mb interfaces, creating spool files for my >news services using 'dd if/dev/zero of=<filename> count=<x>'. Hmmm. Benchmarks don't get much more write intensive than this, do they. :-) So large sequential writes then. Fair enough. >When I was seeing about 1300 NFSops/Sec and 18-20MegaBytes of input traffic, >the CPU on the F760 would peg. Yes. Writing is a more CPU intensive function than reading. Lots of shunting things into NVRAM and performing of RAID calculations etc... None of that needs to be done on reads. Anyway, a *sustained* agregate of ~20 MBytes/Sec write performance sounds excellent to me. You only have ~25 MBytes/Sec worth of pipes coming into the filer (2 x 100Mbits/Sec), and the thing is stashing things away onto disks, with RAID, at 80% of the theoretical maximum rate at which data can arrive at its doorstep from the network. Nope... nothing to be ashamed of there I'm afraid. The F760 is a beast and a half! ;-) Keith

1 0

Re: Routing Anomaly..fixed (and how)
by Keith Brown 22 Dec '98

22 Dec '98

Jeff... I'm glad your routing anomilies got sorted out. Regarding your subsequent mail... >Also, Ive noticed a max input rate of about 20Mb/sec into the filter, then >the CPU tops out on my F760. > >I understand that the NVRAM can only process 16Mb at a time before the >system really gums up, but I did expect a little more input performance. > >Does anyone have any official or un-official comments on this? If your F760 is still of the unclustered variety (which I'm sure it is, as we haven't quite yet shipped the F700 series cluster release of Data ONTAP) then you will currently be enjoying the full 32 MB capacity of your NVRAM. In a clustered pair of filers however, each systems NVRAM is mirrored to the other, meaning that each filer's individual *effective* NVRAM capacity for the file system(s) that they are individually journaling is halved to 16 MB. They each still physically have 32 MB of NVRAM of course. On the performance front, I'm afraid you would need to better stipulate precisely what you mean by a "20 Mb/sec input rate" for me or anyone else at NetApp to be able to make a useful comment on whether it looks about right or not. How are you determining this number? Is this MBytes/Sec or MBits/Sec? How many clients are you using, and through what networks are they talking to the filer? What software are you running? What is that software really doing on the I/O front? How are the timings being made? Etc... Keith

4 3

ndmpcopy for linux?
by Gil Smith 22 Dec '98

22 Dec '98

Hi, Has anyone compiled and used the ndmpcopy utility on Linux? If so can you pass on any required changes directly to me. --Thanks, Gil

2 1

RE: ClearCase VOBs on NetApp
by Clarke, Bruce 21 Dec '98

21 Dec '98

Network Appliance is working closely with Rational to fully test the procedures and risks for putting the VOB database on the filer. As has been mentioned, putting the various storage pools has always worked and many customers use this to great advantage. Until the move of Network Appliance into the database space, putting the VOB database on the filer was considered risky. Now that both Oracle and Sybase have certified NetApp, it is just a matter of testing, documentation, and time before Rational provides similar certification since theirs is just a modified Raima database anyway. Some discussion on this topic has already taken place on the Clearcase Users Group discussion groups (CCIUG). If you can, I would suggest accessing those archives for the last 2 months to see where this discussion has gone on that forum and get firsthand Rational's response and plans. Bruce Clarke Network Appliance, Inc. -----Original Message----- From: Nick Thompson [mailto:nickthompson@lucent.com] Sent: Friday, December 18, 1998 1:51 AM To: Toasters(a)mathworks.com Subject: ClearCase VOBs on NetApp Hi, We are just starting to deploy ClearCase... I have been speaking to engineers at Network Applications who assured me that it is possible to create the WHOLE of a ClearCase VOB (including the db) on a NetApp filer (and any other NFS filer for that matter). Since Rational told me this was not possible, I got curious and tried it anyway. It worked! Has anybody else here tried this configuration? Had any problems? According to the ClearCase docs, if you can snapshot a complete VOB (as on a Toaster) then it is not necessary to lock it prior to backup (though some disk may be lost to empty containers if you restore from it). Anybody tried/trust this or would you advise against it? Potentially this could make our backup scheme MUCH simpler. Thanks, -- _ _______ __ __ Nick Thompson | Lucent Technologies / \/ / / __\/ // /\ Lucent Technologies | (Bell Labs Innovations) / / / /__/ _ / / Microelectronics House | nickthompson(a)lucent.com /_/\_/_/____/_/\\_\/ Kings Ride, Ascot | Tel: +44 1344 865951 \_\/\\_\____\_\/ \_\ Berkshire SL5 8AD | Fax: +44 1344 865959

1 0

Re: 5.x Restore cannot read 4.x dumps
by Scott Miller 18 Dec '98

18 Dec '98

On Dec 18, 1:01pm, Stephen Manley wrote: > Subject: Re: 5.x Restore cannot read 4.x dumps > > Below is a dialog with our F630 running 5.1.2P1 trying to read a tape written > > with 4.x. We were able to recover data from this tape using a filer running > > 4.3R4D2. > > > > > > range> restore tvf rst0l > > RESTORE: Tape Block size should be 10240, not 64512. > > Fri Dec 18 13:00:12 EST [isp_main]: Tape block was shorter than byte count. Requested = 4096, Read = -50176 > > RESTORE: Could not initialize media. > > range> restore tvfb rst0l 64512 > > RESTORE: No buffers available. > ... > We figured people would get bitten by this change, so we added the error > message (which is obviously not effective) > RESTORE: Tape Block size should be x, not y. > > Now, how do I know the error message didn't work? This message didn't work because it is not obvious. I'd recommend changing the message to somthing like: RESTORE: restore defaulted to a tape block size of 63K RESTORE: your dump was written with a tape block size of 10K RESTORE: re-trying the restore with the block size of 10K ... and then doing the restore with the blocksize that is on the tape. Since you could print the message, you have all the information needed to do The Right Thing (tm) on the users behalf. If I'm doing a restore, it's usually to recover from a disaster. When I'm recovering from a disaster, people are anxious for their data, I'm tired, frustrated and not in the mood to deal with balky restore software. -Skottie -- ----- Scott Miller | Walt Disney Feature Animation skottie(a)fa.disney.com | Digital Studio Technology

1 0

Re: ClearCase VOBs on NetApp
by Keith Brown 18 Dec '98

18 Dec '98

Hi Nick... >I have been speaking to engineers at Network Applications who assured me >that it is possible to create the WHOLE of a ClearCase VOB (including >the db) on a NetApp filer (and any other NFS filer for that matter). I'm afraid I'm not terribly familiar with the ClearCase application myself, but an extensive amount of work on ClearCase interoperability with filer based network storage has been undertaken here at NetApp. So... I just thought I'd call your attention to: http://www.netapp.com/technology/level3/atria.html which documents some of this work. Keith

1 0

Re: 5.x Restore cannot read 4.x dumps
by grdodson＠lexmark.com 18 Dec '98

18 Dec '98

Below is a dialog with our F630 running 5.1.2P1 trying to read a tape written with 4.x. We were able to recover data from this tape using a filer running 4.3R4D2. range> mt -f rst0l diag 1 Fri Dec 18 12:59:45 EST [tape_admin]: Tape driver diagnostic messages enabled. range> mt -f rst0l status Tape drive: Digital DLT7000 Status: ready, write protected Format: 81633 bpi 40 GB (w/comp) fileno = 0 blockno = 0 resid = 0 range> restore tvf rst0l Fri Dec 18 13:00:12 EST [isp_main]: Tape (6.4):cmdblk 0xfffffc0000be7088 op 0x8 block 54272 no error (20 0, 0) RESTORE: Tape Block size should be 10240, not 64512. Fri Dec 18 13:00:12 EST [isp_main]: Tape block was shorter than byte count. Requested = 4096, Read = -50176 Fri Dec 18 13:00:12 EST [isp_main]: Tape (6.4) no sense data. RESTORE: Could not initialize media. range> restore tvfb rst0l 64512 RESTORE: No buffers available. We now have a VERY strong suspicion that tapes written with 4.x cannot be read with 5.1.2P1. Graydon Dodson grdodson(a)lexmark.com Lexmark International Inc. ----- Begin Included Message ----- From stephen%netapp.com(a)interlock.lexmark.com Thu Dec 17 20:24:43 1998 From: stephen%netapp.com(a)interlock.lexmark.com (Stephen Manley) Subject: Re: 5.x Restore cannot read 4.x dumps To: grdodson(a)sol.lpdev.prtdev.lexmark.com Date: Thu, 17 Dec 1998 17:23:54 -0800 (PST) Cc: toasters%mathworks.com(a)interlock.lexmark.com > > > Anyone having problems restoring their dump tapes? We pulled a couple of > old archive tapes (6 mo. old level 0 dumps) to restore some files and were > unable to read them. Kept getting buffer size or buffer allocation errors. > Placed a call to Tech. Sup. waiting for a callback (and waiting, > and waiting, and waiting...). > > While waiting we tried some experiments. The tapes were written on an > F330 running 4.x NFS & CIFS enabled (so we cannot use a sun to restore them). > We discovered that we could read recent tapes written by either an F630 or > F330 on a F630 running 5.1.2P1 with NFS & CIFS. > > I strongly suspect that a filer running 5.1.2P1 cannot read tapes written > with 4.x. This has a less than pleasant affect on our backup & archive strategy. > > Can anyone confirm this? > What's the exact error message? You should be able to restore 4.x tapes on 5.1 systems, and 5.1 tapes on 4.x systems (obviously ACLs disappear) Stephen Manley FS Recovery Superfan ----- End Included Message -----

2 1

Re: 5.x Restore cannot read 4.x dumps
by stephen＠netapp.com 18 Dec '98

18 Dec '98

[Note: I am snipping out the information that is not relevant to the problem. I'm not trying to trick anybody ;)] Executive summary: restore tvfb rst0l 10 will work on 5.1.2P1. > Below is a dialog with our F630 running 5.1.2P1 trying to read a tape written > with 4.x. We were able to recover data from this tape using a filer running > 4.3R4D2. > > > range> restore tvf rst0l > RESTORE: Tape Block size should be 10240, not 64512. > Fri Dec 18 13:00:12 EST [isp_main]: Tape block was shorter than byte count. Requested = 4096, Read = -50176 > RESTORE: Could not initialize media. > range> restore tvfb rst0l 64512 > RESTORE: No buffers available. Ok. This is actually a very simple problem. In every release before 5.1, dump's default tape record size (think 'b' option) was 10KB. In 5.1, we changed this to 63KB. Most people _thought_ the default was always 63KB. It wasn't. So, now, in 5.1, restore _also_ defaults to thinking the tape record size is 63KB. We figured people would get bitten by this change, so we added the error message (which is obviously not effective) RESTORE: Tape Block size should be x, not y. So, if you run your restore as: restore tvfb rst0l 10 you'll be happy with the results. Now, how do I know the error message didn't work? 1) It prints out the tape record sizes in bytes, rather than 1KB blocks. That's fine, except that the command line wants the numbers in 1KB blocks. This will be changed for the next release. I apologize for this. Anyway, in your second test, restore is saying it can't grab 64512*1024 bytes. This isn't particularly surprising. Since most people don't use a 64MB tape record size, restore can't really hande that. Again, this is our fault for printing out the wrong increment. 2) You seem to have chosen to use the number that restore said was a bad record size (i.e. 63KB). We need to make sure people try to use the 10KB. We'll try to re-examine how to make that part of the message clearer as soon as we can. In summary, dump/restore should be both _forward_ and _backward_ compatible, as well as ufsrestore compatible. If this ever changes, we will make sure everybody knows this. Thanks for your patience, Stephen Manley FS Recovery Tenor

1 0

Re: 5.x Restore cannot read 4.x dumps
by Fred Ab 18 Dec '98

18 Dec '98

---} We now have a VERY strong suspicion that tapes written with 4.x cannot be read ---}with 5.1.2P1. I have a F220 running 4.3.3 and a F540 running 5.0.1. I just wrote a tape on the F220 using dump on a local attached DLT-4000 using compression. I then took the tape out and put it in a DLT-7000 that is locally attached to the F540. I had no problem doing a listing of the tape: america> mt -f nrst1a rewind america> restore tvf nrst1a Verify tape and initialize maps Tape block size is 63 Dump date: Fri Dec 11 23:52:14 CST 1998 Dumped from: the epoch Level 0 dump of /etc on mach5svr:snapshot_for_dump.116 Label: none Extract directories from tape Initialize symbol table. dir 2 . leaf 1106080 ./messages leaf 100277 ./rc dir 100263 ./crash I then went to a Sun Solaris 2.6 node and did a remote restore of a single file from the same tape. Therefore, it isn't true that "5.x Restore cannot read 4.x dumps" however there still might be a problem with 5.1.2P1 reading the 4.x version. I am very interested in the resolution of your problem because I plan on upgrading the 4.3.3 to one of the newer 5.x releases next week. One that is "Y2K Compatible" and I'm wondering now if I'll see the same problem. Fred. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Fred Abounader Vantis (AMD's PLD Subsidiary) ~ ~ email: fred.abounader(a)vantis.com Mailstop 546 ~ ~ voice: (512)-602-1644 5300 E. Ben White Blvd. ~ ~ FAX: (512)-602-4148 Austin, TX 78741 ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: ClearCase VOBs on NetApp
by Scott Miller 18 Dec '98

18 Dec '98

On Dec 18, 9:50am, Nick Thompson wrote: > Subject: ClearCase VOBs on NetApp > I have been speaking to engineers at Network Applications who assured me you mean Network Appliance, right? > that it is possible to create the WHOLE of a ClearCase VOB (including > the db) on a NetApp filer (and any other NFS filer for that matter). > Since Rational told me this was not possible, I got curious and tried it > anyway. It worked! Has anybody else here tried this configuration? Had > any problems? Not the VOB itself. Text pools, DO pools, etc work great on a NetApp, but the VOB (I always thought) needed to be on disk that was physicially local to the VOB server. take a look at http://www.netapp.com/technology/level3/atria.html for NetApp's version of how to use their filers with Atria. > According to the ClearCase docs, if you can snapshot a complete VOB (as > on a Toaster) then it is not necessary to lock it prior to backup You still want to lock the VOB, take the snapshot, then unlock the VOB before the backup. Since a VOB is a database, if you don't lock it you might get an inconsistant copy of the VOB in the snapshot. > (though some disk may be lost to empty containers if you restore from > it). Anybody tried/trust this or would you advise against it? Our backups work kind of like this. We lock all the VOBS, make a snapshot using Veritas FileSysteM snapshots, unlock the VOB, then backup the snapshot. Same concept, same benefits: backup doesn't lock the VOB for very long, which means developers aren't impacted. -Skottie -- ----- Scott Miller | Walt Disney Feature Animation skottie(a)fa.disney.com | Digital Studio Technology

1 0

Re: Routing Anomaly..
by Keith Brown 18 Dec '98

18 Dec '98

> >Im assuming that the default route on the filer is being used to send out >traffic destined for 151.142.223.0/24. Not on a good day it won't! :-) The filer's networking code should be more than sharp enough to see that it has an interface directly connected to your 151.142.223.0 network and route packets targeted to this network to said interface accordingly. In fact, a "netstat -r" on the console should show you an explicit zero-metric route for each network, directing traffic to the interface on which that network is to be found (look for gateway targets that look like "link#1", "link#2" in the "Gateway" column). >What should I do to make the e1a interface active to the 151.142.223.0/24 >network? I read your e-mail twice and can't spot a configuration mistake. Everything looked fine in fact. Is it possible that there is a more fundamental problem? A bad cable connecting the filer to the switch? A VLAN configuration within the switch that is preventing the filer's port from communicating with the Sun ports? A complete examination of the routing tables on filer, Suns and Cisco might reveal something peculiar. As an act of desperation, bringing the filer up without the FDDI interface configured (such that it is no more than a single Ethernet interface system connected via a switch to three other single Ethernet interface systems) might also be an experiment worthy of a shot. Keith

2 2

5.x Restore cannot read 4.x dumps
by grdodson＠lexmark.com 18 Dec '98

18 Dec '98

Anyone having problems restoring their dump tapes? We pulled a couple of old archive tapes (6 mo. old level 0 dumps) to restore some files and were unable to read them. Kept getting buffer size or buffer allocation errors. Placed a call to Tech. Sup. waiting for a callback (and waiting, and waiting, and waiting...). While waiting we tried some experiments. The tapes were written on an F330 running 4.x NFS & CIFS enabled (so we cannot use a sun to restore them). We discovered that we could read recent tapes written by either an F630 or F330 on a F630 running 5.1.2P1 with NFS & CIFS. I strongly suspect that a filer running 5.1.2P1 cannot read tapes written with 4.x. This has a less than pleasant affect on our backup & archive strategy. Can anyone confirm this? Thanks. Graydon Dodson grdodson(a)lexmark.com Lexmark International Inc.

3 2

ClearCase VOBs on NetApp
by Nick Thompson 18 Dec '98

18 Dec '98

Hi, We are just starting to deploy ClearCase... I have been speaking to engineers at Network Applications who assured me that it is possible to create the WHOLE of a ClearCase VOB (including the db) on a NetApp filer (and any other NFS filer for that matter). Since Rational told me this was not possible, I got curious and tried it anyway. It worked! Has anybody else here tried this configuration? Had any problems? According to the ClearCase docs, if you can snapshot a complete VOB (as on a Toaster) then it is not necessary to lock it prior to backup (though some disk may be lost to empty containers if you restore from it). Anybody tried/trust this or would you advise against it? Potentially this could make our backup scheme MUCH simpler. Thanks, -- _ _______ __ __ Nick Thompson | Lucent Technologies / \/ / / __\/ // /\ Lucent Technologies | (Bell Labs Innovations) / / / /__/ _ / / Microelectronics House | nickthompson(a)lucent.com /_/\_/_/____/_/\\_\/ Kings Ride, Ascot | Tel: +44 1344 865951 \_\/\\_\____\_\/ \_\ Berkshire SL5 8AD | Fax: +44 1344 865959

1 0

Routing Anomaly..
by Jeff Mohler 17 Dec '98

17 Dec '98

I have a newbie question about my 760. I have a FDDI interface, and a quad Ethernet interface. FDDI Interface is 10.16.2.25/24 with a default route on the box to 10.16.2.1 e1a Interface is 151.142.223.30/24 plugged into a 10/100 switch, the switch holds three Sun servers on the same network, and a Cisco router at .1. Problem is, that I cannot ping any 151.142.223 address from the Filer, and the Sun servers also cannot ping the Filer. Im assuming that the default route on the filer is being used to send out traffic destined for 151.142.223.0/24. I have routed off in the filer config. What should I do to make the e1a interface active to the 151.142.223.0/24 network? Thanks in advance.

1 0

Re: NT and UID
by Mark Muhlestein 14 Dec '98

14 Dec '98

Good point. And in that case you should definitely keep the UIDs consistent. Mark -----Original Message----- From: Allison, Bridget <bridget.allison(a)netapp.com> To: Muhlestein, Mark <mmm(a)netapp.com>; Patrick.Day.B(a)bayer.com <Patrick.Day.B(a)bayer.com> Cc: toasters(a)mathworks.com <toasters(a)mathworks.com> Date: Monday, December 14, 1998 10:00 AM Subject: RE: NT and UID >>If you are only using NT clients it doesn't matter too much what you use >>for UIDs. > >... unless you're using user level quotas when you still need a unique >UID for each user, right? I think Patrick is only using SSAM because >he's using quotas. >

1 0

RE: NT and UID
by Allison, Bridget 14 Dec '98

14 Dec '98

>If you are only using NT clients it doesn't matter too much what you use >for UIDs. ... unless you're using user level quotas when you still need a unique UID for each user, right? I think Patrick is only using SSAM because he's using quotas.

1 0

Re: NT and UID
by Mark Muhlestein 14 Dec '98

14 Dec '98

If you are only using NT clients it doesn't matter too much what you use for UIDs. If you want, you can just map all NT users to the same UID, since the files will all have NT security and what matters is the ACL. However, if you do have UNIX users accessing the data you will want to have a consistent mapping for the UIDs. I agree that is how SSAM should work. We'll look into fixing it. Mark -----Original Message----- From: Patrick.Day.B(a)bayer.com <Patrick.Day.B(a)bayer.com> To: - (052)toasters(a)mathworks.com <toasters(a)mathworks.com> Date: Monday, December 14, 1998 8:54 AM Subject: NT and UID >I have a question about the use of UID entries in the passwd and group files in >regards to an NT environment. We are installing a NetFiler 740 with Ontap >5.1.2 and only use NTFS (no mixed or NFS) permissions. We also have enable >quotas. I am using the Secure Share AccountMigrator to pull in and merge two >separate NT domains. The SSAM arbitrarily/sequentially assigns UID's on the >initial merge. However, i was wanting to use the SSAM as an accont update >utility as well. When we make changes to the account database on a daily >basis, we can simply merge and save using the SSAM. When i have experimented, >i found that a user's UID may change from update to update. I can't find >anything wrong with this, but wanted to know if anyone else is doing the same >and whether or not they have encountered any problems. > >Thanx! >W. Patrick Day >System Adminstrator >Bayer Corporation >Clayton, NC >

1 0

NT and UID
by Patrick.Day.B＠bayer.com 14 Dec '98

14 Dec '98

I have a question about the use of UID entries in the passwd and group files in regards to an NT environment. We are installing a NetFiler 740 with Ontap 5.1.2 and only use NTFS (no mixed or NFS) permissions. We also have enable quotas. I am using the Secure Share AccountMigrator to pull in and merge two separate NT domains. The SSAM arbitrarily/sequentially assigns UID's on the initial merge. However, i was wanting to use the SSAM as an accont update utility as well. When we make changes to the account database on a daily basis, we can simply merge and save using the SSAM. When i have experimented, i found that a user's UID may change from update to update. I can't find anything wrong with this, but wanted to know if anyone else is doing the same and whether or not they have encountered any problems. Thanx! W. Patrick Day System Adminstrator Bayer Corporation Clayton, NC

1 0

None
by Michael Massee 11 Dec '98

11 Dec '98

1 0

Re: Proposed List - Cache Toasters
by jrg＠acm.org 08 Dec '98

08 Dec '98

On Tue 8 Dec, 1998, mds(a)ns.gbnet.net (Mark D Simmons) wrote: >A very worthy idea! However, one that's already been addressed: > >netcache-users(a)gbnet.net indeed, usual stuff - email netcache-users-request(a)gbnet.net with 'subscribe' in the message body to join (it's run using Majordomo). There's also a rudimentary archive at <URL:http://www.gbnet.net/lists/netcache-users/> James.

1 0

Re: Proposed List - Cache Toasters
by mds＠ns.gbnet.net 08 Dec '98

08 Dec '98

A very worthy idea! However, one that's already been addressed: netcache-users(a)gbnet.net netcache-users Discussion list for NetCache users I'm sure the administrator of the list will be along shortly to explain how to join it and what it's all about. It's been running for a while and receives the patronage of Peter Danzig no less! *drumroll fades*

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