hi, since some weeks i've noticed that filesizes for new files differ in the outputs of ls and du. file contains 100MB of /dev/urandom. copy is a copy of file. # ls -l file copy -rw-r--r-- 1 root root 104857600 2013-01-04 11:43 copy -rw-r--r-- 1 root root 104857600 2013-01-04 10:21 file # ls -lh file copy -rw-r--r-- 1 root root 100M 2013-01-04 11:43 copy -rw-r--r-- 1 root root 100M 2013-01-04 10:21 file # du -bs file copy 104857600 file 104857600 copy # du -hs file copy 128M file !! 100M copy # stat file copy File: `file' Size: 104857600 Blocks: 262144 IO Block: 4096 regular file Device: fb03h/64259d Inode: 4705643 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2013-01-04 10:21:28.721872771 +0000 Modify: 2013-01-04 10:21:42.641599647 +0000 Change: 2013-01-04 10:21:42.641599647 +0000 File: `copy' Size: 104857600 Blocks: 204800 IO Block: 4096 regular file Device: fb03h/64259d Inode: 4709043 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2013-01-04 11:43:39.665785370 +0000 Modify: 2013-01-04 11:43:40.005778696 +0000 Change: 2013-01-04 11:43:40.005778696 +0000 notice the different count of blocks. this difference is reflected in the 28MB difference. # xfs_fsr -v file copy file file already fully defragmented. copy copy already fully defragmented. # sha1sum file copy 23071d0b4caeeb4aa9579283ca67c7c13e66b8ee file 23071d0b4caeeb4aa9579283ca67c7c13e66b8ee copy it's hard to create those files reliably, but the following procedure worked for me (see random.part): 1) dd file as concatenated parts 2) overwrite it again # dd if=/dev/urandom of=random.part bs=1M count=100 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 10.6646 s, 9.8 MB/s # dd if=/dev/urandom of=random.full bs=100M count=1 1+0 records in 1+0 records out 104857600 bytes (105 MB) copied, 11.132 s, 9.4 MB/s # ls -lh; du -hs * -rw-r--r-- 1 root root 100M 2013-01-04 12:11 random.full -rw-r--r-- 1 root root 100M 2013-01-04 12:10 random.part 100M random.full 100M random.part # dd if=/dev/urandom of=random.part bs=1M count=100 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 11.3788 s, 9.2 MB/s # dd if=/dev/urandom of=random.full bs=100M count=1 1+0 records in 1+0 records out 104857600 bytes (105 MB) copied, 10.6937 s, 9.8 MB/s # ls -lh; du -hs * -rw-r--r-- 1 root root 100M 2013-01-04 12:11 random.full -rw-r--r-- 1 root root 100M 2013-01-04 12:11 random.part 100M random.full 128M random.part !! i'm on ubuntu 10.04, kernel 2.6.38-13-server #57~lucid1-Ubuntu this issue does not exist as long as the uptime of the server is. i can't trigger this issue on another server that uses 3.2.0-35-generic #55-Ubuntu (12.04). is this a known issue? please tell me when you need additional information. cheers pille PS: when i stat the shell-script to check for the issue, it claims that it uses 128 blocks for 849 bytes: File: `check_issue8634.sh' Size: 849 Blocks: 128 IO Block: 4096 regular file Device: fb03h/64259d Inode: 4708316 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2013-01-03 10:45:15.000000000 +0000 Modify: 2013-01-04 11:54:01.583582496 +0000 Change: 2013-01-04 11:54:01.583582496 +0000 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
