[LU-4893] allow unlink for dangling entry Created: 12/Apr/14 Updated: 12/Dec/17 Resolved: 12/Dec/17 |
|
| Status: | Closed |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.6.0 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Richard Henwood (Inactive) | Assignee: | WC Triage |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | dne, dne2 | ||
| Severity: | 3 |
| Rank (Obsolete): | 13529 |
| Description |
|
It should be possible for a regular user to delete a file or directory if the remote MDT is available but the object does not exist using normal tools like rm and rmdir. Normally, "lfs rm_entry" is only allowed by the root user, and this will not delete remote entries even of they exist. |
| Comments |
| Comment by Andreas Dilger [ 04/Dec/14 ] |
|
This isn't really specific to DNE2 (striped directories), it also applies to DNE1 (remote directories). |
| Comment by Andreas Dilger [ 04/Sep/15 ] |
|
I recall the upstream kernel folks were unhappy with our ioctl (LL_IOC_REMOVE_ENTRY) to allow root to delete dangling entries like this. The problem with allowing non-root users to delete dangling entries is that it isn't possible to have proper permission checks for this, since the inode's UID/GID/ACL are on the remote (unavailable) MDT, and only the local permission of the directory can be used. For something like a striped /tmp directory with +S permissions this would allow any user to potentially disconnect a whole tree of files owned by another user. |
| Comment by Andreas Dilger [ 08/Sep/15 ] |
|
Oleg suggests to allow regular users to delete dangling subdirectories in directories that they own IFF the target MDT is online and available and reports that the directory is missing. |
| Comment by James A Simmons [ 01/Nov/17 ] |
|
In fact upstream hated it so much that LL_IOC_REMOVE_ENTRY has been deleted. Doesn't LFSCK replace this? |
| Comment by Andreas Dilger [ 07/Nov/17 ] |
|
This is needed in case some remote MDT is permanently removed, and the user/admin wants to delete the directory. While LFSCK could potentially fix this, that might take hours/days to scan and repair the whole filesystem depending on the size. Also, LFSCK will typically not repair components of the filesystem if some server is unavailable, on the assumption that the server will be restored. Otherwise, an ill-timed LFSCK run could clobber a large fraction of the filesystem if some OST or MDT is temporarily offline. |