[LU-11466] DoM files should not need LSOM sync for valid attributes on the MDS Created: 03/Oct/18  Updated: 12/Oct/19  Resolved: 27/Nov/18

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.12.0
Fix Version/s: Lustre 2.12.0

Type: Bug Priority: Minor
Reporter: James Nunez (Inactive) Assignee: Qian Yingjin
Resolution: Fixed Votes: 0
Labels: LSOM

Issue Links:
Related
is related to LU-9538 Size on MDT with guarantee of eventua... Resolved
is related to LU-11479 Error replicating xattr for /tmp/targ... Resolved
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

Currently, Lazy size on MDT (LSOM) creates and stores file attributes on the MDS for Data on MDT files, just like all other files, and we need to llsom_sync to get the file attributes for DoM files to be correct. The file metadata for DoM files is on the MDS already and is valid. Thus, we shouldn’t have to sync to get the LSOM data to match the DoM file metadata.

From the example below, we can see that the number of blocks in the LSOM data for the DoM file mdt_file_2 is only updated after we run llsom_sync

# lfs setstripe -E 4M -L mdt /lustre/scratch/mdt_file_2
# dd if=/dev/urandom of=/lustre/scratch/mdt_file_2 bs=25k count=2
2+0 records in
2+0 records out
51200 bytes (51 kB) copied, 0.00100831 s, 50.8 MB/s

# lfs getsom /lustre/scratch/mdt_file_2
file: /lustre/scratch/mdt_file_2 size: 51200 blocks: 0 flags: 4

# llsom_sync /lustre/scratch -vvvv -vvv -u cl1 -m scratch-MDT0000
Start receiving records
Processed changelog record index:5894 type:CREAT(0x1) FID:[0x200000401:0x99d:0x0]
Processed changelog record index:5895 type:LYOUT(0xc) FID:[0x200000401:0x99d:0x0]
Processed changelog record index:5896 type:XATTR(0xf) FID:[0x200000401:0x99d:0x0]
Processed changelog record index:5897 type:CLOSE(0xb) FID:[0x200000401:0x99d:0x0]
Start to sync 1 records.
record 1652041866429631028:5897, updated LSOM for fid [0x200000401:0x99d:0x0] size:51200 blocks:112
Processed changelog record index:5898 type:CLOSE(0xb) FID:[0x200000401:0x99d:0x0]
Start to sync 1 records.
record 1652041866429970184:5898, updated LSOM for fid [0x200000401:0x99d:0x0] size:51200 blocks:112
Processed changelog record index:5909 type:XATTR(0xf) FID:[0x200000401:0x99d:0x0]
Processed changelog record index:5910 type:XATTR(0xf) FID:[0x200000401:0x99d:0x0]
Processed changelog record index:5911 type:CLOSE(0xb) FID:[0x200000401:0x99d:0x0]
Start to sync 1 records.
record 1652041916629724290:5911, updated LSOM for fid [0x200000401:0x99d:0x0] size:51200 blocks:112
finished reading [scratch-MDT0000]
Start to sync 0 records.
[root@trevis-62vm4 ~]# lfs getsom /lustre/scratch/mdt_file_2
file: /lustre/scratch/mdt_file_2 size: 51200 blocks: 112 flags: 4

Also, for DoM files, shouldn’t the flag = 1; SOM_FL_STRICT = 0x0001 - Known strictly correct, FLR or DoM file (SoM guaranteed). In the case above, the flag never changes from 4, SOM_FL_LAZY = 0x0004 - Approximate, may never have been strictly correct, need to sync SOM data to achieve eventual consistency.



 Comments   
Comment by Qian Yingjin [ 09/Oct/18 ]

After discussion, we think that there is no need to store the SOM xattr for DoM-only files.
When scan the MDT image, DoM-only files can be specializied handled, the size and blocks information of the file can be got directly from files' inode directly, no need SoM xattr anymore.

Comment by Gerrit Updater [ 10/Oct/18 ]

Yingjin Qian (qian@ddn.com) uploaded a new patch: https://review.whamcloud.com/33331
Subject: LU-11466 mdt: Skip SOM xattr update for DoM-only files
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 5868e79d8a67af3326b4c8ae2a801cb8c2f76d2b

Comment by Gerrit Updater [ 27/Nov/18 ]

Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/33331/
Subject: LU-11466 mdt: Skip SOM xattr update for DoM-only files
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 76b9eecdebf830606b021079148eaefa6aab99cc

Comment by Peter Jones [ 27/Nov/18 ]

Landed for 2.12

Generated at Sat Feb 10 02:44:07 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.