Hi,
So basically my problem is similar to case: like this. Where in big shurtcut when pulling image from dockerhub it can takes forever .. Finally always it finish it's job but extracting over all night is too much
At linked post users claims that sollution is switching to faster sd card solves a problem, which I really doubt that! And here is why (btw I have switched to a brand new one):
I have NonoPi R4S with 6cores on CPU and 4GB of RAM - for a such device like it it's nice, right? Additionally I have equipped it in additional 1TB SSD - so we can assume it won't be faster that that. My net speed is ~ 750MiB/s.
Already I have a few images pulled and up running. It works ok. But while pulling a new image then it stock (acctually work but reallllllllllyyyyyy slow). Please keep in mind that!
I changed SD card. First attempt to pull - WOW it did the trick!! And after system reboot it back again to a snail mode And because of that I don't belive SD hint helps here.
But I was tinkering around. Probably I supost start from fact that during first start on a brand new SD:
root@FriendlyWrt:~# blkid
/dev/mmcblk1p8: LABEL="rootfs" UUID="ff313567-e9f1-5a5d-9895-3ba130b4a864" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="rootfs" PARTUUID="b2af085d-a675-48c6-c437-f6d557ff4744"
/dev/mmcblk1p9: LABEL="userdata" UUID="269e9152-5cb6-035b-9c34-e1ed87cca310" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="userdata" PARTUUID="2d9e7b61-1b31-47e7-ee0d-8cec26d42ef6"
/dev/sda1: UUID="6D2A-9E26" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="50098e3a-01"
/dev/sdb1: LABEL="RedNateck_NanoPi" UUID="cce28d02-24e0-488e-a848-f60d0d28e7c1" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="587fb637-01"
/dev/mmcblk1p3: PARTLABEL="misc" PARTUUID="43784a32-a03d-4ade-92c6-ede64ff9b794"
/dev/mmcblk1p1: PARTLABEL="uboot" PARTUUID="b750e44e-833f-4a30-c38c-b117241d84d4"
/dev/mmcblk1p6: PARTLABEL="kernel" PARTUUID="1cac805f-726a-495a-fd35-821355a6e7e8"
/dev/mmcblk1p4: PARTLABEL="dtbo" PARTUUID="000b305f-484a-4582-9090-4ad0099d47bd"
/dev/mmcblk1p2: PARTLABEL="trust" PARTUUID="a1c81622-7741-47ad-b846-c6972488d396"
/dev/mmcblk1p7: PARTLABEL="boot" PARTUUID="2bfee623-d83c-426a-ab80-21732c9bb7d3"
/dev/mmcblk1p5: PARTLABEL="resource" PARTUUID="24eeb649-277f-4c11-ffeb-d9f20027a83b"
/dev/sdb1 here is my SSD and it's crutial. Sda1 is another flash drive.
block info command:
Disk /dev/sdb: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: 400-01T-G2
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x587fb637
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 2000396287 2000394240 953.9G 83 Linux
So we know what type of disc it is. Let's proceed then.
When I'm able to find that disk then pulling images from docker hub is jus a bullet speed! 1-2 min for images like 1GB (including extraction time).
There is down side here - while I'm able to get mounted SSD my data in containeres seams to be lost.. Because non of app doesn't recognize my credentials any more...
But lets reboot this sucker!
Suddenly blkid lost /dev/sdb1 after waking up. And something interesting happened:
and
with set up like that my data from containers are backed!
My docker setup point on that location because of:
root@FriendlyWrt:~# docker info
Client:
Context: default
Debug Mode: false
Plugins:
compose: Docker Compose (Docker Inc., v2.15.1)
Server:
Containers: 5
Running: 3
Paused: 0
Stopped: 2
Images: 13
Server Version: 20.10.22
Storage Driver: fuse-overlayfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
Default Runtime: runc
Init Binary: docker-init
containerd version:
runc version:
init version: de40ad0
Kernel Version: 5.15.78
Operating System: OpenWrt 22.03.3
OSType: linux
Architecture: aarch64
CPUs: 6
Total Memory: 3.747GiB
Name: FriendlyWrt
ID: W6EH:KEAU:CLUM:HWVM:G5WX:RUFY:U5EX:ZH3O:7XHT:I7WQ:M5RN:4V2J
Docker Root Dir: /mnt/sdb1/Docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Docker Root Dir: /mnt/sdb1/Docker - I just wanted to store images, containers and volumes outside of slow micro SD card.
Please check out what happened with mount bellow:
root@FriendlyWrt:~# mount |grep sdb1
overlay on /mnt/sdb1/Docker type overlay (rw,noatime,lowerdir=/root,upperdir=/data/root,workdir=/data/work)
fuse-overlayfs on /mnt/sdb1/Docker/fuse-overlayfs/6c314d6a7350e936f4fe2e04d0f864492b396ed594724c82541dfc8179c2375d/merged type fuse.fuse-overlayfs (rw,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other)
fuse-overlayfs on /mnt/sdb1/Docker/fuse-overlayfs/24dde8dd5b57f25b122b31890b7c0167a9f64734be94065f832580c8c56dfd6f/merged type fuse.fuse-overlayfs (rw,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other)
fuse-overlayfs on /mnt/sdb1/Docker/fuse-overlayfs/0f2bab965354b03fc0141af31204a2cf9a1aad7d95ba1979264c5ff6ea637c46/merged type fuse.fuse-overlayfs (rw,nodev,noatime,user_id=0,group_id=0,default_permissions,allow_other)
How to get rid of that overlay but in the same time be able to not loose data from my current containers? Because of that overlay pulling images causing performance issue. And I'm sure about that after my investigation
Personally I find particular topic very interesting, but I think I chaising my tail currently
Any idea?
Thanks in advance!