prefetch cannot handle duplicated chunks in different inodes correctly

Additional Information

Version of nydus being used (nydusd --version)

Version: v2.3.0-alpha.0-4-g5c63ba92 Git Commit: 5c63ba924e5db94da5e0db44b1f9551bae938fe3 Build Time: 2023-10-19T10:54:12.443265226Z Profile: release Rustc: rustc 1.68.2 (9eb3afe9e 2023-03-27)

Version of nydus-snapshotter being used (containerd-nydus-grpc --version)

Version: v0.8.0-41-g2c1de89.m Revision: 2c1de89684595c12737d3cb9aac1cd41e28025a2.m Go version: go1.20.1 Build time: 2023-05-31T08:47:41

Kernel information (uname -r)

5.3.18-050318-generic command result: uname -r

GNU/Linux Distribution, if applicable (cat /etc/os-release)

NAME="Ubuntu" VERSION="18.04.6 LTS (Bionic Beaver)" command result: cat /etc/os-release

containerd-nydus-grpc command line used, if applicable (ps aux | grep containerd-nydus-grpc)

client command line used, if applicable (such as: nerdctl, docker, kubectl, ctr)

For a single layer wordpress:latest, do:

# enable dir-rafs
export NYDUS_DISABLE_TAR2RAFS=true

# build time prefetching
nydusify convert --source dockerhub.kubekey.local/dedup/wordpress-s:latest \
--target dockerhub.kubekey.local/dedup/wordpress-s:latest-nydus \
--target-insecure --source-insecure --prefetch-patterns \
log-level trace < /home/runner/wordpress-prefetch.txt

sudo -E nerdctl --insecure-registry --snapshotter nydus run --rm \
dockerhub.kubekey.local/dedup/wordpress-s:latest-nydus

Screenshots (if applicable)

Details about issue

When build time prefetching is enabled, there is a huge number of tiny HTTP GET requests are generated for prefetching.

The reason is that is_continuous() is failed and then split into many tiny pieces, beacuse there's two same bio inside bios, that is, the two same chunks are not continuous.

https://github.com/dragonflyoss/image-service/blob/5c63ba924e5db94da5e0db44b1f9551bae938fe3/storage/src/cache/mod.rs#L120-L126

The reason why two same chunk are included is that, the chunk is appended without checking whether it is already existed, since multiple different inodes may share the same chunk.

https://github.com/dragonflyoss/image-service/blob/5c63ba924e5db94da5e0db44b1f9551bae938fe3/rafs/src/metadata/mod.rs#L982-L987

https://github.com/dragonflyoss/image-service/blob/5c63ba924e5db94da5e0db44b1f9551bae938fe3/storage/src/device.rs#L800-L806

Two same chunks in a bios and adjacent is just the simplest case. I can't imagine but there must be some more complicated cases. How to solve it?

Seems simply checking each BlobIoDesc before appending neither comprehensive nor efficient.

dragonflyoss / nydus