阿里云内容设计中心

OSS Java SDK依赖下列包：

1. aliyun-sdk-oss-2.2.1.jar
2. hamcrest-core-1.1.jar
3. jdom-1.1.jar
4. commons-codec-1.9.jar
5. httpclient-4.4.1.jar
6. commons-logging-1.2.jar
7. httpcore-4.4.1.jar
8. log4j-1.2.15.jar

其中log4j-1.2.15.jar是可选的，需要日志功能的时候加入该包，其它包都是必需的。

• 解决方法

在您的工程中加入OSS Java SDK依赖的包。加入方法如下：

1. 如果您的工程在Eclipse中，请参见Java SDK使用手册中的安装方式二。

2. 如果您的工程在Ant中，请把OSS Java SDK依赖的包放入工程的lib目录中。

3. 如果您直接使用.javac或.java文件，请使用-classpath或-cp命令指定OSS Java SDK依赖的包路径，或把OSS Java SDK依赖的包放入classpath路经下。

各个ftp客户端一般都有超时设置，可以设置为不超时。以FileZilla工具为例，在设置->连接里，可以将超时设置为0。

由于ftp协议的控制端口和数据端口不同，当ftpserver工作在被动模式下，每当需要传输数据时，ftpserver会打开1个随机端口，等待客户端来连接。所以当ftpserver所在机器有端口限制时，可能会导致数据无法正常传输。

解决办法是当运行ftpserver.py时，通过指定--passive_ports_start和--passive_ports_end参数来设置本地端口的起止范围，然后将该范围的端口都打开。

原因一般是Bucket根目录下的文件数或文件夹过多。 登录ftp后，ftpserver会尝试将Bucket根目录下的所有文件／文件夹List出来，每次可以List出1000个文件／文件夹。如果根目录下有100万以上的文件／文件夹，则会导致1000次以上的http请求，非常容易超时。

此类错误通常是因为本地的中文编码有问题。在将要运行start.sh的终端中输入下面的命令，然后再重新启动即可。

$ export LC_ALL=en_US.UTF-8; export LANG="en_US.UTF-8"; locale

问题分析：程序扫描ossfs挂载的目录，会转换成向OSS的请求。如果请求次数很多，会产生费用。

解决方案：可以通过auditd工具查看是哪些进程扫描了OSS挂载的目录。具体步骤如下：

1、安装auditd并启动。

sudo apt-get install auditd
sudo service auditd start

2、将OSS挂载的目录设置为监视目录，例如挂载目录为/mnt/ossfs。

auditctl -w /mnt/ossfs

3、在auditlog中查看是哪些进程访问了这个目录。

ausearch -i | grep /mnt/ossfs

4、修改参数，跳过程序扫描。

例如通过auditlog查到是 updatedb 扫描了所挂载的目录，可以通过修改/etc/updatedb.conf让它跳过。具体做法是：

a.在RUNEFS =后面加上fuse.ossfs。

b.在PRUNEPATHS =后面加上挂载的目录。

问题分析：ossfs默认会缓存文件的元信息（包括大小/权限等），这样就不需要每次ls的时候向OSS发送请求，加快速度。 如果用户通过其他程序（例如SDK/官网控制台/ossutil等）对文件进行了修改，由于缓存的关系，ossfs没有及时更新，导致与其他工具看到的文件信息不一致。

解决方案：可以在挂载的时候加上参数-omax_stat_cache_size=0，禁用元数据缓存功能。每次ls时，都会向OSS 发送请求，获取最新的文件信息。

问题分析：假设一个目录下有N个文件，那么ls该目录至少需要N次OSS http requests。在文件非常多的时候，这可能造成严重的性能问题。

解决方案： 通过-omax_stat_cache_size=xxx参数增大stat cache的size，这样第一次ls会较慢，但是后续的ls就快了，因为文件的元数据都在本地cache中。这个值默认是1000，大约消耗4MB内存，请根据您机器内存大小调整为合适的值。

问题分析：上传文件时，ossfs通过查询/etc/mime.types中的内容来设置文件的Content-Type。当该文件不存在时，默认设置为application/octet-stream。

解决方案：请检查这个文件是否存在，如果不存在，则需要添加。

• 通过命令自动添加mime.types文件

1、Ubuntu系统： 使用sudo apt-get install mime-support命令添加。

2、CentOS系统： 使用sudo yum install mailcap命令添加。

• 手动添加mime.types文件

1、创建mime.types文件

vi /etc/mime.types

2、添加需要的格式，每种格式一行，每行格式为application/javascript js。

添加完成后，需要重新挂载OSS。

问题分析：403错误通常是访问权限问题导致的。以下情况会导致touch一个文件出现403报错。

• 该文件为归档类型文件，touch时会出现403报错。

