Bug 1127065 - ls produces inconsistent sizes
Summary: ls produces inconsistent sizes
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-08-06 04:33 UTC by lionghostshop
Modified: 2014-08-06 12:59 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-08-06 12:52:05 UTC

Attachments (Terms of Use)

Description lionghostshop 2014-08-06 04:33:21 UTC
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run ll
2. Run ls -sh
3. The sizes of core.2328 are 47 M and 6.5M. 

Actual results:
[leo@thinkpad-leo DR]$ ll dr_replay/ -sh
total 11M
   0 drwxrwxr-x 3 leo leo  121 Aug  6 08:30 build
4.0K -rwxrwxr-x 1 leo leo  159 Aug  4 12:13 build.sh
6.5M -rw------- 1 leo leo  47M Aug  6 09:48 core.2328
3.2M -rw------- 1 leo leo  44M Aug  6 12:11 core.6597
4.0K -rw-rw-r-- 1 leo leo   68 Aug  4 12:19 env.sh
400K -rwxr-xr-x 1 leo leo 397K Aug  4 11:09 memcached
 16K -rw-rw-r-- 1 leo leo  15K Aug  4 12:12 out
4.0K -rwxrwxr-x 1 leo leo  117 Aug  6 08:07 run1.sh
4.0K -rwxrwxr-x 1 leo leo   33 Aug  5 16:10 run2.sh
   0 drwxrwxr-x 2 leo leo   44 Aug  6 08:35 sym
 12K -rwxrwxr-x 1 leo leo 8.5K Aug  5 15:43 test_main
4.0K -rw-rw-r-- 1 leo leo  108 Aug  4 12:12 test_main.c
[leo@thinkpad-leo DR]$ ls
build_replay.sh  commons  dr_replay  DynamoRIO_replay_build  memcached-1.4.20
[leo@thinkpad-leo DR]$ ls -sh dr_replay/
total 11M
   0 build     6.5M core.2328  4.0K env.sh      16K out      4.0K run2.sh   12K test_main
4.0K build.sh  3.2M core.6597  400K memcached  4.0K run1.sh     0 sym      4.0K test_main.c

Additional info:

If I copy dr_replay folder to other places, the problem does not occur again.
I am using XFS.

Comment 2 Pádraig Brady 2014-08-06 12:52:05 UTC
While this is confusing, there is no inconsistency here.

Notice the first column is 6.5M in the `ll -sh` case, which corresponds to the `ls -sh` reported disk usage for the sparse core file.

Once you copy the file you're probably removing the sparseness (though that may be another issue as cp should maintain the sparseness if possigle).

Comment 3 lionghostshop 2014-08-06 12:59:26 UTC
I see. Thank you.

Note You need to log in before you can comment on or make changes to this bug.