Has anyone tried making /etc into a qtree? We'd like to do that and give it an infinite quota. That way the sum of our qtree usages will equal our df usage and we can track the size of /etc.
I wonder if this could be done on a production filer assuming nobody is accesing /etc:
adminhost% sudo rsh filer qtree create etc.new adminhost% sudo tarcp /etc /etc.new adminhost% sudo mv /etc /etc.old adminhost% sudo mv /etc.new /etc
Seems like this could hose up syslog and possibly CIFS since it tinkers with its files there. Any ideas? Anyone tried this before?
-- Jeff
-- ---------------------------------------------------------------------------- Jeff Krueger E-Mail: jeff@qualcomm.com NetApp File Server Lead Phone: 858-651-6709 IT Engineering and Support Fax: 858-651-6627 QUALCOMM, Incorporated Web: www.qualcomm.com
Jeff Krueger jkrueger@qualcomm.com writes:
Has anyone tried making /etc into a qtree? We'd like to do that and give it an infinite quota. That way the sum of our qtree usages will equal our df usage and we can track the size of /etc.
No-one seems to be screaming "don't do it!", but I wouldn't care to try it out first on a production filer...
What I do is to make everything *except* /etc a qtree. Not as convenient if you want to track /etc usage, admittedly, but that's rarely an issue for us.
Incidentally, it wouldn't be quite true that the sum of qtree usages would equal df usage. The blocks occupied by directories count against df usage but not against quotas.
I wonder if this could be done on a production filer assuming nobody is accesing /etc:
adminhost% sudo rsh filer qtree create etc.new adminhost% sudo tarcp /etc /etc.new adminhost% sudo mv /etc /etc.old adminhost% sudo mv /etc.new /etc
I do know that one can make an /etc.new *outside* a qtree, populate it appropriately, and then put it into service by renaming as above. Because it was outside a qtree, I could share some files between the two worlds by hard linking them, but of course this wouldn't be allowed across a qtree boundary.
Seems like this could hose up syslog and possibly CIFS since it tinkers with its files there. Any ideas? Anyone tried this before?
The filer "tinkers" with *lots* of files in /etc (that's probably why you want to track the usage in the first place, right?). A very partial list:
/etc/dumpdates & /etc/tmp/* when dumping /etc/db/quota_names at "quota" /etc/rmtab to record client NFS mount/umount /etc/sm/* as part of lockd/statd activity /etc/registry at "options" if options are changed /etc/log/httpd.log (even if HTTP is not enabled/licensed!) /etc/crash/* at "savecore" /etc/.avail written at every checkpoint? (not documented) ...
The real question is probably whether such files are written via interfaces that keep the quota database information up to date or not.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
how big can etc get anyways? mine's 30MB...
what's wrong with a du -k or du -ks?
-corris
On Sun, 18 Jun 2000, Chris Thompson wrote:
Date: Sun, 18 Jun 2000 14:07:28 +0100 (BST) From: Chris Thompson cet1@cus.cam.ac.uk To: jkrueger@qualcomm.com Cc: toasters@mathworks.com Subject: Re: Make /etc into a qtree?
Jeff Krueger jkrueger@qualcomm.com writes:
Has anyone tried making /etc into a qtree? We'd like to do that and give it an infinite quota. That way the sum of our qtree usages will equal our df usage and we can track the size of /etc.
No-one seems to be screaming "don't do it!", but I wouldn't care to try it out first on a production filer...
What I do is to make everything *except* /etc a qtree. Not as convenient if you want to track /etc usage, admittedly, but that's rarely an issue for us.
Incidentally, it wouldn't be quite true that the sum of qtree usages would equal df usage. The blocks occupied by directories count against df usage but not against quotas.
I wonder if this could be done on a production filer assuming nobody is accesing /etc:
adminhost% sudo rsh filer qtree create etc.new adminhost% sudo tarcp /etc /etc.new adminhost% sudo mv /etc /etc.old adminhost% sudo mv /etc.new /etc
I do know that one can make an /etc.new *outside* a qtree, populate it appropriately, and then put it into service by renaming as above. Because it was outside a qtree, I could share some files between the two worlds by hard linking them, but of course this wouldn't be allowed across a qtree boundary.
Seems like this could hose up syslog and possibly CIFS since it tinkers with its files there. Any ideas? Anyone tried this before?
The filer "tinkers" with *lots* of files in /etc (that's probably why you want to track the usage in the first place, right?). A very partial list:
/etc/dumpdates & /etc/tmp/* when dumping /etc/db/quota_names at "quota" /etc/rmtab to record client NFS mount/umount /etc/sm/* as part of lockd/statd activity /etc/registry at "options" if options are changed /etc/log/httpd.log (even if HTTP is not enabled/licensed!) /etc/crash/* at "savecore" /etc/.avail written at every checkpoint? (not documented) ...
The real question is probably whether such files are written via interfaces that keep the quota database information up to date or not.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
how big can etc get anyways? mine's 30MB...
My only caution would be to remind people that dump and restore create temporary files in the /etc/tmp directory when they run.
In the case of restore of a large backup, the temporary files can grow into the GBs.
You could make a rough estimate of about 256 bytes per file on tape during a full or single-file/subtree restore....
For the backup, estimate about 6 bytes per inode (by total inodes, not by allocated inode).
Stephen Manley Data Availability and Management Movie Reviewer
P.S. Go see Titan A.E. Not as good as Iron Giant, but better than the latest Star Wars...
On Mon, Jun 19, 2000 at 07:24:28AM -0700, Corris Randall wrote:
how big can etc get anyways? mine's 30MB...
when a filer crashes the core is copied under /etc. this could cause problems if you were to make /etc a qtree and put a quota on it. i would imagine the core could get copied over fine, but normal filer ops which normally write to /etc would start failing in strange ways.
-s
-
Chris Thompson -
Corris Randall -
Jeff Krueger -
Stephen Manley -
Steve Armijo