• 使用的Accesskey无该存储空间的操作权限。

解决方案：

• 归档类型文件问题：将文件解冻后访问。

• 权限问题：为使用的Accesskey对应的账号配置正确的权限。

问题分析：ossfs上传大文件时，是通过分片来上传的。分片大小默认为10MB，分片最大数量为1000个。

ossfs在上传文件时会写一些临时缓存文件到/tmp目录下，在写这些文件之前需要先判断/tmp目录所在的磁盘可用空间是否小于用户上传的文件总量，若判断磁盘可用空间小于用户上传文件总量，就会出现本地磁盘可用空间不足的报错。以下场景会导致磁盘可用空间不足的报错：

• 场景一：磁盘可用空间本身小于用户上传文件总量。例如磁盘可用空间是200GB，上传的文件是300GB。

• 场景二：分片大小和上传线程数量的参数设置错误。例如磁盘可用空间是300GB，需上传的文件是100GB。因操作错误，multipart_size被设置成了100GB，上传线程数量是5。此时ossfs判断上传的文件就是100GB*5=500GB，超过磁盘安全空间了。

解决方案：

• 场景一：增大磁盘可用空间。

• 场景二：分片大小正常单位是MB，最大数量是1000，不要将分片大小设置过大。

问题分析：ossfs与rsync同步使用本身会出现问题。此案例中，用户是对一个141GB的大文件进行cp操作，使磁盘读写处于非常高的负载状态，从而产生此报错。

解决方案：如果想要将oss文件下载到本地ECS ，或者本地上传到ECS ，可以通过ossutil的分片上传、下载进行操作。

问题分析：input/output error都是捕获到系统磁盘的错误而产生的报错，可以查看出现报错时，磁盘读写是否存在高负载的情况。

解决方案：可以增加分片参数，控制文件读写。使用ossfs -h命令可以查看分片参数。

问题分析：根据Message判断，错误原因是Endpoint指定错误，有以下两种可能性： Bucket和Endpoint不匹配。 Bucket所属UID和实际的Accesskey对应的UID不一致。

解决方案：确认正确的配置信息并修改。

问题分析：

1. 开启ossfs的debug日志，加上-d -o f2参数，ossfs会把日志写入到系统/var/log/message。

2. 分析日志，发现ossfs在listbucket、listobject申请内存过多，触发了系统的oom。

说明 listobject是发起http请求到OSS获取文件的meta信息，如果客户的文件很多，ls会消耗系统大量内存来获取文件的meta。

解决方案：

• 通过-omax_stat_cache_size=xxx参数增大stat cache 的 size，这样第一次ls会较慢，但是后续的ls速度会提高，因为文件的元数据都在本地cache中。这个值默认是1000，约消耗4MB内存，请根据您机器内存大小调整为合适的值。

• ossfs在读写时会占用磁盘写大量的temp cache ，和Nginx差不多，可能会导致磁盘可用空间不足，需要经常清理。

• 使用ossutil替代ossfs，非线上敏感业务可以使用ossfs ，要求可靠性、稳定性的建议使用ossutil。

问题分析：请检查您的Bucket中，是否存在名称含有不可见字符的Object。文件系统对文件名和目录名有严格的限制，因此会收到上述错误。

解决方案：用其他工具对这些Object重命名后，ls就能正确显示目录内容了。

问题分析：当默认情况下，ossfs只能挂载到空目录下。当试图挂载到非空目录下时，会提示上述错误。

解决方案：切换到一个空目录下重新挂载。如果还是需要挂载到该目录下，挂载时增加 -ononempty 参数。

问题分析：这是fuse的一个Bug，它要求当前用户对当前目录（非挂载目录）有读权限。

解决方案：通过cd命令切换到到一个有读权限的目录，再运行ossfs命令。

问题分析：未创建该目录导致的。

解决方案：先创建对应的目录，之后再进行挂载操作。

问题分析：这种问题是系统中存在老版本的fuse，与ossfs里的依赖版本冲突了。

解决方案：请先使用相关的包管理器卸载fuse，再重新安装ossfs。

增量模式是采用对比文件最后修改时间来判断文件是否为增量的。Linux的mv，Windows的cp、mv以及rsync带-t或者-a参数等操作是不会修改文件的最后修改时间的，这些操作修改的文件是不会被扫描到，所以在迁移时会被忽略。

开启增量模式，本地删除后OSS上不会被删，删除操作不会被同步。

如果是配置的内网域名，将不收取流量费用，但访问次数的费用是依旧计费的。

目前不支持代理。

不可以，srcPrefix只支持目录或者前缀级别，不支持单独指定文件。

问题分析：使用的对应命令没有安装，请根据系统使用yum、apt-get或zypper 命令安装相应的命令。

