Re: `du -h` not printing out the filesystems?
In the last episode (Aug 30), Robert G. said: > chkn# du -h > 12K. > chkn# > > Anyone know what that is? This is a brand new FreeBSD 5.4 install. Did you mean to run df maybe? -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: `du -h` not printing out the filesystems?
At 08:43 PM 8/30/2005, Robert G. wrote: chkn# du -h 12K. chkn# Anyone know what that is? This is a brand new FreeBSD 5.4 install. A bit of a guess, but it looks like you're running du in a dir that has no subdirs. -Glenn Thanks -- Robert G. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: du -k VS ls -l (what I'm missing?)
On Fri, Jul 02, 2004 at 01:04:32AM +0400, Alex K wrote: > what do I miss here? > sum of individual file sizes is much more than "total" in ls and more than du -k > reports > > bash-2.05b$ ls -l > total 354112 > -rw-r--r-- 1 lesha wheel 98490960 1 ??? 12:29 88479E51B1D77190A2A8C882 > -rw-r--r-- 1 lesha wheel 299376716 25 ??? 15:20 F44AA5CA2D90F33EE0F1 > -rw-r--r-- 1 lesha wheel 540729348 1 ??? 19:01 0C859D601337F1D26D68BA90 > -rw-r--r-- 1 lesha wheel 125204414 30 ??? 18:12 50922168AB8D4CB73FA39063 > -rw-r--r-- 1 lesha wheel 365164364 1 ??? 12:06 CBB789334BF480B9ED153EA8 > -rw-r--r-- 1 lesha wheel 209031053 30 ??? 19:05 B2AFAA6C8C68575BA97476F4 > -rw-r--r-- 1 lesha wheel 336457988 29 ??? 17:43 200DCA96AFFAF2FB08E3E279 > -rw-r--r-- 1 lesha wheel 40714776 1 ??? 18:16 6E30F671D9F305458A093617 > -rw-r--r-- 1 lesha wheel 209945132 25 ??? 15:29 A515D96BFAD85C294D4A9BB7 > -rw-r--r-- 1 lesha wheel 114632620 1 ??? 18:25 7868FE483F37D653109E67B3 > -rw-r--r-- 1 lesha wheel 242241614 1 ??? 19:02 75B7DC03642E00CE564C1FF6 > -rw-r--r-- 1 lesha wheel 42681134 25 ??? 15:29 F9C3246915327E44B9B0FD2C > -rw-r--r-- 1 lesha wheel 165569384 30 ??? 18:54 4FCA6EC8E3AB33B33E3E5011 > bash-2.05b$ du -k > 354114 . > bash-2.05b$ The 'total' figure from ls(1) and the number shown by du(1) is the total disk usage in blocks of 1024 bytes (if BLOCKSIZE=k is set in your environment, which is the default) -- in this case, about a factor of 7 smaller than the total of the file sizes. Files can have 'holes' -- parts of the file that have never been written to, although later parts of the file have. Disk blocks are not allocated for those unwritten areas. If you use hexdump(1) on the file, the holes will show up as a sequence of null bytes. The way to tell if a file is holey is to compare the size of the file against the number of blocks allocated for it using: % stat -f "%10z %6b %N" * [ or % ls -ls * where the 1st column is the number of blocks, the 6th is the filesize in bytes] If the filesize is significantly greater than the number of blocks multiplied by the block size (stat(1) shows 512 byte blocks, ls(1) shows 1024 byte blocks) then those files have holes in them. It's quite common to see this, for example, in files that are the backing stores for databases. Having holey files is not a problem, although some broken backup software will tend to fill in all of the gaps with zeros, meaning that occasionally you can't restore a file back onto the same partition it was backed up from. You can quite easily have a file whose apparent size is larger than the partition holding it. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgpJZHzOMARMS.pgp Description: PGP signature
Re: du -s causes reboot
On Sat, May 15, 2004 at 04:50:24AM -0700, Kris Kennaway wrote: : : On Sat, May 15, 2004 at 04:54:10AM -0500, Eugene Lee wrote: : : > FreeBSD 4.9p7. I have a new Dell PowerEdge 1750 that is giving me fits. : > I have a ~/src directory containing source tarballs that are unpacked. : > A "du -s ~/src" locks up my ssh session and causes it machine to reboot. : > No entries in /var/log/messages or /var/log/console.info to indicate the : > problem. No core dumps either. All filesystems (except root) have : > softupdates enabled. Suggestions to troubleshoot this are appreciated. : > Rebuilding the kernel now with -g, hope it helps... : : Try dropping to single-user mode and applying the utility from your : domain name :-) It's possible you have filesystem corruption that is : causing your kernel crashes. Finally had a chance to get to the office and onto the PowerEdge console to do the obvious (i.e. /sbin/fsck, what Kris suggested). If there was any corruption in the filesystem, it seems to have fixed. Civilization is saved once again. Thanks Kris. :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: du -s causes reboot
On Sat, May 15, 2004 at 04:54:10AM -0500, Eugene Lee wrote: > FreeBSD 4.9p7. I have a new Dell PowerEdge 1750 that is giving me fits. > I have a ~/src directory containing source tarballs that are unpacked. > A "du -s ~/src" locks up my ssh session and causes it machine to reboot. > No entries in /var/log/messages or /var/log/console.info to indicate the > problem. No core dumps either. All filesystems (except root) have > softupdates enabled. Suggestions to troubleshoot this are appreciated. > Rebuilding the kernel now with -g, hope it helps... Try dropping to single-user mode and applying the utility from your domain name :-) It's possible you have filesystem corruption that is causing your kernel crashes. If not, you'll need to capture the panic by enabling crashdumps; see the chapter on kernel debugging in the developer's handbook. Kris pgpP3vg0Tmhf1.pgp Description: PGP signature
Re: du
- Original Message - From: "Lowell Gilbert" <[EMAIL PROTECTED]> To: "Henning, Brian" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, March 16, 2004 16:15 Subject: Re: du > Please don't top-post. > > "Henning, Brian" <[EMAIL PROTECTED]> writes: > > > The only reason why I question it is when I lookup the size in windows > > (the directory is shared with samba) I see it as less. > > >From bsd: 390 /home/henninb/jpg > > >From windows: 372KB windows > > > > Is it because of the share or the change in platform? > > How did you measure it on Windows? I suspect what's happening is that > Windows gave you the actual sum of the sizes of all the files, whereas > du(1) counts the space *used* by all the files. In other words, the > Windows tool is giving a count in bytes, whereas du(1) is giving a > count in disk blocks (rounded up to the nearest block, because that > space is unavailable for other files to use). It may have. Starting with W2K, if you right click a file and select properties, you are given two file sizes: "Size" and "Size on disk". "Size on disk" is the total size - file size and the so-called slack space. Using any other method (such as Explorer or the dir command) gives only the file size. Always be careful to compare apples to apples ;) To get tangential for a moment, an interesting exercise is to discover how many different methods Windows has for reporting total harddrive size and how many different values are returned. An additional exercise for the advanced student is to find out why different methods report values. (Hint: Sometimes Windows sucks) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: du
Please don't top-post. "Henning, Brian" <[EMAIL PROTECTED]> writes: > The only reason why I question it is when I lookup the size in windows > (the directory is shared with samba) I see it as less. > >From bsd: 390 /home/henninb/jpg > >From windows: 372KB windows > > Is it because of the share or the change in platform? How did you measure it on Windows? I suspect what's happening is that Windows gave you the actual sum of the sizes of all the files, whereas du(1) counts the space *used* by all the files. In other words, the Windows tool is giving a count in bytes, whereas du(1) is giving a count in disk blocks (rounded up to the nearest block, because that space is unavailable for other files to use). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: du
[ du(1) accuracy ] On Tue, Mar 16, 2004 at 12:17:12PM -0600, Henning, Brian wrote: > The only reason why I question it is when I lookup the size in windows > (the directory is shared with samba) I see it as less. > >From bsd: 390 /home/henninb/jpg > >From windows: 372KB windows > > Is it because of the share or the change in platform? Hmmm.. that's only a 5% difference: unlikely to be due to differences in blocksize. I'd guess that both OSes will manage the trivial task of adding up the size of all the files under that directory without making silly errors. I guess there's something which either isn't included in the share as produced by Samba, or that Windows assumes it can ignore, validly on a native Windows filesystem but not on a Samba share. On the whole though I wouldn't worry about it too much -- it's "good enough for Government work". Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
RE: du
The only reason why I question it is when I lookup the size in windows (the directory is shared with samba) I see it as less. >From bsd: 390 /home/henninb/jpg >From windows: 372KB windows Is it because of the share or the change in platform? thanks -Original Message- From: Matthew Seaman [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 11:33 AM To: Chris Cc: [EMAIL PROTECTED] Subject: Re: du On Tue, Mar 16, 2004 at 10:55:33AM -0600, Chris wrote: > On Tuesday 16 March 2004 10:53 am, Chris wrote: > > On Tuesday 16 March 2004 10:51 am, Brian Henning wrote: > > > does du return the size in KB by default? > > > thanks > > > > You can try du -h > > That's listed in man du > > Sorry - I forgot to answer - Yes Actually the answer is 'no, but...' -- by default du tells you the size in disk blocks, ie. multiples of 512b. However, the standard /etc/login.conf on FreeBSD causes the environment setting: BLOCKSIZE=K to be made, causing all the numbers du outputs (unless told otherwise on the command line) to appear in kilobytes. This is all quite clearly explained in the du(1) man page. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: du
On Tue, Mar 16, 2004 at 10:55:33AM -0600, Chris wrote: > On Tuesday 16 March 2004 10:53 am, Chris wrote: > > On Tuesday 16 March 2004 10:51 am, Brian Henning wrote: > > > does du return the size in KB by default? > > > thanks > > > > You can try du -h > > That's listed in man du > > Sorry - I forgot to answer - Yes Actually the answer is 'no, but...' -- by default du tells you the size in disk blocks, ie. multiples of 512b. However, the standard /etc/login.conf on FreeBSD causes the environment setting: BLOCKSIZE=K to be made, causing all the numbers du outputs (unless told otherwise on the command line) to appear in kilobytes. This is all quite clearly explained in the du(1) man page. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: du
On Tuesday 16 March 2004 10:53 am, Chris wrote: > On Tuesday 16 March 2004 10:51 am, Brian Henning wrote: > > does du return the size in KB by default? > > thanks > > You can try du -h > That's listed in man du Sorry - I forgot to answer - Yes -- Best regards, Chris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: du
On Tuesday 16 March 2004 10:51 am, Brian Henning wrote: > does du return the size in KB by default? > thanks You can try du -h That's listed in man du -- Best regards, Chris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: du,df tools
Hi Brain Try df -h (h for human readable output I think)Also, in you shell profile change BLOCKSIZE= to k for kilobytes, M for Megabytes to suit you needs Regards Andrew Kozak ] On Wed, 2003-09-24 at 03:52, Brian Henning wrote: > Greetings: > I would like to use df and du tools to get some stat about my files and my disk. > > first, why does 59375408 + 1348433 != 61337213 > df -k /home/henninb > Filesystemkbytesused avail capacity Mounted on > 61337213 59375408 134843398%/home/henninb > > second, when i try the following command i get the result in usage on the disk. > does du give results of 'actual file size'? can i get it to report the result > in bytes or megabytes? > du -a -k /home/henninb/ > > Thanks for any help, > > Brian > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: du,df tools
> first, why does 59375408 + 1348433 != 61337213 > df -k /home/henninb > Filesystemkbytesused avail capacity Mounted on > 61337213 59375408 134843398%/home/henninb I believe your disk has 1% reserved space. See newfs(8) -m free space % The percentage of space reserved from normal users; the minimum free space threshold. The default value used is defined by MINFREE from , currently 8%. See tunefs(8) for more details on how to set this option. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: du -sh inconsistant with df -h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > Paul: > > > > You hit the nail right on the head! I did a lsof +L1 and found > > stunnel taking up a huge (2148999) amount of space. Killed it, > > restarted it and all my space is back! Now, the question is why does > > it keep accumulating all that space and how can I prevent that from > > happening. Quick addendum: I had stunnel on debug level 7 which was logging a tremendous amount of information since it records each and every connection; I have many users check their mail via a tunneled pop connection every 1-3 minutes! As you can imagine, the log files were enormous. Wiping the logs and dialing the debug level down to 4 fixed the problem nicely. Hope this helps someone else. Happy holidays to all! -BEGIN PGP SIGNATURE- Version: PGP 8.0 Comment: This message has been digitally signed by Mike Loiterman iQA/AwUBPgPRl2jZbUnRudGOEQKsowCg+Yig3H1E+MfddfGQBIk1NQo08VkAn3Uz xDmnOSKmyg8ctznns37K14Jl =Oswk -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: du -sh inconsistant with df -h
I'm posting this offline message to the group for others who may be researching the same problem. Apparently 'stunnel' was the culprit. >> Are you familiar with 'lsof'? This utility, in >> /usr/ports/sysutils/lsof, will show all open files. It may help you >> discover the cause of the problem. I recommend that you install the >> port and run "lsof +L1" which should list all unlinked files. Read >> the man page carefully though. I may not have the correct syntax, >> and you may discover many other valuable things you can do. >> >> Paul >> > > Paul: > > You hit the nail right on the head! I did a lsof +L1 and found > stunnel taking up a huge (2148999) amount of space. Killed it, > restarted it and all my space is back! -- Paul A. Scott mailto:[EMAIL PROTECTED] http://skycoast.us/pscott/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: [Fwd: Re: du -sh inconsistant with df -h]
> From: Mike Loiterman <[EMAIL PROTECTED]> > Where are the extra 1.6 megs at? If a running process opens a file and then unlink(2)'s it, the file will not show up in the filesystem, and du will not reflect any space it uses. However, df will. Paul >>> >>> >>> >>> So is there any way to reclaim that space aside from rebooting? >> >> Kill that process. >> > > How do I know which process is doing the right one? Prseumably, the > process itself has already been terminated, is this correct? You probably don't want (or need) to kill the process. It is probably working correctly. There are good reasons why a process will open a file and then immediately unlink it while it's still open. If the file is unlinked, then it can't be seen in the file system, so it's safer from prying eyes if it contains confidential data. Also, if the process terminates unexpectedly the file space is reclaimed automatically; no action required. When an open file is unlinked, the used space is not reclaimed (and may even grow larger if needed) until the file is closed or the process ends. This is a feature of unix systems. I don't know of any other OS that does this, but I've depended on this feature many times in the past when writing complex shell scripts that needed a large scratchpad for sensitive data. Read the man page on unlink(2) for an explanation. Paul -- Paul A. Scott mailto:[EMAIL PROTECTED] http://skycoast.us/pscott/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: du -sh inconsistant with df -h
Mike Loiterman wrote: This is strange. When I do: [11:49:09 root@fat_man: /var]# du -sh 7.0M. > but when I do: [11:49:18 root@fat_man: /var]# df -h FilesystemSize Used Avail Capacity Mounted on /dev/ad0s1a97M55M34M62%/ /dev/ad0s1f 1.7G 1.2G 403M75%/usr /dev/ad0s1e19M 8.6M 9.2M48%/var procfs4.0K 4.0K 0B 100%/proc Where are the extra 1.6 megs at? I thought there must be a stray process running that had a lock on that amount of memory, but I couldn't find anything with top or via ps -aux. I use tripwire everynight to check file consistencies and I believe it's the problem, I can't figure out how or why. Rebooting the server fixes the problem and clears up the missing memory. ??? Please reply to [EMAIL PROTECTED] which is the address I am subscribed with, but since my isp hasn't corrected my reverse dns problem yet, I can't post from that address to *@freebsd.org. Thanks! Hm, let me see what my development machine says: -bash-2.05b# cd /var/www/ -bash-2.05b# du -sh 471M. -bash-2.05b# df -h FilesystemSize Used Avail Capacity Mounted on /dev/da0s1a 126M46M70M40%/ /dev/da0s1e 7.9G 1.4G 5.9G19%/usr /dev/da0s1f 3.9G 268M 3.4G 7%/var /dev/da0s1g 5.8G 471M 4.9G 9%/var/www procfs4.0K 4.0K 0B 100%/proc Maybe it's because your /var filesystem is really small? If you can you should try boot in single user mode and test again. It could help seeing your running processes... But 1.6 Meg??? To much I think for being cached, isn't it? Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: du -sh inconsistant with df -h
> From: "Mike Loiterman" <[EMAIL PROTECTED]> > Where are the extra 1.6 megs at? If a running process opens a file and then unlink(2)'s it, the file will not show up in the filesystem, and du will not reflect any space it uses. However, df will. Paul -- Paul A. Scott mailto:[EMAIL PROTECTED] http://skycoast.us/pscott/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: du, find/xargs/sort, and MP3.tar
# [EMAIL PROTECTED] / 2002-10-23 17:05:48 -0400: > On 22 Oct 2002, Gary W. Swearingen wrote: > > Peter Leftwich <[EMAIL PROTECTED]> writes: > > > Then I thought I'd get crafty and > > > `tar tvf MP3.DONE0415021909MPT.tar > the-tarfile.out` thinking I > > > could later run things through `sort` but I am hung up on how to > > > get similar output that shows the contents of MP3/. > > tar cf - MP3/ | tar tvf - >the-mp3dir.out > > Could someone step through what this is doing? I thought you could use "-" > (stdin?) only once on a command line. the first tar sends the tarball to stdout, the second reads it from stdin. your shell connect those two together. > My question was more about using less CPU time with something simiar > to "find" or `ls -alR | sort` the output of `ls -alR` is not suitable for what you want. `tar tvf` with find(1) is your best bet. -- If you cc me or take the list(s) out completely I'll most likely ignore your message. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: du, find/xargs/sort, and MP3.tar
On 22 Oct 2002, Gary W. Swearingen wrote: > Peter Leftwich <[EMAIL PROTECTED]> writes: > > Then I thought I'd get crafty and `tar tvf MP3.DONE0415021909MPT.tar > > > the-tarfile.out` thinking I could later run things through `sort` but I am > > hung up on how to get similar output that shows the contents of MP3/. > tar cf - MP3/ | tar tvf - >the-mp3dir.out Could someone step through what this is doing? I thought you could use "-" (stdin?) only once on a command line. My question was more about using less CPU time with something simiar to "find" or `ls -alR | sort` -- Peter Leftwich President & Founder Video2Video Services Box 13692, La Jolla, CA, 92039 USA +1-413-403-9555 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: du, find/xargs/sort, and MP3.tar
Peter Leftwich <[EMAIL PROTECTED]> writes: > Then I thought I'd get crafty and `tar tvf MP3.DONE0415021909MPT.tar > > the-tarfile.out` thinking I could later run things through `sort` but I am > hung up on how to get similar output that shows the contents of MP3/. tar cf - MP3/ | tar tvf - >the-mp3dir.out To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
