2024-07-16T13:21:34.584Z | <Frank Troost> 👋 Hello, team! Thnx for making ceph! |
2024-07-16T13:46:06.382Z | <Frank Troost> i have soms strange case.. maibe someone is willing to think with me. I have a completely healthy ceph file system running. All data on the cephfs is visible when browsing through the cephfs, no missing data. But all the data on the cephfs file system are broken when opening the files. |
2024-07-16T13:47:22.986Z | <Frank Troost> there is also a .snap of half a year ago, same behavior, browsable, all files broken. |
2024-07-16T19:00:18.937Z | <Hutch> Hi All, I've been following this bug report for some time now and have not been getting any responses back from it. im just looking for someone to take a look into it so we can get it resolved
I currently have a customer experiencing this issue which is stopping them from accessing there data
<https://tracker.ceph.com/issues/50719> |
2024-07-16T19:37:26.634Z | <Wes Dillingham> I have a few large OMAP objects in my cephfs metadata pool. All of a sudden. Slightly over the 200,000 threshold. I have found the object name from the ceph.log and I am trying to figure out if I can map that object back to a directory in the FS. I am guessing it is related to a directory with many files in it, but not 100%. If I could map the object to a directory I could maybe determine why that object has so many keys. Is this possible? Not finding much help in the docs or mailing list at the moment. Thanks for any leads. |