[LU-11695] disabling the xattr cache on client for LSOM Created: 23/Nov/18 Updated: 28/Mar/23 Resolved: 11/Jul/22 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.16.0, Lustre 2.15.3 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Qian Yingjin | Assignee: | Qian Yingjin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||||||||||
| Description |
|
Currently, to get uptodate LSOM data, we need to set llite.*.xattr_cache=0 to disable the xattr cache on client completely. This may lead that other kind of xattr can not be cached on client too. This ticket mainly focues on the heavy-weight solution to disable caching only for LSOM xattr data ("trusted.som") on client. |
| Comments |
| Comment by Gerrit Updater [ 23/Nov/18 ] |
|
Yingjin Qian (qian@ddn.com) uploaded a new patch: https://review.whamcloud.com/33711 |
| Comment by Andreas Dilger [ 23/Nov/18 ] |
|
As I mentioned previously, there is no need to disable the xattr cache for trusted.som completely. Virtually all files in the filesystem will not be recently modified, so disabling the cache just means more overhead for the common case where the trusted.som xattr is valid. Also, the current implementation of LSOM is mainly intended to be used from the MDS by scanning the MDT disk filesystem directly, not to be used on the client, so adding overhead on the client to manage what is supposed to be "lazy" doesn't make sense. Even if the trusted.som xattr is fetched repeatedly, there is still a chance that it is out-of-date (e.g. file has not been closed, llsom_sync is not running, or MDS is an older version without LSOM), so we can't ever rely on it to be completely accurate, and shouldn't try too hard to make it so. The file size will normally be accurate shortly after close, it is only the blocks count which may be inaccurate. If the application depends on the blocks count to be relatively accurate, then the userspace application should check something like:
struct lustre_som_attrs lsom;
rc = lgetxattr(file, "trusted.som", &lsom, sizeof(lsom));
size = lsom.lsa_size;
blocks = lsom.lsa_blocks; /* what unit is "lsa_blocks" in? it should be documented */
/* if xattr fetch failed or is short, or if we care about blocks being relatively accurate */
if (rc < sizeof(lsom) || size > 1048576 && lsom.lsa_blocks == 0 && lsom.lsa_valid != SOM_FL_STRICT) {
/* LSOM data is likely stale (unless file is totally empty) */
fd = open(file, O_RDONLY);
if (fd >= 0) {
rc = fstat(fd, st);
size = st.st_size;
blocks = st.st_blocks;
/* closing the file will update the LSOM data for next time */
close(fd);
}
}
Two lighter-weight solutions exist that will still allow accurate trusted.som xattrs to be fetched to the client:
|
| Comment by Li Xi [ 26/Nov/18 ] |
|
I think at least currently, there is no requirement to use the client side interface to acess the LSOM. So, I'd suggest to delay the implement of this API until we started to see some real requirement for it. After all, LSOM is designed for MDT scanning, not client side accessment. And I think Yingjin's patch is enough to fix the test problem for now. |
| Comment by Andreas Dilger [ 15/May/20 ] |
|
Now that the statx() patch is landing, I think this patch should be abandoned, and this ticket closed. |
| Comment by Andreas Dilger [ 09/Mar/22 ] |
|
It turns out that the trusted.som xattr is not used directly on the client for anything except "lfs getsom", so keeping it in the xattr cache doesn't help any real workload, and only serves to confuse tests that are using getsom and see a cached value that is stale. I've un-abandoned patch https://review.whamcloud.com/33711 " |
| Comment by Gerrit Updater [ 11/Jul/22 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/33711/ |
| Comment by Peter Jones [ 11/Jul/22 ] |
|
Landed for 2.16 |
| Comment by Gerrit Updater [ 09/Feb/23 ] |
|
"Jian Yu <yujian@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/49952 |
| Comment by Gerrit Updater [ 28/Mar/23 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/49952/ |