https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-6574 Lustre <p>doing a chown doesn't update object ownership on ost. This has caused our quota to be way off.<br/> here is a example</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">pfe22 ~ # stat /nobacku....180.3d.vtk File: `/nobacku...180.3d.vtk' Size: 65820817 Blocks: 128568 IO Block: 4194304 regular file Device: 48b492b4h/1219793588d Inode: 144118607926790745 Links: 1 Access: (0644/-rw-r--r--) Uid: (11467/ XXXX) Gid: (30730/ XXXXX) Access: 2014-01-17 17:09:36.000000000 -0800 Modify: 2014-01-17 17:09:36.000000000 -0800 Change: 2015-05-06 11:33:29.000000000 -0700 Birth: - pfe22 ~ # chown root:root /noback....180.3d.vtk lfs getstripe /nobackup....180.3d.vtk /nobacku....180.3d.vtk lmm_stripe_count: 1 lmm_stripe_size: 1048576 lmm_layout_gen: 0 lmm_stripe_offset: 0 obdidx objid objid group 0 7286499 0x6f2ee3 0 debugfs: pwd [pwd] INODE: 6815751 PATH: /O/0/d3 [root] INODE: 2 PATH: / debugfs: stat 7286499 Inode: 117 Type: regular Mode: 0666 Flags: 0x80000 Generation: 2012045754 Version: 0x00000009:04f812d0 User: 11467 Group: 0 Size: 65820817 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 128568 Fragment: Address: 0 <span class="code-object">Number</span>: 0 Size: 0 ctime: 0x52d9d450:00000000 -- Fri Jan 17 17:09:36 2014 atime: 0x00000000:00000000 -- Wed Dec 31 16:00:00 1969 mtime: 0x52d9d450:00000000 -- Fri Jan 17 17:09:36 2014 crtime: 0x52d9c7d5:451115c8 -- Fri Jan 17 16:16:21 2014 Size of extra inode fields: 28 Extended attributes stored in inode body: lma = <span class="code-quote">"00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 e3 2e 6f 00 00 00 00 00 "</span> (24) lma: fid=[0x100000000:0x6f2ee3:0x0] compat=0 incompat=0 fid = <span class="code-quote">"3f 1c 03 00 02 00 00 00 59 0a 00 00 00 00 00 00 "</span> (16) fid: parent=[0x200031c3f:0xa59:0x0] stripe=0 EXTENTS: (ETB0):170790783, (0-511):170587392-170587903, (512-1023):170558464-170558975, (1024-2047):170557440-170558463, (2048-6143):170784768-170788863, (6144-16069):1708011 52-170811077 </pre> </div></div> <p>I will upload debug from mds when i did a chown to root:root and then back to the user.<br/> file fid is <span class="error">&#91;0x200031c3f:0xa59:0x0&#93;</span></p> LU-6574

chown doesn't update object ownership on ost

Bug Major Resolved Duplicate Niu Yawei Mahmoud Hanafi Wed, 6 May 2015 19:27:10 +0000 Fri, 8 May 2015 22:42:44 +0000 Fri, 8 May 2015 22:42:44 +0000 Lustre 2.4.3 0 4 <p>uploaded debugs logs to ftp.whamcloud.com:/uploads/LU6574/out.2.bz2</p> <p>looks like this is where it is failing </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">00000004:00000001:13.0:1430953684.928752:0:5251:0:(osp_sync.c:481:osp_sync_new_setattr_job()) <span class="code-object">Process</span> entered 00000004:00020000:13.0:1430953684.928753:0:5251:0:(osp_sync.c:487:osp_sync_new_setattr_job()) nbp7-OST0000-osc-MDT0000: invalid setattr record, lsr_valid:100 00000004:00000001:13.0:1430953684.951012:0:5251:0:(osp_sync.c:494:osp_sync_new_setattr_job()) <span class="code-object">Process</span> leaving (rc=0 : 0 : 0) 00000004:00080000:13.0:1430953684.951013:0:5251:0:(osp_sync.c:666:osp_sync_process_record()) found record 10692401, 64, idx 64371, id 89608251: 0 </pre> </div></div> <p>Niu</p> <p>Could you please look into this issue?</p> <p>Thanks</p> <p>Peter</p> <p>Any patches applied to your 2.4.3? The messages in osp_sync_new_setattr_job() should not be in 2.4.3 tree.</p> <p>Can this be reproduced on any files? file created by 'lfs setstripe'? Existing file? And newly created file? Thanks.</p> <p>NASA's tree is at <a href="https://github.com/jlan/lustre-nas" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/jlan/lustre-nas</a></p> <p>Thank you, Peter.</p> <p>Mahmoud,<br/> The error message "osp_sync_new_setattr_job()) nbp7-OST0000-osc-MDT0000: invalid setattr record, lsr_valid:100" looks strange to me, I don't see how can the 'valid' be 100 from the code. The log you uploaded to ftp doesn't have such error messages, perhaps it was truncated? Could you send me a complete log if possible? Do you have a reproducer or this can only be reproduced on certain files? Thank you.</p> <p>The trouble MDS were running 2.4.3-14.2nasS. Mahmoud has tested that the 2.4.3-14.3nasS fixed the problem. We are planning an upgrade.</p> <p>Jay</p> <p>Does this mean that there is a particular fix that you can point to that probably has resolved this issue? Can we close out this ticket as a duplicate?</p> <p>Peter</p> <p>Peter,</p> <p>It was <a href="https://jira.whamcloud.com/browse/LU-4345" title="failed to update accounting ZAP for user" class="issue-link" data-issue-key="LU-4345"><del>LU-4345</del></a>. </p> <p>In dealing with <a href="https://jira.whamcloud.com/browse/LU-6269" title="Unable to mount /nobackupp8" class="issue-link" data-issue-key="LU-6269"><del>LU-6269</del></a> about 2 months ago, Oleg Drokin pointed me to <a href="https://jira.whamcloud.com/browse/LU-4345" title="failed to update accounting ZAP for user" class="issue-link" data-issue-key="LU-4345"><del>LU-4345</del></a>, and we (very) unhappily found out we had an earlier version of <a href="https://jira.whamcloud.com/browse/LU-4345" title="failed to update accounting ZAP for user" class="issue-link" data-issue-key="LU-4345"><del>LU-4345</del></a> patch (I think it was patchset #1) that seemed to have worked for us back then without knowing that <a href="https://jira.whamcloud.com/browse/LU-4345" title="failed to update accounting ZAP for user" class="issue-link" data-issue-key="LU-4345"><del>LU-4345</del></a> have gradually evolved itself to patchset #7.</p> <p>I upgraded lustre-nas 2.4.3 from 14.2nasS to 14.3nasS by picking up the <a href="https://jira.whamcloud.com/browse/LU-4345" title="failed to update accounting ZAP for user" class="issue-link" data-issue-key="LU-4345"><del>LU-4345</del></a> patchset #7 back then, but our servers stayed at 14.2nasS.</p> <p>Mahmoud is going to upgrade the servers today.</p> <p>We can close this ticket.</p> <p>ok - thanks!</p> Development Rank 1|hzxcn3: Rank (Obsolete) 9223372036854775807 Severity