Project

General

Profile

Actions

Bug #23873

closed

cephfs does not count st_nlink for directories correctly?

Added by Danny Al-Gaaf almost 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
High
Category:
Correctness/Safety
Target version:
% Done:

0%

Source:
other
Tags:
Backport:
luminous
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
Client, kceph
Labels (FS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

Not sure if this behavior is by intention, but if you create a empty directory on cephfs and call stat on the directory it returns '1' for st_nlink while other filesystems like XFS, EXT3/4 and even NFS return '2' for hard links.

How to reproduce:
1) mount cephfs
2) create directory on cephfs
3) call "stat" on the directory and check for "Links"
4) outcome: cephfs=1 but e.g. XFS=2

Tested with ceph version 12.2.1-361-gaea79b8b7a (aea79b8b7a65a8ca5cc1de84c7fe7d99eaa72ec0) luminous (stable)


Related issues 1 (0 open1 closed)

Copied to CephFS - Backport #23987: luminous: cephfs does not count st_nlink for directories correctly?ResolvedDanny Al-GaafActions
Actions #1

Updated by Patrick Donnelly almost 6 years ago

  • Category set to Correctness/Safety
  • Assignee set to Patrick Donnelly
  • Priority changed from Normal to High
  • Target version set to v13.0.0
  • Source set to other
  • Backport set to luminous
  • Component(FS) Client, kceph added
Actions #2

Updated by Patrick Donnelly almost 6 years ago

  • Status changed from New to Fix Under Review
Actions #3

Updated by Zheng Yan almost 6 years ago

If I remember right, this is not required by POSIX (btrfs does not do this). how NFS behaves depends on the exported filesystem. Besides, directory's nlink is not always 2 in EXT4/XFS. It is "2 + <number of subdirs>".

Actions #4

Updated by Patrick Donnelly almost 6 years ago

Zheng Yan wrote:

If I remember right, this is not required by POSIX (btrfs does not do this). how NFS behaves depends on the exported filesystem. Besides, directory's nlink is not always 2 in EXT4/XFS. It is "2 + <number of subdirs>".

Yes, I was thinking about that more today. "2 + <subdir count>" makes sense. hard-coded 2 definitely does not.

I didn't see anything in the spec about this either so I'm inclined to drop this. Danny, does this break something in particular or just an oddity?

Actions #5

Updated by Peter Mauritius almost 6 years ago

The Dovecot mail server does not work properly, if mailbox files are stored on cephfs and a mailbox prefix is configured. Dovecot is using a heuristic based on st_nlink to compute the number of subdirectories. The code assumes "2 + <subdir count>".

Actions #6

Updated by Jeff Layton almost 6 years ago

Peter Mauritius wrote:

The Dovecot mail server does not work properly, if mailbox files are stored on cephfs and a mailbox prefix is configured. Dovecot is using a heuristic based on st_nlink to compute the number of subdirectories. The code assumes "2 + <subdir count>".

Then Dovecot is broken.

POSIX is mostly silent on the subject of st_nlink value for directories, and it can vary widely between filesystems. This is something that is really difficult to determine in a reliable way in many cases -- particularly on network filesystems.

I'd advise the Dovecot developers to re-think that heuristic. One should really not rely on the st_nlink value for directories to mean anything useful.

Actions #7

Updated by Patrick Donnelly almost 6 years ago

  • Status changed from Fix Under Review to Pending Backport
Actions #8

Updated by Nathan Cutler almost 6 years ago

  • Copied to Backport #23987: luminous: cephfs does not count st_nlink for directories correctly? added
Actions #9

Updated by Nathan Cutler almost 6 years ago

  • Status changed from Pending Backport to Resolved
Actions

Also available in: Atom PDF