关于experimental分支的fragments和dedup特性在android上的几个bug

[asuka-mio]

给aosp加上了最新的erofs-utils支持，4.19的高通865内核除了dax和fscache特性其他的也都从主线backport了，核心代码对比上游几乎没有差异了，不过最新两个特性出现了些bug，虽然是experimental，但是还是说下吧

https://github.com/AcmeUI/android_external_erofs-utils/commit/5b931901fc64b0faedb40ed39cf833102187e489

fragments支持在load android的fsconfig下packed inode得跳过，要不然查找不到路径（

---

Handling packed_file ...failed to find rblock: %d in canned fs_config

Out of space? Out of inodes? The tree size of /home/tarsin/Acme/out/soong/.temp/tmp3d41sibp is 990187520 bytes (944 MB), with reserved space of 0 bytes (0 MB).

---

而且加上这个patch虽然能输出文件了，我bp的内核也没法读取，会触发这个https://github.com/torvalds/linux/blob/725737e7c21d2d25a4312c2aaa82a52bd03e3126/block/blk-core.c#L525， 虽然和上游代码高度一致，不过也不排除我bp的有问题

还有就是在开启dedup特性的时候制作某些镜像（比如android的vendor镜像）mkfs直接死循环了（等了十多分钟什么也没有输出，一直在占用一个线程的cpu时间，我还没去调试，如果您需要测试文件的话我可以传下

[asuka-mio]

拿gdb连上看了下，也不是死循环，是一个while循环要跑二百万次（以我的测试样本） https://github.com/hsiangkao/erofs-utils/blob/f3f9a2ce313727a16dd44d5f6cb37882247bdeea/lib/dedupe.c#L79

能否考虑做下simd优化处理

[hsiangkao]

hi！刚看到消息，能否在邮件列表报告问题。。这个github我很少翻issue。。

[hsiangkao]

拿gdb连上看了下，也不是死循环，是一个while循环要跑二百万次（以我的测试样本）

https://github.com/hsiangkao/erofs-utils/blob/f3f9a2ce313727a16dd44d5f6cb37882247bdeea/lib/dedupe.c#L79

能否考虑做下simd优化处理

dedupe目前是比较费cpu的，后面会考虑多线程处理。但由于历史数据不全，压缩率会有损失。 另外fragment去重已经做了进一步优化。

[asuka-mio]

拿gdb连上看了下，也不是死循环，是一个while循环要跑二百万次（以我的测试样本） https://github.com/hsiangkao/erofs-utils/blob/f3f9a2ce313727a16dd44d5f6cb37882247bdeea/lib/dedupe.c#L79

能否考虑做下simd优化处理

dedupe目前是比较费cpu的，后面会考虑多线程处理。但由于历史数据不全，压缩率会有损失。 另外fragment去重已经做了进一步优化。

嗯我的意思就是这块不知道编译器会不会unroll-loops 或许先用memcmp进行block by block 的对比比较好 https://github.com/AcmeUI/android_external_erofs-utils/commit/2688eff570625b022feb7e01b1612ed552783486

[asuka-mio]

毕竟memcmp在大多数c库下都是simd优化的

[hsiangkao]

毕竟memcmp在大多数c库下都是simd优化的

这个位置其实是可以使用类似memcmp的api的，但问题在于memcmp目前无法返回有多少字节匹配，所以不能满足要求。自己写一个或许快一点（比如你说的simd），但目前个人没时间。。

[hsiangkao]

I will close the issue (if you'd like to improve, patches are always welcome ;)