toasters

toasters@lists.teaparty.net

1 participants
13518 discussions

Re: quotas to track disk usage
by sirbruce＠ix.netcom.com 06 Sep '97

06 Sep '97

On 09/05/97 23:58:50 you wrote: >> A "quota convert qtree" command would be great, even if it took >> hours to accomplish for a large directory structure. > > Can't you create the quota tree, and then use something like tar >to copy/delete files into the quota tree while preserving the >directory structure? As discussed earlier, you'd want to use something like cpio, but yes. The point is that could take a long time for 10s or 100s of Gigabytes of data, wheras the filer itself could theoretically do the process faster (it doesn't have to copy files; just set the appropriate tree id). Bruce

1 0

Re: quotas to track disk usage
by sirbruce＠ix.netcom.com 06 Sep '97

06 Sep '97

On 09/05/97 02:55:47 you wrote: > >>> - Quotas trees are not usable because you can't mv files from one >>> quota tree to another (according to the docs). > >> The docs are slightly misleading here... sure, you can mv files from >> one to another, but they get copied, not moved. This should not >> generally be a problem (it's just like a separate mount point). > >Could someone from NetApp provide more detail here? I'm sure you can >move from one point to another over NFS, but if you are working from >/, you can't do an NFS rename call from one tree to another? What >happens when you try to use mv? Yeah, I'm not sure what would happen if you mount / and try to do the move from one tree to another. But if you mount them separately it won't make any difference (you probably do that anyway, since you want to confine the quota to just /home and not the whole filer). The mv command just does a copy instead. >What can't you do from a NFS/SMB client point of view? Again, I'm not sure what would happen with the root share, but between shares it will just copy (and then delete if you actually specified a move). >> 1. You have to create the quota tree first... if you already have a >> /home and directories in it, you can't "convert" them into a quota >> tree. You have to start with a new directory from scratch, crated >> via the "quota qtree newhome" or something similar. > >Ugh. If we get another filer, sure, but doesn't do much good for me >now. Yep. I complained bitterly about this years ago when a filer was set up the wrong way without a quota tree. You couldn't fix it after the fact. IMHO this is a big problem, as most admins won't understand quota trees when they first start using the filer, and once they do, it's too late to change. A "quota convert qtree" command would be great, even if it took hours to accomplish for a large directory structure. >> What Netapp really needs to do is a default quota report by uid/gid >> type of command on the filer, to avoid the need to set up quotas to >> track usage. > >Agreed. It looks like I'm stuck using "du" for now. Well, don't take me as definitive... maybe someone else has an idea. Bruce

2 1

Nice hidden command: mv
by Daniel Quinlan 06 Sep '97

06 Sep '97

(I'm assuming this mailing list is still active.) As an ice-breaker (teaser?), I thought I would share a useful hidden command that is present in NetApp Release 4.1d (and probably most others). It isn't listed in any online help (well, that's almost true) or documented anywhere, but you can use it anytime on the console. Note: I found this command on my own (i.e., it was not disclosed to me by NetApp). hostname> help mv rename files hostname> mv usage: mv file1 file2 hostname> mv /test1 /test2 I'd like to see more information and discussion on this mailing list: - problems you have experienced - any diagnostic utilities - undocumented commands - backup systems, experiences, etc. - Your experiences with other vendors (Auspex, Falcon, etc.) (positive or negative) - experiences with different NetApp models - using NetApps in growing or rapidly changing environments (for example, problems with having to move trees of data around often) - using more than a few NetApps - using one NetApp from multiple buildings (switching, routing, etc.) - performance tips, techniques, advice - and so on... I'll be making more postings in the not-too-distant future. Hopefully, things will pick-up a bit. Dan -- Daniel Quinlan (at work) Linux, our last best hope for Unix quinlan(a)transmeta.com http://www.pathname.com/~quinlan/ ... (Got BOFH? Looking for good ones.)

7 6

Re: Nice hidden command: mv
by guy＠netapp.com 06 Sep '97

06 Sep '97

> In many cases they aren't "safe" to use, and > you can be sure they certainly don't go through the usual QA cycle. Yup. If it's not documented, it's not supported, even though it might be useful. (I've filed a bug saying that our whole collection of undocumented commands needs cleaning up. Note that "cleaning up" in many cases may mean "removing from the system" - a whole *pile* of commands are there solely to provoke the system to do things for testing purposes inside development, for example. In some other cases, it may mean, making information available to support people, and maybe to end-users, but not necessarily committing to keeping the interface the same henceforth and forever more, world without end, amen. In other cases, it may mean leaving the command around for now, but not documenting it, because changes to the system in the future may obviate the need for it, at which point we'll remove it.) > Now, I'm not saying mv is dangerous (I don't know the code), but I > would not be surprised if it didn't fail to lock certain buffers > properly in multiuser operation, or not update the filesystem > correctly for CIFS attributes, or any number of other problems. Actually, "mv" happens to be Pretty Damn Simple - it does a pile of standard WAFL operations to look up the containing directories and then the standard WAFL rename operation (and uses an internal-to-Data-ONTAP(R)(TM)(LSMFT) routine to do it, so it's about 12 lines of code - counting blank linkes and curly braces), so it shouldn't, in theory, cause those problems (and won't do any better at moving stuff out of a snapshot than would a "mv" command on a UNIX box or a "ren" command on a DOS/Windows box; moving stuff out of a snapshot isn't exactly trivial), but... > I wouldn't want to risk the possibility of corruption and/or a crash > unless it was an "approved" Netapp command. ...that's definitely the case; undocumented means unsupported and, quite likely, untested, and also means "not guaranteed to stick around forever".

