1. Monitor file system growth and control growing files
2. Manage file system disk space usage
3. Implement basic file system integrity checks
File systems expand uupon notice, NOT automatically
To keep from funning into problems:
–> Monitor file system growth
–> Determine causes
–> Control growing files
–> Manage file system space usage
–> Control user disk usage
–> Defragment file system
Note: Remember that once a file system is expanded it cannot be reduced in size.
Listing Free Disk Space:
The df command displays information about total space and available space on a file system.
df – display filesystem information
df (default – displays filesystem size in 512 byte blocks)
df -k (displays filesystem size in 1024 byte blocks)
If the %Used is close to or over 80% then you should investigate.
If the %Used is below 40% then it may be under utilized. In this case you could backup the data, and reconfigure the filespace smaller to be able to use that free disk space somewhere else.
Control Growing Files:
/var/adm/wtmp – Logs every time someone logs on (doesn’t roll the entries out)
/var/adm/sulog – Logs every time someone uses the su command
/var/spool/*/* – Every time you print a file it creates a file
$HOME/smit.log – Logs every time someone enter smit
$HOME/smit.script – Logs all commands executed in smit
/etc/security/failedlogin – Logs every time someone fails to logon, Could be hackers if growing quickly
Has a line in the scheduler
1. The skulker command cleans up file systems by removing unwanted or obsolete files
2. Candidate files include (can use file aging as criteria)
–> those in /tmp directory
–> a.out file
–> core files
–> ed.hup files
3. skulker is normally invoked daily by the cron command as part of the root’s crontab file
4. Modify the skulker shell script to suit local needs for the removal of files.
Listing Disk Usage:
The du command can be used to list the number of blocks used by a file or a directory.
# du /home | sort -r -n (-r reverse, -n numeric order)
To view individual file sizes, use the ls -l command
ls -l /home/fred
Considerations to be made
–> Disk space allocation
–> Disk space utilization
–> I/O activity
–> Free space fragmentation
–> Fragment allocation map
Defragmenting a File System:
The defragfs command increases a file system’s contiguous free space
The file system must be mounted
/usr/sbin/defragfs [-q | -r] filesystem
-q – Reports the current state of the file system and stands for query
-r – Reports the current state of the file system and the state that would result if the defragfs command is run without either -q or -r
Note: If you use the -q or -r option then defragfs won’t actually do any defragmentation.
Verify a File System:
fsck [-p | -y | -n][-f] [ filesystem ]
fsck – file system check command
-p – does a quick fix
-y – automatically fixes everything
-n – reports but doesn’t fix anything
-f – must specify the file system
Note: Make sure that you unmount the files system before doing the check.
–> Checks Journal Log
–> Checks inodes, indirect blocks, data blocks, free lists
–> If no file system name is specified, the fsck command will check all filesystems which have the check=true attribute set in the /etc/filesystems
–> Orphan files are placed in the /lost+found directory
Documenting File System Setup:
Run the lsfs command
Get the contents of the /etc/filesystems file
Run the df command to check free space
Check all the mounted file systems by running the mount command
Q: Is there a down side to creating a large-file enabled file system?
A: The only problem could be in data block allocation. Large file enabled file systems need 32 contiguous 4K blocks for files larger than 4 MB. If the file system contains lots of small files that are scattered around the file system, there may not be 32 contiguous blocks. If this occurs, you will get out space errors even though there is plenty of space. Without the large file enable attribute, the data will look for 4K blocks instead. You are more likely to find 1 4K block than 32 contiguous 4K blocks.
Q: If I mount a file system read/write, does that mean anyone can read or write all the files in it?
A: No. The permissions on the files will dictate whether someone can read, write, or execute them. Mounting a file system read only, will prevent any changes from occurring in that file system regardless of file permissions.
Q: When I create a file system in SMIT, do I have to create the directory that will be used as the mount point first?
A: No. SMIT will create the directory automatically for you. It will not mount the file system automatically. You will need to do that in a separate step.
Q: Why should I change the Allocation Group Size?
A: Only change this if you are trying to reach file system sizes larger than 2GB. Changing the allocation group size will let you have NBPI values larger than 16384. You will need a NBPI larger than 16384 to go beyond 2GB due to the maximum limitation of the number of inodes in a file system (2 to the 24th power).
Q: When should I set my fragment size smaller than 4096?
A: Set it smaller whenever you expect the majority of files in the file systems to be smaller than 4096 bytes.
Q: When I am increasing the file system size through smit, what happens if I don’t provide a size that is a multiple of the partition size?
A: LVM will automatically round the number up. For example, if you want to increase your file system by one 4 MB partition, you should increase the number by 8192 (512-byte blocks). However, if you only increased the number by 1, the smallest increment available is 8192 so that is what you will get. There are a couple of shortcuts. If you want 1 additional partition added, just add one to the existing number. For example if the size is currently 8192, change it to 8193. This will force the allocation of another partition and the value will automatically adjust to 16384. You can also use a “+” to indicate how much to increase it by. Maybe you want two partitions but don’t want to do the math. You could tell SMIT to change the size to +16384. This will add 16384 to the existing size.
Q: I removed an LV that contained a FS. What should I do now?
A: You should go into smit fs and remove the file system. If you don’t, /etc/filesystems will continue to hold the definition of the file system but the related LV is really gone. And, it could get worse. If you add another file system, the LV that is created could be the same as the one that you removed. The problem with that is in /etc/filesystems, the old file system references the same LV as the new file system. This will cause problems. If there is a file system on the LV, remove the file system, not the LV.
Q: /usr shows at 100% full. What should I do?
A: No. You can write scripts to do this. You may also investigate a tool called PDT that comes as part of the performance toolkit. This tools will monitor your filesystems and provide reports of the file system status.
Q: / (root) shows 95% full. What should I do?
A: Act now. Start investigating. Try running “du -x /” to determine what is filling the root filesystem. If root fills, your system will most likely crash. So clean up or increase the file system.
Q: Should I unmount my file system prior to running defragfs?
A: No. The file system needs to be mounted for defragfs to work.