2

I'm having an issue with a circular directory structure warning produced by du and find on my CentOS servers.

I have two FreeNAS servers exporting several datasets via NFS which are mounted on the CentOS servers in a hierarchical structure. For example:

FreeNAS datasets: u, home, user1, user2 CentOS file hierarchy: /u /u/home /u/home/user1 /u/home/user2 

When I run du and find anywhere within this tree, they get upset and tell me that there is a circular file structure.

find: File system loop detected; './u/home/user1' is part of the same file system loop as '/u/home'. du: WARNING: Circular directory structure. This almost certainly means that you have a corrupted file system. NOTIFY YOUR SYSTEM MANAGER. The following directory is part of the cycle: './u/home/user1' 

I think this warning happens because the mount points for each dataset all have the same inode number. However, I think this is not a problem, because each is it's own filesystem.

Am I correct or is there actually a problem here? If there is a problem, how do I fix it? And if there isn't, can I tell find and du to not report these warnings?

5
  • Can you give more details on the NAS disk and export configuration? How the CentOS machine mounts these shares? Via NFS? Commented May 21, 2015 at 8:36
  • The inode number does not matter, at least on Linux. It is expected that different NFS exports could have files which share the same inode number. This is possible because an export is a filesystem, and inodes are only unique to the filesystem. Both Linux NFS Server and Client can handle files in different NFS exports with the same inode number (at least in RHEL6 and 7). Commented May 21, 2015 at 11:46
  • What's the exact message you get? Is it the directory <name> contains a readdir loop? This can happen because the NFS Server returns the same READDIR cookie for two different files in the same directory. If so, this would be a bug in the NFS Server. Commented May 21, 2015 at 11:49
  • Thanks for your input. The exports are NFS exports. I've edited the question to include that information and also the warnings. Commented May 21, 2015 at 15:01
  • There is no way to know because you only provided a relative path, and did not tell us what it is relative to! Show the absolute path, and also the list of mounts in /proc/self/mounts. Commented May 21, 2015 at 16:59

0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.