问题分析：

• OSS控制台的Bucket数据量是延迟1~2小时更新的。

• Linux系统的du命令统计的是块大小，会比实际文件要大。您可以使用 ls -lR <目录绝对路径> | grep "-rw" | awk '{sum+=$5}END{print sum}'。命令统计本地目录的真实大小。

拍云对SDK访问间隔做了限制，如果访问稍微快一点就会进行限速。请联系又拍云的客服放开限制。ossimport本身会对这种情况进行重试。

填写又拍云的操作员账号和密码 。

问题分析：首先查看任务运行日志。

[2016-07-21 10:21:46] [INFO] [name=YoupaiList, totalRequest=1729925, avgLatency=38,
          recentLatency=300000]

• 如果这条日志中recentLatency小于或等于30000，表示在正常List文件。又拍云List过程比较慢，一般都会超过30秒的超时时间。30秒内List出几个文件就返回几个文件，这种情况等任务慢慢List完成就可以了。

• 如果recentLatency很小，一般是账号密码填写错误。因为又拍的SDK出错只返回null，并不返回错误结果，所以只能先通过抓包的方式获得又拍云返回的错误码进行排查。

问题分析：如果之前提交过迁移任务，任务被中止后修改Job配置文件是不会生效的。

解决方案：使用clean命令清除之前的任务，待Job配置文件修改完成后重新提交任务即可。

问题分析：Master是先List出文件列表，之后按照文件列表做数据迁移。若List完成后，源端某些文件被删除，就会出现源端文件不存在的情况。这种文件会被跳过，并把文件输出在错误列表里。

问题分析：这种情况一般是配置文件错误或配置文件路径错误。

解决方案：

1. 正确配置conf/sys.properties中的配置项workingDir。

2. 若配置无问题，检查配置文件路径是否正确。

问题分析：

• srcPrefix填写错误，导致列举不出来文件。

• srcPrefix下只有目录，没有文件，因为目录概念是OSS模拟出来的，不会被真正上传。

解决方案：填写正确的srcPrefix参数，并保证srcPrefix中有可用文件。

问题分析：没有权限访问配置文件。

解决方案：设置配置文件的权限为所有人可读或将操作系统账号切换为管理员后启动服务。

解决方案：

1. 确认乱码文件的编码格式。

2. 使用export LANG=" "命令解析这些编码。

3. 使用clean命令清除原来的Job，再用submit命令重新提交Job。

只要您没有使用clean命令清除同名任务，所有提交过的Job都会有断点记录，所以直接调用start命令启动服务即可，已经提交的Job不需要重新提交。

问题分析：如果机器的可用内存少于2GB，服务进程很可能是因为内存不足被杀掉了。可以检查dmesg日志是否有内存不足导致进程被杀掉的记录。

解决方案：观察Task的总数是否在增加。

• 如果Task总数增加，则表明Job的文件列表还在List新的文件，是正常现象。

• 如果Task总数没变化，且Job配置的是增量模式，scanFinished不为true的情况下 ，ossimport会根据您配置的间隔时间定期扫描文件列表，检查有无新增或修改的文件。

• 如果不是增量模式，Task数也不会增多，检查运行日志是否有异常。单机部署查看日志文件logs/ossimport2.log；分布式部署查看日志文件logs/ossimport.log，找到异常原因并解决，然后再启动服务进程。

问题分析：任务开始运行需要服务已启动，且任务已提交，之后使用stat命令才可以查看到任务的运行状态 。

• 若仅使用submit命令提交了任务，而没有使用start命令启动服务，则会一直报“no jobs is running or finished”。您需要使用start命令启动服务。

• 若服务已启动，且任务刚提交，Master需要先去扫描文件列表，这时Task还没有真正生成和分发，所以打印该日志是正常的。

• 若服务已启动，且任务已提交一段时间后依旧打印该错误，查看是否该进程启动后异常退出了。单机部署查看日志文件logs/ossimport2.log；分布式部署查看日志文件logs/ossimport.log，找到异常原因并解决，然后再启动服务进程。

解决方案：使用ulimit -n查看系统句柄。

• 如果值在一万以下，可以通过ulimit -n 65536调大，之后重启进程即可。

• 如果本来就设置的比较大，使用sudo losf -n排查是哪些进程打开了句柄，您可以评估下这些进程是否需要，如果不需要可以kill掉它们从而释放相应的句柄。

问题分析：“com.aliyun.oss.ClientException: Unknown”错误和“SocketTimeoutException”错误一般都是网络被占满的时候出现。此时ossimport会自动进行重试，如果重试完后依旧失败，您可以在任务完成后调用retry命令再次重试。

Java版本过低，请更新到1.7或1.8版本。