因为并发控制不当，几百个应用的覆盖率数据反复不断上传，导致磁盘不久就满了。应用中凡是牵扯到文件IO的全部报错。由于mysql也安装在这台linux服务器，当对数据库插入数据时也会报错。遭遇的几个问题，详述如下：
1、应用有写入zip文件的行为，当磁盘满时，会导致写入的zip文件不完整，导致后续读zip文件异常：
- Cause By：
- java.io.IOException: Truncated ZIP file
- org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:300)
- java.io.InputStream.read(InputStream.java:85)
- org.apache.commons.compress.utils.IOUtils.copy(IOUtils.java:66)
- org.apache.commons.compress.utils.IOUtils.copy(IOUtils.java:47)
- com.esc.common.util.UnCompressFileUtils.unPackZipFile(UnCompressFileUtils.java:51)
- com.esc.tcc.service.impl.TccDataServiceImpl.saveEmEc(TccDataServiceImpl.java:94)
- sun.reflect.GeneratedMethodAccessor288.invoke(Unknown Source)
- sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
- java.lang.reflect.Method.invoke(Method.java:597)
- org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
2、无法向数据库表插入数据：
- Cause By：
- java.sql.SQLException: Disk is full writing './tcc_v40/tcc_p_a_msp_msp.MYD' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)
这种错误显然应该是极少遇到的，不过，倒是可以给测试人员提个醒，可以去测试这样一些情形，以确保应用在这样极端的情形下，依然有“正常”的表现，或者，给出合理的反馈信息。
线上故障，也有遭遇磁盘满的，比较典型的是因为配置更改，导致日志文件狂打印，把磁盘空间耗完，导致线上故障。提到日志打印，其实，也是一门学问，怎么打，在哪打，是否要打印完整堆栈？是否控制重复打？日志文件如何定时清理？等等。与本篇文章主题离的太远，不详细展开。
