Jerry Feldman wrote:

On Wednesday 26 April 2006 12:42 pm, James Watkins wrote:

...

Hi all, has anyone seen this before? I'm using an opensuse 10.0 box as a samba file server to store backups of our other windows servers. It took a while to figure out that there was no disk space since the samba box was still reporting that there was plenty. Looking a bit deeper, I found that although 'ls -l' showed the sizes of the individual files correctly, the total was wildly incorrect. Here is an example of the output of 'ls -l' :

total 29274510 -rwxr--r-- 1 M2\backup M2\domain admins 28353837056 2006-02-18 00:47 B2D000161.bkf -rwxr--r-- 1 M2\backup M2\domain admins 28456399872 2006-04-01 00:51 B2D000162.bkf -rwxr--r-- 1 M2\backup M2\domain admins 28456552448 2006-04-04 00:51 B2D000163.bkf -rwxr--r-- 1 M2\backup M2\domain admins 28456648704 2006-04-05 00:49 B2D000164.bkf -rwxr--r-- 1 M2\backup M2\domain admins 28451419136 2006-04-06 00:49 B2D000165.bkf -rwxr--r-- 1 M2\backup M2\domain admins 28448050176 2006-04-08 00:49 B2D000166.bkf -rwxr--r-- 1 M2\backup M2\domain admins 714 2006-04-25 23:00 Changer.cfg -rw-r--r-- 1 root M2\domain admins 672743424 2006-04-26 16:55 test -rw-r--r-- 1 root M2\domain admins 3363717120 2006-04-26 17:02 test2

This behaviour is reflected by df and du. Am I doing something stupid or is this an actual bug? By the way, I the same thing happens whether I use reiser or ext3 so I assume that it is not filesystem specific.

Thanks in advance to anyone who can shed some light on this.

The du(1) and ls(1) utilities use the stat(2), fstat(2), or lstat(2) system calls. There report the size of a file.

df(1) reports the space available/used on the file system, generally in terms of blocks.

One must remember that these are 2 different things. A 1 byte file may take up a single block on a file system. ReiserFS tends to optimize itself for small files.

Thanks for the reply Jerry, but I'm not sure that the byte/block confusion is the source of my problem. I've noticed that this is the only directory on the filesystem for which the total is incorrect and also that the 'real total' (calulated by hand, admittedly with some degree of inaccuracy) appears to be greater than the capacity of the volume as reported by df. I was wondering if the 27GB files are acually smaller and ls is reporting their size incorrectly. I have attached the output of 'ls -lhR' together with the output of 'df -h' (the filesystem in question is the last in the list). Thanks again for your help, James.

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?

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. Another possibility is with SMB, but since you have a ReiserFS file system

On Friday 28 April 2006 8:23 am, James Watkins wrote: that is exported, it should not be a problem on the local system unless, as I mention, the file system was crated before the LFS fix. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9