A better way to get the byte count of a file is stat --format=%s On Fri, Apr 4, 2014 at 3:03 PM, David Wagle <david.wagle at gmail.com> wrote: > "apparent size" is the "ls -l" size of the file. > > which is the "rght" size for you to use is dependent on what you're trying > to do. > > Apparent size is nearly useless for managing disks -- which is usually > what you use du for. > > Say my disk has blocks that are 1KB. If I have a file with the nothing but > the letter 'A' in it, that will have an apparent size of 1 byte. But > because the smallest block size on my disk is 1KB, that 1 byte file will > USE 1 KB of disk space no matter what because the physical data has to be > recorded in a block and that block will then be marked 'used.' > > As an aside, imho, the 'apparent size' option is really a terrible option > to include in 'du' and is a violation of the unix philosophy because it has > explicitly NOTHING to do with disk management. But that's neither here nor > there. > > > On Fri, Apr 4, 2014 at 2:29 PM, Mike Miller <mbmiller+l at gmail.com> wrote: > >> On Tue, 1 Apr 2014, Mike Miller wrote: >> >> On Tue, 1 Apr 2014, Ben wrote: >>> >>> -h will always be different from the actual disk usage, you might also >>>> want to play around with -B option too. >>>> >>> >>> I've done that. Using --si -sB GB gives the same result as --si -sh. >>> Did you think that they would be different? >>> >> >> Thanks for the suggestions. Now I have answers (below). >> >> I was misusing the --si option there. It should be used *instead* of -h, >> not in conjunction with it. These two commands should do the same thing >> when the volume in "dir" is in the multi-gigabyte range... >> >> du -s --si dir >> du -sB GB dir >> >> ...and so should these two commands: >> >> du -sh dir >> du -sB G dir >> >> The first pair will report 1000*1000*1000 bytes and the second will >> report 1024*1024*1024 bytes. >> >> >> >> What happens when you use --apparent-size option. >>>> --apparent-size >>>> print apparent sizes, rather than disk usage; although the >>>> apparent size is usually smaller, it may be larger due to holes >>>> in ('sparse') files, internal fragmentation, indirect blocks, >>>> and the like >>>> >>> >>> I want to try that, but I'm having this problem right now: >>> >>> $ ls /project/guanwh >>> ls: cannot access /project/guanwh: Stale file handle >>> >> >> Yep, you nailed it. That was the issue. If I use --apparent-size, the >> results are consistent. According to supercomputing staff: >> >> "it is not a bug, -b is implies --apparent-size, so to compare its output >> to -sm/sh you have to include --apparent-size with -sm/-sh as well. >> >> "when the apparent size is different from the reported size it is not a >> bug in du but rather a feature of the filesystem :)" >> >> Now I just have to figure out which is the right size for me -- apparent >> or reported. I guess apparent sizes are the real file sizes. In this >> example "dir" has about 10,000 files in it with about half being 5 KB and >> have about 29 MB: >> >> $ du -s --si dir >> 162G dir >> >> $ du -s --si --apparent-size dir >> 143G dir >> >> $ du -sb dir >> 142038799951 dir >> >> $ wc -c dir/* | tail -1 >> 142037349967 total >> >> >> One thing to note: It seems that du always rounds up. So if 1.1 GB are >> used, du will report 2 GB. >> >> >> Mike >> _______________________________________________ >> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >> tclug-list at mn-linux.org >> http://mailman.mn-linux.org/mailman/listinfo/tclug-list >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20140404/203d5663/attachment.html>