toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

ndmpcopy slower than tar, huh?
by Lisa Malgeri 19 May '99

19 May '99

Hello, I am moving 20 GB of data from a 220 to a 330. A support engineer at Network Appliance suggested using ndmpcopy. I acquired this software and compiled it on a Solaris 2.5.1 machine and am now testing. I have a 190 MB directory that I copied from the 220 to the 330 in 9 minutes using GNU tar over the public 10mbs network. I then tried to copy the same data using ndmpcopy. It took 1 hour 6 minutes! I set up a direct ethernet connection between the two filers running at 100mbs full duplex. From a Solaris 2.6 workstation on the public network I kicked off the ndmpcopy. nac220 is the 220, nac330 is the 330 and nac330-bak is the private 100mb network connection between the two. Here is my command: ndmpcopy nac220:/vol/vol0/testdir nac330:/vol/vol0/testdir -sa root:pass -da root:pass -d nac330-bak One other piece of info--the 220 is used to store Netnews data. When I am testing I have not turned news off, so the data is continually changing. When I do the actual transfer news will be turned off. But I can't turn it off for my testing. 1. Is my ndmpcopy command correct? 2. Is it abysmally slow because the news is still up? Thanks for any help. Lisa Malgeri

1 0

None
by Kinney, Roger 19 May '99

19 May '99

unsubscribe toasters roger.kinney(a)netapp.com

1 0

None
by dtm＠blue.hex.net 19 May '99

19 May '99

unsubscribe toasters dtm(a)hex.net

1 0

Re: Network Appliance makes the news...
by Andrew Hobson 18 May '99

18 May '99

On Mon, 17 May 1999 20:48:23 -0400, Jay Soffian <jay(a)cimedia.com> said: > Maybe we're just not a big enough NetApp customer. We have an F540, > and F630 and an F740. None of them have ever given us the least bit > of trouble. We do have a goodly number of Netapps, but I suspect we have a different mix of NFS ops. Maybe our bugs are in a different part of the code. :-) Of course, I'm more Netapps means more hardware, and more opportunity for foulups, but we've received cards that were bent so badly we couldn't put them in. The box didn't appear damaged at all. Drew

2 1

Re: Network Appliance makes the news...
by Jim McCoy 18 May '99

18 May '99

sirbruce(a)ix.netcom.com writes: >As to what happened, the most *likely* scenario for any signficant >downtime of the Netapp is double disk failure. That is, one disk >failed, and during reconstruction they lost another. I beg to differ. YahooMail has had significant problems with all sorts of unpleasant little bugs which has led to downtime for the system and in two cases actual data loss. Since the beginning of this year we have apparently run into every possible failure mode of these systems, except for a dual disk failure, and I can assure you that there are all sorts of reasons that an event like this could occur. Reading the tea leaves on this one I would guess that they also run into bug 1549 and were forced to run a wack on a filer (props to John E. for the fast wack, if it were not for that single improvement I can assure everyone at NetApp reading this that Yahoo would be using EMC boxes right now...) >If they were running a cluster, most likely there would have been >no interruption in service. You get what you pay for. I'm sure >their Apache (or whatever) web servers have crashed more than their >filers have. How I wish we would get what we paid for... We run a hacked version of Apache and have probably had a total of 30 minutes of system downtime due to this Apache problems this year (mostly due to a memory leak I think that we introduced into our version.) Contrast that with a total of 36 hours of system downtime since January due to filer failures. If NetApp expects us to pay twice as much per MB of storage and run a cluster then they are going to start getting into the realm where an EMC box begins to look like a better deal, and when it comes to system reliability NetApp still has a long way to go to reach the sort of reputation that EMC has in the industry. NetApp had a very serious problem with quality control on hardware and QA within the engineering department was so useless as to be non-existent. We have been given assurances that this specific problem as been recognized and is being addressed. Only time will tell. >There doesn't seem to be much of a story here. But there is a story here, and one which needs to be addressed. NetApp charges a large premium over the raw costs of the disks and hardware to hook them together compared to what I could rig up with a PC and a few raid controllers, as a customer I would like to know that I am getting some value for this addtional cost. When that "value-add" proves to be a mirage I think that I have a justifiable reason to be pissed off. Critical Path was just the first customer to admit that NetApp was the source of the downtime, the prompt attention we have received from NetApp (even when there was nothing they could do) is the only thing which prevented Yahoo from being the first one to attribute responsibility for system downtime to NetApp in a press release. jim mccoy Yahoo! Inc.