3 2

NetApp and FDDI
by Alexei Rodriguez 06 Sep '97

06 Sep '97

Anybody else out ther using FDDI for their NetApp and using Sun's as clients? We have been seeing some odd behavior at times. Looking through the logs on the clients, we have "NFS server not responding" errors (for 0 sec duration) across all the clients. Those that beat more heavily on the NetApp (like one box that constitutes 70% of the traffic) has these every few minutes. We have also had the NetApp stop serving NFS over the FDDI interface. Taking the interface down and bringing it back up has solved the problem. But what is the root of this problem? Bad NIC? Any suggestions? Thanks. Alex

6 7

alternate drives, RAM for NetApp 630
by Wayne D. Correia 06 Sep '97

06 Sep '97

Hi, What's the current supported 9GB drive revision that works in the NetApp 630? Also, can someone confirm if the DEC Storageworks shelf model SWXSS-22 shelf works in a NetApp 630? That's the Storageworks shelf that DEC recommends for their 9GB drives that are actually Seagate ST-19171-W's. I just can not justify paying NetApp $3000 for a $1200 hard disk or $10,000 for 256MB of DRAM when it should cost no more than $1500. As far as testing does, I really doubt that NetApp can possibly perform any level of pre-sale burn-in testing to justify more than 400% markup on RAM, more than 200% markup on hard disks, and more than 300% markup on an empty DEC Storageworks shelf.

2 1

Re: quotas to track disk usage
by sirbruce＠ix.netcom.com 05 Sep '97

05 Sep '97

On 09/05/97 01:40:58 you wrote: > >Given these parameters: > > - I would like to use quotas to track user disk space usage (but not > limit it) Easily done, but there are some caveats. > - Quotas trees are not usable because you can't mv files from one > quota tree to another (according to the docs). The docs are slightly misleading here... sure, you can mv files from one to another, but they get copied, not moved. This should not generally be a problem (it's just like a separate mount point). > - I only want to track usage in /home/* only, not the entire disk > (since there are other areas on the filesystem that users use, but > I do not want included in the quota report. This can be done with the new 4.1 software. >Is this possible or are the docs wrong about #2 ? Take a look at the na_quota(1) man page and they provide just such an example of restricting user quotas per export. However, there are some caveats: 1. You have to create the quota tree first... if you already have a /home and directories in it, you can't "convert" them into a quota tree. You have to start with a new directory from scratch, crated via the "quota qtree newhome" or something similar. 2. Some clients can't deal with quotas great thatn 8GB, and there is currently no option on the filer to limit this (this is filed as a bug), so you'd have to restrict your users to 8GB. If you have any over that, you don't want them in the quota system. So, you'd want something like: # Quota Target type disk files # ------------- ----- ---- ----- /newhome tree * user@newhome 8G The first line might not even be necessary, but it's worth including just for reference. Hmm, unless it breaks the clients the same way. Maybe the 8G can be omitted from the user entry as well? I don't know, I haven't tried it. The line might also be ncessary for the file to be parsed properly. What Netapp really needs to do is a default quota report by uid/gid type of command on the filer, to avoid the need to set up quotas to track usage. Bruce

3 2

Re: drive enclosure options
by sirbruce＠ix.netcom.com 05 Sep '97

05 Sep '97

On 09/05/97 09:07:08 you wrote: > >We have a F220 and our first drive enclosure is the standard Digital >Storage Works one provided by NetApp. We are considering making our >second enclosure be an Adjile Systems Lynx enclosure, since we have had >good experience with them in other systems. > >We are wondering if there are any incompatibilities between the Lynx and >the F220. I know when a drive is "raid fail"ed with the DSW enclosure >that the lights indicate the drive is spun down and ready for removal. The >Lynx does not provide that kind of lighting, but it is designed for hot >swapping. I don't think any other enclosures are allowed except on a PVR and unsupported basis. I'm surprised if Netapp is changing this, as even different Storage Works enclosures have demonstrated problems with each-other, let alone other enclosures. Bruce

1 0

NIC card for NetApp?
by Wayne D. Correia 05 Sep '97

05 Sep '97

Hi, Are any of the NetApp 630 accessories like hard disks, disk shelves, NIC cards, and RAM for the NetApp available via any other source than NetApp? Their prices for the add-ins are quite high and I am trying to plan out a system purchase now. Quick responses really appreciated. :-) -w Wayne D. Correia 1-415-826-6000

5 4

Re: Clarification
by sthaug＠nethelp.no 05 Sep '97

05 Sep '97

> > In my specific circumstance (lots of small files grouped in large > > quantities in single directories), I am unhappy with the performance of > > the F540 that I have. NetApp tech support and I have been working on the > > issue for almost 3 months now, and resolution may be in sight. ... > But this application sounds disturbingly similar to Internet news...and > the NetApp's tend to excel in that! > > We noticed a 300% performance increase versus a Sun StorageArray, for > example. We use an F330 for News, and are very happy with the performance and stability. That being said, our NetApp/Ultrasparc system still isn't very happy with 200.000 (or more) files in control.cancel, and we also see the occasional "not responding still trying" during renumbering (i.e. readings lots of directory entries, including some moderately large ones. (We no longer have the problem with control.cancel after we started deleting the cancel messages every few hours. The renumber problem is still with us, but isn't *enough* of a problem to worry about.) My conclusion is that a NetApp works much better than the traditional Unix file system for lots of small files - but there are limits even to what a NetApp will take of file system "abuse". The obvious long term solution for News is a few large files for the article store, like Diablo does it - and like Scott Fritchie's mods to INN. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

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