A scratch file system we purge data from aggressively has had its MDT usage growing unexpectedly. This appears to be a result of a change in model behavior to create a lot of symlinks. The symlinks cannot be resolved by our robinhood server because the targets do not exist on it.

--entry-info reports "couldn't get id" for the links:

==========

[root@sherwood mysql]# rbh-report --entry-info /cscratch/short/<USER>//baseline/stmp_2015050112_gdas_eomn01/mem008/crtm_coeffs/amsr2_gcom-w1.TauCoeff.bin -f cscratch
Using config file '/etc/robinhood.d/cscratch.cfg'.
Couldn't get id for /cscratch/short/<USER>//baseline/stmp_2015050112_gdas_eomn01/mem008/crtm_coeffs/amsr2_gcom-w1.TauCoeff.bin: No such file or directory

==========

The link indeed exists, but the target file cannot be reached from sherwood:

==========

[root@sherwood mysql]# ls -l /cscratch/short/<USER>//baseline/stmp_2015050112_gdas_eomn01/mem008/crtm_coeffs/amsr2_gcom-w1.TauCoeff.bin lrwxrwxrwx 1 <USER> domain users 137 Jun 30 12:29 /cscratch/short/<USER>//baseline/stmp_2015050112_gdas_eomn01/mem008/crtm_coeffs/amsr2_gcom-w1.TauCoeff.bin -> /usr/local/jcsda/NESDIS-JCSDA/tools_R2O/nwpro
d_2016q1/GFS_LIBs/CRTM_REL-2.2.3_BIG/fix/TauCoeff/ODPS/Big_Endian/amsr2_gcom-w1.TauCoeff.bin

==========


I manually deleted a little over 40 million symlinks for now but this would certainly be something we'd want to work going forward. Is there a good way we can work around this issue?

We're running 3.1 on both a centos 6 server and a centos 7 server, both with lustre 2.10.2.

Best,
Jesse Stroik

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
robinhood-support mailing list
robinhood-support@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/robinhood-support

Reply via email to