5 4

Re: Network Appliance makes the news...
by Tripp Cox 18 May '99

18 May '99

On 17 May 1999 20:54:25 -0400, Andrew Hobson wrote: >Of course, I'm more Netapps means more hardware, and more opportunity >for foulups, but we've received cards that were bent so badly we >couldn't put them in. The box didn't appear damaged at all. I recall several instances of buggy hardware and sloppy hardware QA dating back to early-mid 1997. I'd like to think things have improved since then. We had to replace all of our SCSI controllers in a slew of F540s, we had bad EMUs in a couple of F630s, and a heck of a time with the short-lived EFBs of the F520s. Not to mention a plethora of bad disks (new equipment) and shelf pairs bent beyond any utility. I also recall having to reseat a small microchip within the casing of an EFB. Of course, Jan and I managed to hose Netapp's lab equipment so bad on one trip to San Jose that a stream of curious engineers visiting the sick equipment couldn't recover it before the day was over. Maybe we're not the best test case. :) Of course the point to all of this being that it generated a great deal of service downtime that we never should have had to endure. Tripp

1 0

Re: Network Appliance makes the news...
by Andrew Hobson 18 May '99

18 May '99

On Mon, 17 May 1999 12:50:58 -0700, "Jim McCoy" <mccoy(a)yahoo-inc.com> said: > sirbruce(a)ix.netcom.com writes: >> As to what happened, the most *likely* scenario for any signficant >> downtime of the Netapp is double disk failure. That is, one disk >> failed, and during reconstruction they lost another. > I beg to differ. I just about to write this exact same email. We've had the same experiences with filer failers and quality control. We're having the same thoughts about the cost when you want non-stop computing. Netapp is great for the 98% uptime market. They aren't ready to play in the 99.99% uptime market, at least in my view. I used to be a Netapp enthusiast, but no longer. I'd sleep better if our customers' email was moved off of filers. Drew "Speaking from experience, but not speaking as a representative of MindSpring" Hobson -- "He's a love machine, sir." -- Waylon Smithers

2 2

Re: Network Appliance makes the news...
by Jeff Newton 18 May '99

18 May '99

Ok, I'll bite. What is a "wack"? Cheers, > In the immortal words of Jim McCoy (mccoy(a)yahoo-inc.com): > > > Reading the tea leaves on this one I would > > guess that they also run into bug 1549 and were forced to run a wack on a > > filer (props to John E. for the fast wack, if it were not for that single > > improvement I can assure everyone at NetApp reading this that Yahoo would be > > using EMC boxes right now...) > > Out of morbid curiosity, which is bug 1549? I have had to run wack > in recent memory, and it was a...sobering experience. > > -n > > ------------------------------------------------------<memory(a)blank.or g> > I've got more than one membership / to more than one club > and I owe my life / to the people that I love. (--Ani DiFranco) > <http://www.blank.org/memory/>---------------------------------------- -- ---- Jeff Newton Unix Systems Administrator PMC-Sierra Inc.

2 1

32-bit uptime counter?
by Brian Tao 17 May '99

17 May '99

Still running good ol' 4.2a on an F230: Sun Apr 18 21:00:00 EDT [statd]: 9:00pm up 497 days, 1:10 407777519 NFS ops, 0 CIFS ops, 0 HTTP ops Sun Apr 18 22:00:00 EDT [statd]: 10:00pm up 497 days, 2:10 408458997 NFS ops, 0 CIFS ops, 0 HTTP ops Sun Apr 18 23:00:00 EDT [statd]: 11:00pm up 42 mins, 409036765 NFS ops, 0 CIFS ops, 0 HTTP ops Mon Apr 19 00:00:00 EDT [statd]: 12:00am up 1:42 409494263 NFS ops, 0 CIFS ops, 0 HTTP ops This looks like 2^32 ticks elapsed (about 42949673 seconds)... is this one of the counters being increased to 64 bits? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

