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-1651 Lustre <p>We need to confirm that changelogs supports multiple readers like it is supposed. Changelog records need to be retained until all readers have seen them, and stale readers need to be evicted at some point so we can flush the logs. </p> LU-1651

Audit multireader support changelogs

Bug Major Closed Fixed John Hammond Robert Read Fri, 22 Oct 2010 16:58:33 +0000 Wed, 20 Apr 2016 13:54:13 +0000 Wed, 20 Apr 2016 13:54:13 +0000 0 6 <p>Changelog supports a set of interfaces for recording lustre namespace changes, reading such records, purging specified record(s), and so on. Currently, all such records will not be purged automatically, even if someone has read such record(s) already (maybe for replicate the lustre system). Means such records can be read many times before they are purged explicitly.</p> <p>If you think some old records are not useful (since you have replicated current lustre system already) or you just want to free up some space, then you can purge some records as following:<br/> "lfs changelog_clear &lt;mdtname&gt; &lt;id&gt; &lt;endrec&gt;"<br/> Such command indicates that changelog records up to &lt;endrec&gt; are no longer of interest to consumer &lt;id&gt;, removing them. An &lt;endrec&gt; of "0" means removing all records.</p> <p>On the other hand, when all changelog users deregistered, then changelog will be off and all records will be purged automatically under such case, even though no one used them yet. (I am not sure it is reasonable, but it is the current implementation)</p> <p>Lustre implements a small rsync tools &#8211; lustre_rsync, which uses changelog as the backend support. When lustre_rsync runs, it will purge (by calling ioctl with "OBD_IOC_CHANGELOG_CLEAR" explicitly) the old changelog of 100 records each time periodically.</p> <p>So the feature to automatically flush log records once they've been consumed by all readers has not been implemented, and lustre_rsync is a destructive reader of changelogs. This is very helpful, thanks.</p> <p>Changelog only supplies the interfaces for recording/reading lustre namespace changes. It is the HSM engine's duty to decide (according to the so called 'policy') which change(s) should be recorded and how long the record(s) should be retained, just like lustre_rsync does.</p> <p>Right, the application decides when to mark the records as "consumed," but if there is more than one reader then records should not be deleted until all of the readers have marked them as "consumed."</p> <p>Unfortunately, the current implementation of changelog has no idea about "consumed", it neither knows nor cares about how many reader want to access the record(s). But the application can keep the "consumed" conception by keeping the next record index to be read. Anyway, even if some reader had not accessed related changelog record(s) yet, he can not prevent others to purge such record(s) explicitly.</p> <p>Can you estimate what needs to be done to add state to changelogs to allow keeping track of multiple registered readers and to only flush records that have been marked consumed by all the readers? This will require maintaining persistent state for each client, and we'll need options for allow stale readers to be "evicted" if the logs reach a certain size or after a period of time of inactivity from that client. We'll also need the ability to stop updates on the filesystem of the log fills up to support, say, a high availability replication application. </p> <p>This is basic idea for changelog enhancement. We can implement it within one month. There are some uncertain issues mentioned in the document, need more discussion.</p> <p>Each registered changelog reader has a persistent minimum record index (<tt>mcud_minrec</tt>) which can be updated by calling <tt>lfs changelog_clear</tt>. This also purges changelog records with index lower than the all of the minimum record indexes.</p> <p>So this is fixed and the ticket can be closed.</p> LU-1652 Development Rank 1|hzus3b: Rank (Obsolete) 2213 Severity