Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Gofer filesystem does not support hard links #6739

Open
ayushr2 opened this issue Oct 14, 2021 · 1 comment
Open

Gofer filesystem does not support hard links #6739

ayushr2 opened this issue Oct 14, 2021 · 1 comment
Labels
area: filesystem Issue related to filesystem no-auto-close type: bug Something isn't working

Comments

@ayushr2
Copy link
Collaborator

ayushr2 commented Oct 14, 2021 •
edited
Loading

Description

The gofer filesystem does not support hard links correctly.

The gofer client uses different dentry structs for hard linked files (which is correct) however hard linked files have the same inode. But the gofer client embeds the inode fields in the dentry struct itself. Hence inode properties for hard linked files can diverge because of this duplication.
Hard linked files also have different mappings by virtue of having separate dentries.

The solution would be to create a new inode abstraction in the gofer client. A dentry would then point to an inode. Dentries representing hard linked files will point to the same inode hence fixing the issue mentioned above.

Steps to reproduce

This bug can manifest in various ways (with an exclusive gofer mount). Create hard link to a file, change the ownership/time/size or any attribute of one file and see that the other does not reflect the change.

You can also write to one and read from the other and see that the data is not present.
@ayushr2 ayushr2 added type: bug Something isn't working area: filesystem Issue related to filesystem labels Oct 14, 2021
@ekzhang ekzhang mentioned this issue Mar 13, 2023
Closed
@github-actions
Copy link

A friendly reminder that this issue had no activity for 120 days.

@github-actions github-actions bot added the stale-issue This issue has not been updated in 120 days. label Sep 13, 2023
@ayushr2 ayushr2 added no-auto-close and removed stale-issue This issue has not been updated in 120 days. labels Sep 13, 2023
@ayushr2 ayushr2 mentioned this issue Mar 12, 2024
Closed
@copybara-service copybara-service bot mentioned this issue Mar 13, 2024
Merged
copybara-service bot pushed a commit that referenced this issue Mar 13, 2024
@ayushr2 @gvisor-bot
Error out when attempting to hard link synthetic files in non-synthet…
f8f1219 
…ic dir.

This is consistent with attempting to hard link a synthetic file in a synthetic
directory (fs.LinkAt() => fs.doCreateAt(..., createInSyntheticDir=nil)), which
should result in error.

Due to #6739, fsimpl/gofer does not support hard links correctly since it does
not have an inode abstraction. All inode fields are embedded in the dentry.
So inode attributes and file data of hard linked files can go out of sync.
In remote_revalidating mode, at least the inode attributes of non-synthetic
files are refreshed on each access. But since synthetic files don't exist on
the remote filesystem, there is no way to sync hard linked synthetic dentries.
We'd have to wait for #6739 to be resolved to add such support. For now
returning EOPNOTSUPP is most consistent.

Fixes #10143.

PiperOrigin-RevId: 615537813
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: filesystem Issue related to filesystem no-auto-close type: bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ayushr2