2 1

Re: Running CIFS
by sirbruce＠ix.netcom.com 17 May '99

17 May '99

On 05/05/99 15:53:45 you wrote: > >In message <7F608EC0BDE6D111B53A00805FA7F7DA03A83938(a)TAHOE.netapp.com>, "Muh >lestein, Mark" writes: >>A mixed qtree already works exactly as you want it to. In a mixed qtree the >>security of a file is based on the last security-setting operation. If an A >>CL is >>set which denies you access, but you still need to do something with a file, >>then as root you can change the security on any files/dirs in that qtree (using >>chmod, chown, or chgrp), which changes the security-style to UNIX. After that, > > Ok, so far I've read this alot. No maybe I'm missing something > 'cause I get the following errors trying to put it into practice. What errors? These are exactly correct. > Here's a test on a directory w/ NTFS permissions allowing only full > control to the owner: In other words, you've told NTFS that Administrator can't read the directory or change permissions. All Administrator can do is assume ownership. >root@jagular: fs0/home/kelleher [130] # >root@jagular: fs0/home/kelleher [130] # ls -ald test_dir >drwx------ 2 kelleher users 4096 May 5 14:47 test_dir >root@jagular: fs0/home/kelleher [131] # >root@jagular: fs0/home/kelleher [131] # ls -al test_dir >test_dir: Permission denied >total 8 This is correct; root on UNIX will map as Administrator in the NT realm, so it can't read the directory. >root@jagular: fs0/home/kelleher [132] # >root@jagular: fs0/home/kelleher [132] # chown 755 test_dir >chown: test_dir: Not owner Firstly, you should have done chmod, not chown. Secondly, this would be correct... Administrator (root) does not have permission to change the file permissions. >root@jagular: fs0/home/kelleher [133] # >root@jagular: fs0/home/kelleher [133] # chown root test_dir >chown: test_dir: Not owner >root@jagular: fs0/home/kelleher [134] # This should have suceeded, if I understand the model correctly. I'm not sure why it didn't; perhaps it's a bug? > I can however su to the UNIX user, chmod it, and then get access to > the file: > >root@jagular: fs0/home/kelleher [134] # su kelleher >jagular% >jagular% chmod 755 test_dir >jagular% >jagular% exit >jagular% root@jagular: fs0/home/kelleher [135] # >root@jagular: fs0/home/kelleher [135] # ls -al test_dir >total 72 >drwxr-xr-x 2 kelleher users 4096 May 5 14:47 . >drwxr-xr-x 25 kelleher users 32768 May 5 15:25 .. >-rwx------ 1 kelleher users 0 May 5 14:47 test_file >root@jagular: fs0/home/kelleher [136] # >root@jagular: fs0/home/kelleher [136] # > > Is this what you mean? This all makes sense. >>those files follow regular UNIX rules, which allows root full access. If the >>user wants to put an ACL back on afterwards, no problem. >> >>We have found that using ACLs in a mixed qtree can be helpful in a number of >>situations. That's because ACLs are enforced even for NT Admins and root. For >>example, we found that some files were being accidentally deleted by root/Admin >>users, so we put an ACL on those files which allows only READ access to all >>users. That prevents deleting, even by root or NT Admins. Of course, if we >>actually want to delete the files we just change the permissions to allow that, >>since in a mixed qtree both root and NT Admins have a special dispensation >>tochange the permissions. > > Sounds like the problem is too many people with root/Admin access. > Your solution only requires these people to take an extra step > (give themselves the permissions) before they accidentally mess > something up. If I were you I'd work on getting rid of their > access. (Not that it's an easy thing to do.) In my experience many people are unwilling to take this approach, for reasons I can't quite fathom. They would much rather let incompetent people continue to work for them and spend effort trying to keep them from shooting themselves in the foot rather than spending the time to make them competent and/or getting another employee. Bruce

2 1

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