[LU-5044] not include the .lustre directory in readdir output Created: 10/May/14  Updated: 09/Dec/17  Resolved: 01/Dec/14

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.6.0
Fix Version/s: Lustre 2.7.0, Lustre 2.5.4

Type: Bug Priority: Major
Reporter: Di Wang Assignee: Di Wang
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Related
is related to LU-5955 llapi_semantic_traverse() and lfs fin... Resolved
Severity: 3
Rank (Obsolete): 13937

 Description   

Comments from Andreas

"I noticed that ".lustre" now appears in "ls -a" output, but I don't think that is supposed to happen. It might have been added when .lustre was created as a real inode in 2.4 or so?

This causes a problem because backup and other filesystem scanning tools will want to go into .lustre and read all the files there, and may also want to restore them after a crash, which could cause problems.

I think readdir needs to be fixed to not include the .lustre directory in readdir output. "



 Comments   
Comment by nasf (Inactive) [ 10/May/14 ]

Currently, .lustre/lost+found is used for LFSCK, if we want to make .lustre to be invisible for readdir, then we need some especial tools to read the .lustre, then the administrator can check the orphans under .lustre/lost+found.

Comment by Di Wang [ 10/May/14 ]

http://review.whamcloud.com/10286

Comment by Robert Read (Inactive) [ 12/May/14 ]

It would be good to include tests (if we don't have them already) that other uses of .lustre, such as open by fid from userspace, still work as well.

Comment by John Hammond [ 13/May/14 ]

Is this really a problem? Shouldn't we wait for some sign that this is causing an issue for some real program before we go adding special cases?

Comment by Robert Read (Inactive) [ 13/May/14 ]

>Is this really a problem? Shouldn't we wait for some sign that this is causing an issue for some real program before we go adding special cases?

I suppose it means backup and recursive copy tools need to be configured to skip it, but other filesystems have similar "magic" directories that shouldn't be copied, so it's not that odd. I agree it would be simpler to leave it alone.

Comment by John Hammond [ 22/Jul/14 ]

See also http://review.whamcloud.com/#/c/11186/.

Comment by Andreas Dilger [ 25/Nov/14 ]

I'd like to land the 11186 patch to b2_5 so that we can fix LU-5955 on the client.

Comment by Jodi Levi (Inactive) [ 01/Dec/14 ]

Patch landed to Master.

Generated at Sat Feb 10 01:48:03 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.