Jerry Feldman wrote:
This is possible. You could use the stat(1) command that reports both the file size and the number of blocks the file occupies. I can see many cases where the size of a file in bytes will be small where the number of blocks can be large. Additionally, could that directory contain some hidden files. ls -lhR will not report them. It is also possible that there is some file system corruption. The "reiserfsck --check" command should be able report if the file system is corrupted.
Thanks for the stat tip, nice tool. stat reported that the size of one of the larger files was 28353837056 and that it was using 8442800 blocks, which sounds about right for a block size of 4096 bytes. However, during the course of my investigations I decided to copy this file repeatedly to see how long it took to fill up the filesystem. I kept an eye on the size of the new file whilst copying it and noticed that when the size reached 4294971392 bytes (4 GB and a block, I don't know if this is significant or not) it paused for about a minute and then suddenly jumped to the full size. This seems a bit odd. Running 'reiserfsck --check' revealed no corruptions and there were no relevant messages in /var/log/messages. My next test will be to create a large file from /dev/urandom to see if I can create a file that's bigger than 4GB. My theory is that either my backup agent (backup exec) or samba gave up writing real data after 4GB and filled the rest with zeros and since reiserfs supports sparse files it doesn't really store those zeros, it just keeps a record of how many there are. Does this sound reasonable?