You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
is there any possibility to determine which files are saved on which Lustre MDT in Robinhood?
We are using Robinhood in version 3.1 here. As far as I have investigated the documentation, rbh-command line tools and the database table schemas there is no information retrievable which would determine which file is saved on which MDT.
I have also checked the changelogs processed by Robinhood and there at least the MDT's are listed for the processed entries:
It is in the TODO things for years but it has not been a priority so far because there was no obvious use case (except for information purpose).
Do you have a use case in mind?
An idea could be to use a Robinhood policy for an automated inode migration between MDTs when the fill level of a MDT has reached a specific threshold.
Right. With Data on MDT, it is clear robinhood now has to monitor the MDS usage as well (previously it only checked OST usage), and keep track of MDT location the same way it previously kept track of OST before. Your point is very similar but it is for the inode usage. We keep this in mind for future develoments.
Hello,
is there any possibility to determine which files are saved on which Lustre MDT in Robinhood?
We are using Robinhood in version 3.1 here. As far as I have investigated the documentation, rbh-command line tools and the database table schemas there is no information retrievable which would determine which file is saved on which MDT.
I have also checked the changelogs processed by Robinhood and there at least the MDT's are listed for the processed entries:
ChangeLog | MDT0000: 7958205027 11CLOSE 1517902683.680415766 0x442 t=[0x5100027c0d:0x16:0x0] J=
ChangeLog | MDT0001: 4125235531 11CLOSE 1517902746.289858659 0x241 t=[0x50c000cf9e:0x7dbd:0x0] J=
So technically I could be possible to save that information in the ENTRIES table, which would be very helpful for us and in general I assume.
Best regards
Gabriele
The text was updated successfully, but these errors were encountered: