toasters

toasters@lists.teaparty.net

13520 discussions

Re: Potential user has questions
by sirbruce＠ix.netcom.com 07 Nov '98

07 Nov '98

On 11/06/98 16:54:16 you wrote: > >Hi, we are considering going with one or more filers for our >free hosting service. I've got some basic questions that I >hope you all can help us out with. (I'll ask Netapp too whenever >they return my voice mail..) Most of these are already answered at least once, but what the hey, I'm bored. :) >Can you add drives to a file without shutting down? Yes. And grow the filesystem dynamically to include the new drive, while still in service. >How would you add shelves/adapters? Basically, you'd mount your new disk shelf in the rack, populate it with drives, shut down the filer, open the back of the cabinet, quickly slip in the adapter to the appropriate slot (if a new one is needed), close it back up, attach the cable from the shelf, and turn the filer back on. With a little practice the actual downtime of the filer for such an operation can be under 10 minutes. With the new FCAL, I don't know if you can add new shelves without shutting down or not. >Is the filer OS considered secure? I would consider it pretty secure. There's not much on it. You have the same risks of sniffing packets as you do with UNIX or NT from another machine, but breaking into the filer itself is unlikely. >Y2K compliant? Yes. >Would you feel safe running your filer attached to potentially >hostile web servers running user-uploaded CGI programs? As far as the filer is concerned, yes. As far as other servers on the network, less so. That is, the uploaded CGI could compromise security on your web server on your UNIX box that is talking to the filer over NFS, but I wouldn't worry about the filer itself being compromised. >Can we use third party drives/shelves/canisters/mem? You could in theory. They may or may not work at first. Even if they appear to work, they may or may not work later when you stress them or encounter an unusual SCSI condition. And you'll get minimal support for running a non-standard configuration. So why bother? You may save a few bucks by using the 18GB disk you got at Fry's and some cheap memory, but once it starts failing in the filer because it's not tested by Netapp, you'll wish you hadn't. If you really want to run something third-party, you may be able to make a special arrangement with Netapp. Talk to your salesperson. >Will 18GB and larger drives work ok? (Seagate just announced >36GB half-height drives...) As far as I know they aren't supported yet. When qualifying new drives, Netapp has to take into account not only the drive itself and if it can stand the load, but also the power concerns of the disk shelf. If the shelf can only handle half as many 18GB drives as 9GB drives, you haven't gained anything. >What kind of real-world bandwidth can it put out (F740) ? I >see the transaction specs, but what about sustained mbits >in a web-type environment (3x more reads than writes)? Raw bandwidth isn't a common measurement because rarely are you going to encounter the same mix of operations at each site. And it would depend on whether or not you're accessing the filer over CIFS or NFS, what version, how many drives you have, what kind of network, etc. Having said all that, I would say 40MB/sec or more is possible in a fully maxed out configuration. You mentioned used 100tx ethernet before. I would recommend using gigabit ethernet if you can, or going with multiple 100tx interfaces (full-duplex if you can). >If you use Cisco Fast EtherChannel, does it failover to the >lower bandwidth if you are using multiple network links ? >(assume a CF environment) ? I don't know anything about CFE or even if Netapp supports it. >If yes, and assuming you are using CF with two filers, wouldn't >that be a system with no single point of failure, or is there >anything else we should worry about? Within that system, there's no single point, but when you're talking about the overall service, you'll need to consider multiple sources of power, multiple networks and attached hardware, and so on. >Works with these systems over nfs: http(apache), news(inn and dnews), dns(bind), >mail(qmail), ftp(NcFTPd), Frontpage ? I don't know about Frontpage, but all the others do/should work fine. >Does the CF cost extra? (for the software.. I know it takes a >second filer :-) I think so. >Does Netapp charge for OS upgrades beyond a certain time period? This depends on the support contract. Again, I think so, but you'd need to get the details from your salesperson. Things may have changed. (Note that upgrades and fixes are probably free. Any release that provides major *new* features and functionality will probably cost you.) >Finally, do you feel there are any serious contenders to Netapp >that we should check out? Anyone tried the EMC Symmetrix stuff >or Artecon LnyxNSS systems? It's always good to shop around, but I suspect the other vendors will make a lot of promises they can't keep, or focus on one particular area to shoot down the Netapp (it's slow during reconstruction, for example) rather than address all the other advantages or the deficiencies in their own systems. That having been said, I think EMC and Sun are both worth a look. You may find that for your needs, you'd like to have UNIX available to you on the NFS server. I used to like Falcon, but I haven't heard anything from them lately. Bruce

1 0

Netapp OS networking code stability?
by Brian Atkins 07 Nov '98

07 Nov '98

Jim Davis wrote: > > > Would you feel safe running your filer attached to potentially > > hostile web servers running user-uploaded CGI programs? > > No. But that's a trick question, since user-uploaded CGI programs are > always going to potentially defeat any security system you might use. That's a rather pessimistic way of looking at it :-) What I am after is more like: if some script kiddies upload stuff that goes portscanning and otherwise mucking with the filer, is it going to wig out and die ? I mean people seem to find bugs in the networking code of NT every month- how stable is the filer's OS? Barring any misconfiguration or inherent bugs in the protocols (nfs), is it gonna be rock solid? Or are we gonna have to pamper it behind a firewall or something? -- The future has arrived; it's just not evenly distributed. -William Gibson ______________________________________________________________________ Visit Hypermart at http://www.hypermart.net for free business hosting!

2 1

Potential user has questions
by Brian Atkins 07 Nov '98

07 Nov '98

Hi, we are considering going with one or more filers for our free hosting service. I've got some basic questions that I hope you all can help us out with. (I'll ask Netapp too whenever they return my voice mail..) Can you add drives to a file without shutting down? How would you add shelves/adapters? Is the filer OS considered secure? Y2K compliant? Would you feel safe running your filer attached to potentially hostile web servers running user-uploaded CGI programs? Can we use third party drives/shelves/canisters/mem? Will 18GB and larger drives work ok? (Seagate just announced 36GB half-height drives...) What kind of real-world bandwidth can it put out (F740) ? I see the transaction specs, but what about sustained mbits in a web-type environment (3x more reads than writes)? If you use Cisco Fast EtherChannel, does it failover to the lower bandwidth if you are using multiple network links ? (assume a CF environment) ? If yes, and assuming you are using CF with two filers, wouldn't that be a system with no single point of failure, or is there anything else we should worry about? Works with these systems over nfs: http(apache), news(inn and dnews), dns(bind), mail(qmail), ftp(NcFTPd), Frontpage ? Does the CF cost extra? (for the software.. I know it takes a second filer :-) Does Netapp charge for OS upgrades beyond a certain time period? Finally, do you feel there are any serious contenders to Netapp that we should check out? Anyone tried the EMC Symmetrix stuff or Artecon LnyxNSS systems? Thanks -- The future has arrived; it's just not evenly distributed. -William Gibson ______________________________________________________________________ Visit Hypermart at http://www.hypermart.net for free business hosting!

4 3

Re: can't see ~snapshot directory
by Tom Reingold 06 Nov '98

06 Nov '98

On Fri, 06 Nov 1998 09:37:23 EST, Tom Limoncelli <tal(a)dnrc.bell-labs.com> wrote: > In fact, I wonder if the solution here is to turn off visible .snapshot > and ~snapshot at the mointpoints and put symbolic links in the user's > directory that are SNAPSHOT -> .snapshot. Or, if NetApp could have > these appear as symlinks/shortcuts that would solve the problem. That won't work. NT (and I presume win9[58]) won't let me make a shortcut to a non-existent thing, and it doesn't think .snapshot or It will work when it's a symlink, but you have to be on UNIX to create a symlink, and then I think you're back with the same problem, because fastfind will traverse it. It doesn't know symlinks are special. It thinks SNAPSHOT is a folder (directory). I just tested this.

2 1

None
by Nail, Larry 06 Nov '98

06 Nov '98

unsubscribe lnail(a)ti.com

1 0

Re: can't see ~snapshot directory
by sirbruce＠ix.netcom.com 06 Nov '98

06 Nov '98

On 11/06/98 13:26:41 you wrote: >|> As I pointed out before, simply mounting .snapshot as it's own filesystem >|> on the client will resolve this problem. > > No it won't. > > The .snapshot will still be there and will still suffer this problem >when someone uses it. I'm not sure I follow you. If they use it from the seperate mountpoint, there won't be a problem. If they try to refer to the .snapshot in their own directory, sure, they'll still have the problem, but 1. They wouldn't know to look there if you told them to get it from /snapshot (for example), and 2. If they went ahead and used it anyway, they'd know what they were doing. > And it would leave me with another issue - how to setup automount >maps to do the actual mounts in some consistent way. Well, simply don't use automounter. It's evil anyway. (This is a religious war, though, so let's not get into it on this list.) Bruce

1 0

Re: can't see ~snapshot directory
by sirbruce＠ix.netcom.com 06 Nov '98

06 Nov '98

On 11/06/98 11:50:43 you wrote: > Also, one thing that I would like to see changed (if it makes sense) >is for the NetApp servers to return different inodes for snapshot >entries (OR in teh snapshot number at the top-end?). The reason for >this is that some versions (egL GNU) of diff seem to check fs/inode >info, and if they find they are the same they don't bother to do any >diff'ing.... As I pointed out before, simply mounting .snapshot as it's own filesystem on the client will resolve this problem. Bruce

2 1

Re: SMTP MIB (was Re: raid scrubbing and hot spares)
by mds＠ns.gbnet.net 06 Nov '98

06 Nov '98

