Re: du result is smaller than xfs_quota report

[YeYin <eyniy@qq.com>]

[-- Attachment #1.1: Type: text/plain, Size: 5302 bytes --]

Hi, Dave,
Thank you very much. I got some results:
# xfs_db -xr  /dev/sda4                        
xfs_db> convert agno 1 agino 78272 ino
0x800131c0 (2147561920)
xfs_db> inode 2147561920
xfs_db> p
core.magic = 0x494e
core.mode = 0100600
core.version = 2
core.format = 2 (extents)
core.nlinkv2 = 0
core.onlink = 0
core.projid_lo = 26286
core.projid_hi = 0
core.uid = 30000
core.gid = 100
core.flushiter = 30
core.atime.sec = Tue Oct 20 13:51:58 2015
core.atime.nsec = 104938956
core.mtime.sec = Tue Oct 20 13:53:58 2015
core.mtime.nsec = 824941455
core.ctime.sec = Tue Oct 20 14:21:59 2015
core.ctime.nsec = 062660227
core.size = 41041920
core.nblocks = 10020
core.extsize = 0
core.nextents = 2
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 1
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.filestream = 0
core.gen = 1194777008
next_unlinked = 75712
u.bmx[0-1] = [startoff,startblock,blockcount,extentflag] 0:[0,135330882,32,0] 1:[32,146117410,9988,0]





However, I want to ask how this situation to happen?


From the output,  we can see "core.nlinkv2 = 0". But I can't reapper this:


# dd if=/dev/zero of=/data/test.data bs=4k count=1024
1024+0 records in
1024+0 records out
4194304 bytes (4.2 MB) copied, 0.00476946 s, 879 MB/s


# stat /data/test.data 
  File: `/data/test.data'
  Size: 4194304         Blocks: 8192       IO Block: 4096   regular file
Device: 804h/2052d      Inode: 29409295    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-10-21 16:05:45.201679018 +0800
Modify: 2015-10-21 16:05:45.205679018 +0800
Change: 2015-10-21 16:05:45.205679018 +0800


# xfs_db -xr -c 'inode 29409295' -c p /dev/sda4                                      
core.magic = 0x494e
core.mode = 0100644
core.version = 2
core.format = 2 (extents)
core.nlinkv2 = 1
core.onlink = 0
core.projid_lo = 0
core.projid_hi = 0
core.uid = 0
core.gid = 0
core.flushiter = 12
core.atime.sec = Wed Oct 21 16:05:45 2015
core.atime.nsec = 201679018
core.mtime.sec = Wed Oct 21 16:05:45 2015
core.mtime.nsec = 205679018
core.ctime.sec = Wed Oct 21 16:05:45 2015
core.ctime.nsec = 205679018
core.size = 4194304
core.nblocks = 1024
core.extsize = 0
core.nextents = 1
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.filestream = 0
core.gen = 3722739155
next_unlinked = null
u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,5943235,1024,0]


# tail -f /data/test.data &
[1] 27598
# unlink /data/test.data 


# xfs_db -xr -c 'inode 29409295' -c p /dev/sda4
core.magic = 0x494e
core.mode = 0100644
core.version = 2
core.format = 2 (extents)
core.nlinkv2 = 1
core.onlink = 0
core.projid_lo = 0
core.projid_hi = 0
core.uid = 0
core.gid = 0
core.flushiter = 12
core.atime.sec = Wed Oct 21 16:05:45 2015
core.atime.nsec = 201679018
core.mtime.sec = Wed Oct 21 16:05:45 2015
core.mtime.nsec = 205679018
core.ctime.sec = Wed Oct 21 16:05:45 2015
core.ctime.nsec = 205679018
core.size = 4194304
core.nblocks = 1024
core.extsize = 0
core.nextents = 1
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.filestream = 0
core.gen = 3722739155
next_unlinked = null
u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,5943235,1024,0]



As we can see, core.nlinkv2 is still "1" after I unlink /data/test.data.


Thanks,
Ye


------------------ Original ------------------
From:  "Dave Chinner";<david@fromorbit.com>;
Date:  Wed, Oct 21, 2015 03:13 PM
To:  "YeYin"<eyniy@qq.com>; 
Cc:  "Eric Sandeen"<sandeen@sandeen.net>; "xfs"<xfs@oss.sgi.com>; 
Subject:  Re: du result is smaller than xfs_quota report



On Wed, Oct 21, 2015 at 02:37:04PM +0800, YeYin wrote:
> > Is anything mounted under that directory hierarchy, and hiding files from du's view?
> 
> 
> No, Thanks. I found some unlinked inodes, but I can't get some useful information:
> 
> 
> # xfs_db -xr -c 'agi 1' -c p /dev/sda4  
....
> unlinked[0-63] = 0:78272 ....

> # xfs_db -xr -c 'inode 78272' -c p /dev/sda4

That's because 78272 isn't an real inode number. It's a AG relative
inode number ("agino") of 78272. The global inode number folds in
the AG number to it, and this is from AG 1. So:

xfs_db> convert agno 1 agino 78272 ino
<inum>
xfs_db> inode <inum>
xfs_db> p
....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

[-- Attachment #1.2: Type: text/html, Size: 7952 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs