On Thu, Aug 14, 2008 at 03:23:24PM -0700, Nifty Cluster Mitch wrote:
> On Thu, Aug 14, 2008 at 02:45:43PM -0700, MHR wrote:
> > On Thu, Aug 14, 2008 at 2:36 PM, Nifty Cluster Mitch
> > > $ cat /tmp/checkspace
> > > #!/bin/bash
> > > df -Pkl > /tmp/checkingdiskspce
> > > echo -e "\nInput is:"
> > > cat /tmp/checkingdiskspce
> > > echo -e "\nAdding up the bits"
> > > cat /tmp/checkingdiskspce | awk '/^\/dev\// { used += $3/1024 } END { printf("%d Mb Used\n", used)} '
> >
> > This is simpler (and does not involve as many execs & forks) as:
> >
> > awk '/^\/dev\// { used += $3/1024 } END { printf("%d Mb Used\n",
> > used)} ' /tmp/checkingdiskspce
>
> True, yet if the goal is "df | awk" with no tmp file at all the final
> edit and cleanup is cleaner. If the goal is to present the result of
Boggle-riffic! if you want to see the input as well, then do it in the
awk side. So we have a "df" and an "awk"; one pass through the
output... everything is optimal!
df -Pkl | awk 'BEGIN { print "\nInput is:" }
{ print $0 }
/^\/dev\// {used += $3/1024 }
END { printf("\nAdding up the bits:\n%d MB Used\n",used)}'
Input is:
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda6 4061540 3182144 669752 83% /
/dev/sda5 449567400 28064608 398297708 7% /datadisk
/dev/sda3 93327 11124 77384 13% /boot
tmpfs 2041736 0 2041736 0% /dev/shm
Adding up the bits:
30525 MB Used
(of course I only made that multiple lines for readability; you could put
it all on one line if you really wanted to :-))
> I did notice in this discussion that no one looked at inode counts.
> A filesystem might be "full" for want of an inode.... I cannot
When you're adding up all used space over multiple disks you're not
concerned with a disk filling up. You're just looking for total usage.
Off the top of my head I can only think of one (bad) reason to do it;
some sort of billing system.
The numbers don't even taken into account the %age of space reserved for
root :-)
> Other interesting system admin topics not addressed includes sparse files. For some
> knowing about sparse files is important for backup tools. Also allocation block size
Only for broken backup tools that don't handle sparse files :-) And, yes,
I had one of those in 1990... tar on a DEC Ultrix 3.1 system doesn't grok
sparse files. Bleh! Fortunately "dump" did it properly.
--
rgds
Stephen