Centos/dev/mapper/cl-root 100% Solutions

Originally to be installed on the virtual machine grpc for testing, the results found that gradle can not be used, and then to install Gradle, install gradle before installing Sdkman, and the official website Sdkman installed half a day did not respond, so think of Yum try, results

This was also the case when I ran the spark recommendation system, but I found

There is still a lot of space, so use DF to see

/dev/mapper/cl-root 100%, Instant Meng forced, because I do not know what this is, online some, probably know the liunx system with the physical space allocation, LIUNX itself will have a log, I think it may be the log system occupies too much space.

The discovery is not big, the cache and log are checked, did not find any large files, eventually had to look for large files in the global. Find/-xdev-size +100m-exec ls-l {} \;

Found the culprit, some time ago, in the virtual machine MySQL database synchronization test, resulting in a large number of files into MySQL, do not want to go to MySQL one by one delete library, so the violence deleted the library,

So Yum can use the

Summarize:

/dev/mapper/cl-root 100%
The system will not go down after the file system is fully occupied;
When restarting the service, the original/var/log/message file can be recorded, but after the file system is full, the log is no longer recorded;

After the file system is full, the service can still be restarted;

After the file system fills up, the results are not available using Yum and RPM, and the results are always stuck;

After the file system is full, you can log in to the system so that you can execute commands and still provide remote link services.
After the disk space is cleaned up, the log system resumes its normal operation.

Centos/dev/mapper/cl-root 100% Solutions