Details
-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
Lustre 1.8.8
-
RHEL 6.2
-
3
-
5933
Description
End customer is Lunds University, who has support for our hardware and lustre through us. I have done some basic troubleshooting with them, had them try rm -f, and unlink, but they cannot perform any operations on the files. I suggested the run a file system check, but they cannot take the filesystem down for that. They realize they may have hit a bug, and upgrading could fix the issue, but they would really like to find a way to remove the files right now without going through that yet. I'll attach the logs I have, and also below you can find the last email I have from the customer, which provides a good summary for the issue.
-----From Customer-----
The problematic files were sockets/pipes defined on a server not using
Lustre, and rsynced into Lustre from that server. That went just fine.
The next step we did was copying the files from one part of our Lustre
fs to another, and thereby acquiring proper ACLs. This has worked fine
for all normal files, directories and links, but these sockets have
turned into something broken, that we can't remove.
A little googling brought this up:
http://jira.whamcloud.com/browse/LU-784
As we're on 1.8.8, it seems very similar to our problem. What I'd like
to know, is if there's someone from WhamCloud (or Intel, these days...)
that can give us any hints on what we can do, other than upgrading to
Lustre 2.X? I'm guessing there are ways to clear the faulty inodes
directly from the MDS and/or OSTs, but I'd need some guidance for that.
We'd really like to have this fixed before talking about a Lustre upgrade...
Attachments
Issue Links
- is duplicated by
-
LU-784 Cannot access named pipes or sockets with Posix-ACLs
- Resolved