https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-3932 Lustre <p>In current implementation, a catalog llog can only have ~4G entries in its lifetime which means HSM can only handle ~4G requests at most.</p> <p>We have to improve catalog. It seems reasonable for me to roll catalog index back when it reaches maximum, assuming that it's impossible to have ~4G entries on the same time.</p> LU-3932

HSM can only handle ~4G requests at most

Technical task LU-3647 Major Closed Won't Fix John Hammond Jinshan Xiong hsm Wed, 11 Sep 2013 17:57:08 +0000 Thu, 10 Dec 2020 20:35:32 +0000 Thu, 10 Dec 2020 20:35:27 +0000 Lustre 2.5.0 0 6 <p>After taking a further look at the implementation of catalog llog implementation, unlike plain llog, it reuses its index number. However, after the indices are reused, reading catalog entries will not be in the order when they were added.</p> <p>This doesn't seem to be a severe problem because we have ~4G slot anyway.</p> <p>I will drop the priority.</p> <p>After speaking to Jinshan, this will not be fixed.</p> <p>Andreas says that the catalog should store the catalog index for the first (or last) index that is used. When processing the ChangeLog, it should start at the first (or one after the last) catalog index so that the individual llog files are processed in order.</p> <p>It is worth noting that this only affects the case of the MDS crashes or is shut down while the first and last ChangeLog catalog llogs are straddling the start of the catalog. That would return ChangeLog entries in a slightly wrong order. That is not a problem for HSM, but may be for lustre-rsync and similar. </p> Development Rank 1|hzw1wf: Rank (Obsolete) 10389