HSM _not only_ small fixes and to do list goes here
(LU-3647)
|
|
| Status: | Closed |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.5.0 |
| Fix Version/s: | None |
| Type: | Technical task | Priority: | Major |
| Reporter: | Jinshan Xiong (Inactive) | Assignee: | John Hammond |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | hsm | ||
| Rank (Obsolete): | 10389 |
| Description |
|
In current implementation, a catalog llog can only have ~4G entries in its lifetime which means HSM can only handle ~4G requests at most. 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. |
| Comments |
| Comment by Jinshan Xiong (Inactive) [ 11/Sep/13 ] |
|
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. This doesn't seem to be a severe problem because we have ~4G slot anyway. I will drop the priority. |
| Comment by Jodi Levi (Inactive) [ 19/Mar/14 ] |
|
After speaking to Jinshan, this will not be fixed. |
| Comment by Jinshan Xiong (Inactive) [ 23/Jan/15 ] |
|
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. |
| Comment by Andreas Dilger [ 26/Jan/15 ] |
|
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. |
[LU-3932]