<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I had the same problem with multi-mds. I solved it by freeing up a little space on OSDs, doing "recover dentries", truncating the journal, and then "fs reset". After that I was able to revert to single-active MDS and kept on running for a year until it failed on 13.2.2 upgrade :))<div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 6.11.2018, at 03:18, Rhian Resnick <<a href="mailto:xantho@sepiidae.com" class="">xantho@sepiidae.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Our metadata pool went from 700 MB to 1 TB in size in a few hours. Used all space on OSD and now 2 ranks report damage. The recovery tools on the journal fail as they run out of memory leaving us with the option of truncating the journal and loosing data or recovering using the scan tools. <div class=""><br class=""></div><div class="">Any ideas on solutions are welcome. I posted all the logs and and cluster design previously but am happy to do so again. We are not desperate but we are hurting with this long downtime. </div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Nov 5, 2018 at 7:05 PM Sergey Malinin <<a href="mailto:hell@newmail.com" class="">hell@newmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class="">What kind of damage have you had? Maybe it is worth trying to get MDS to start and backup valuable data instead of doing long running recovery?<div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 6.11.2018, at 02:59, Rhian Resnick <<a href="mailto:xantho@sepiidae.com" target="_blank" class="">xantho@sepiidae.com</a>> wrote:</div><br class="m_3856987895038074971Apple-interchange-newline"><div class=""><div dir="auto" class="">Sounds like I get to have some fun tonight. </div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Nov 5, 2018, 6:39 PM Sergey Malinin <<a href="mailto:hell@newmail.com" target="_blank" class="">hell@newmail.com</a> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">inode linkage (i.e. folder hierarchy) and file names are stored in omap data of objects in metadata pool. You can write a script that would traverse through all the metadata pool to find out file names correspond to objects in data pool and fetch required files via 'rados get' command.<br class="">
<br class="">
> On 6.11.2018, at 02:26, Sergey Malinin <<a href="mailto:hell@newmail.com" rel="noreferrer" target="_blank" class="">hell@newmail.com</a>> wrote:<br class="">
> <br class="">
> Yes, 'rados -h'.<br class="">
> <br class="">
> <br class="">
>> On 6.11.2018, at 02:25, Rhian Resnick <<a href="mailto:xantho@sepiidae.com" rel="noreferrer" target="_blank" class="">xantho@sepiidae.com</a>> wrote:<br class="">
>> <br class="">
>> Does a tool exist to recover files from a cephfs data partition? We are rebuilding metadata but have a user who needs data asap.<br class="">
>> _______________________________________________<br class="">
>> ceph-users mailing list<br class="">
>> <a href="mailto:ceph-users@lists.ceph.com" rel="noreferrer" target="_blank" class="">ceph-users@lists.ceph.com</a><br class="">
>> <a href="http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com" rel="noreferrer noreferrer" target="_blank" class="">http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com</a><br class="">
> <br class="">
<br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></div></blockquote></div>
</div></blockquote></div><br class=""></div></body></html>