I have to say I found it easier (marginally) to use the basic MRTG distribution and copy-in the useful bits from the NOW package - largely because it'd been prepared and tailored a leetle too much in NetApp 8) I, for example, wanted/needed to run it all on an SGI box, and the precompiled SPARC binaries weren't very useful in this instance (read HP/IBM/Linux/etc. if more apt). I'll have to do the same thing over again when I get the latest MIB. I'd kill to get my hands on the proper SNMP tools where I work, as it is I have to work far too hard to work out what variables do what to get even basic info out of any MIB. But that's just a general complaint about SNMP on my part. 8) MRTG is useful, but it's also very limited. I want to do some graphs which tie together the main characteristics of filer (network use, CPU, NVRAM-cache-flushes, cache-age, NFS-ops, CIFS-ops) on the same graphs - try to do that with just two variables. (Yes some of those are desirable but not currently reported - to the observant who spotted my imagination running away with my fingers). I also wanted to be able to graph all the per-client stats. But the problem we found there was that the filer only kept a table of 256 such stats, or at least that's all the we could get through SNMP. Per-volume, per-client stats, now that'd be interesting. Per-volume stats would be interesting. Per-disk stats, would be interesting, if slightly un-immediately-useful. Exposing more of the error- and performance-reporting from the disks would be fascinating too. You could graph that data over time to see if there's a disk that's being hot-spotted for some reason, or which is throwing up more low-level, otherwise hidden errors, or which is responding in a below-par relative to its siblings. You could move data around or pre-emptively maintain problems with such information. As the number of clients and disk increase, getting these stats might make the difference between running a silky-smooth operation with the filer or having disks blow randomly in quick succession in just the most critical sections of the filer, serving the most demanding clients - without even knowing such a relationship pertained. That's my Xmas wishlist on the topic. I'll be praying Santa listens to this one though.

2 1

Re: SMTP MIB (was Re: raid scrubbing and hot spares)
by Elena Samsonova 06 Nov '98

06 Nov '98

Thompson, Tim wrote: > > > > The tools are at http://now.netapp.com/download/tools/filer-mrtg/ > > Yes, I know that, we use those tools and a lot more. > > What other tools do you find useful? (We're always interested > in finding out what people are using.) We wrote our own. We pull and parse the web interface pages of the NetCache Appliance, and I am currently writing one for parsing sysstat output from the filers (and perhaps NetCaches too). Regards Elena ---------------------------------------------------------------- Elena Samsonova e-mail: E.Samsonova(a)wxs.nl World Access / Planet Internet phone: +31 33 45 40 417 PO Box 2529, 3800 GB Amersfoort fax: +31 33 45 40 401 The Netherlands ----------------------------------------------------------------

1 0

Re: hard link .snapshot files
by mds＠ns.gbnet.net 06 Nov '98

06 Nov '98

Actually this issue - of wanting to bring files from a snapshot back into the current filesystem, without raising the occupancy of the disks any more - is something that has crossed my mind before. There are times, for example, when it'd be nice to just bring back a large directory-tree into current use from a snapshot, perhaps/probably toasting anything in the current filesystem image that would name-clash but not having to freshly copy the data into new free blocks on the filer - perhaps because you are close to filling the filer already. Now if it's the total contents of the filer in question then you could take the filer down and use the requisite admin commands (perhaps with the help of the NetApp support folk) to use an older snapshot as your current filesystem image. 'Rolling back to a named consistency point' would be something akin to the NetApp way of putting it. However, I've often thought it'd be darned useful to say: 'take everything from this directory down from that snapshot and graft it coherently into place in the current filesystem here, but leave everything else as it is currently'. This is probably a great deal to ask and couldn't be done with normal filesystem operations, CIFS/NFS notwithstanding. However, as an option available to an admin I think it would be stunningly useful to some folk. This would take some cunning WAFL wizardry to accomplish I think, but it's not beyond the bounds of credibility. > As I'm sure you've already discovered, you can't create a hard link to a > file in a snapshot. The reason is that snapshots are read-only, but it is > necessary to increment the number of links in the linked-to inode. You can > use a symbolic link, of course, but it would point to whatever was at that > location. To prevent the snapshot from being recycled, you could do a "snap > rename" of hourly.0 or whatever to something else. > > Mark > > -----Original Message----- > From: Jim Harm <harm1(a)llnl.gov> > To: toasters(a)mathworks.com <toasters(a)mathworks.com> > Date: Thursday, November 05, 1998 8:56 AM > Subject: hard link .snapshot files > > > >We have the need to occasionally recover a LARGE file and we would like to > >recover it quickly without making the massive increase in space usage that > >would result if we merely copied the file from .snapshot to the old > directory. > > > >Can we build a hard link from the old directory to the > >.snapshot/hourly.#/Large.file and how will that be protected with the next > >snapshot? > > > >I don't want to screw anything up. Our users ARE rocket scientists. > > > >}}}===============>> LLNL > >James E. Harm (Jim); jharm(a)llnl.gov > >(925) 422-4018 Page: 423-7705x57152 > > > > > > >

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