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
- 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?
What can't you do from a NFS/SMB client point of view?
- 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.
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.
- Dan
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?
Nope.
Quota trees are best thought of as "virtual partitions". (In fact, I think that's what Dave had in mind when he first put them in.) Attempts to move stuff into or out of them gets EXDEV, and, in sufficiently recent releases (I think I fixed this in 3.0 or 3.1 or so):
*IF* you've mounted the root of a quota tree from a client (because many clients, including Sun's, do not, on a "statfs()"/"statvfs()"/"ustat()"/etc. call, send a file handle for the argument to the call to the server, they send a file handle for the mount point), you get the space free in the quota tree (minimum of space left in the file system and in the quota);
if you exceed the quota, you get ENOSPC, not EDQUOT.
Unlike real partitions, you can increase or decrease the size relatively easily, by adjusting the quota ("relatively", given that adjusting quotas can be a pain).
What happens when you try to use mv?
"mv" tries a "rename()" (unless it's a crufty old version of UNIX, in which case it tries a "link()", with an "unlink()" to follow, but the results should be the same), gets an EXDEV error, and says "oops, they're on different file systems", copies the file to the destination, and removes the source.
What can't you do from a NFS/SMB client point of view?
Move files into or out of the quota tree.