hdd problems with 2.0.6
Feverqwe opened this issue · comments
Hi, I try use version 2.0.6 with qbittorrent, and have a lot of problems with hard drive.
I run qbittorrent in docker on raspberrypi, with alpine linux, and exfat external 4tb hdd.
When torrent downloading, speed go up to 4mb/s, and after (2 min or less) it go down to zero or near zero, then grow up, and repeat problem. Looks like often call sync command and read/write is lock for a short time.
I rollback to 2.0.5 and it work fine.
Dockerfile looks like this:
FROM gists/libtorrent-rasterbar:2.0.6 as libSource
FROM gists/qbittorrent:4.4.2 as source
FROM alpine:3.15
ARG WEBUI_PORT=8080
ARG PROFILE_PATH=/profile
RUN apk --update --no-cache add qt5-qtbase && rm -rf /tmp/* /var/cache/apk/*
COPY --from=libSource /usr/lib/libtorrent-rasterbar.so.2.0.6 /usr/lib/libtorrent-rasterbar.so.2.0
COPY --from=source /usr/bin/qbittorrent-nox /usr/bin/qbittorrent-nox
RUN qbittorrent-nox --version
CMD /usr/bin/qbittorrent-nox --webui-port=${WEBUI_PORT} --profile=${PROFILE_PATH}
exFAT doesn't support sparse files, does it? I would have thought that to cause problems regardless of libtorrent version.
Do you, by any chance, use settings_pack::write_through or settings_pack::disable_os_cache for your settings_pack::disk_io_write_mode?
The behavior of those two settings has been modified to msync() each piece, once it completes. That's the closest thing I can think of that could affect this.
Thx, I try change file system. But only exfat supported by windows and osx together.
If it worked well in 2.0.5, I would still be interested in understanding what caused the regression
qbittorent by default use os cache, yes. When I start download on exFat it allocate file on disk and then normal download. But I don't know that may be cause of problem on new version.
Some times I think maybe it some side effects from overheating raspberry pi 4 model b. I try to check this. In version 2.0.5 some times I have same problems, but much less often.
Add noatime in mount flags, become better. I think it problems with hard drive or fragmentation. Not in library.
libtorrent defaults to opening files with O_NOATIME (if it's available). I would have thought that would have the same effect as mounting the volume with that option. However, there's a caveat. If the owner of the file is different than the owner of the process accessing the file, O_NOATIME will fail (and libtorrent will fall back to opening the file normally)
No, it don't work well with 2.0.5. I change hard drive, and it work well with 2.0.6. I monitoring hdd activity (with diskgraph tool) and it is problem with hdd. It write some data and then it don't response some time or response very slow, after some time it work fine again, other hdd don't have same problems.
I see how it write data on drive, and first 1.5tb write/read fast 50mb/s (and this part is full), other part very slow writing and reading (4mb/s). I try understand how to fix it, but I think it broken hdd.