Samba issue concerning delay when copying files

ich verstehe struggle mehr Sinne von "scheitern" nach vergeblichen Bemühungen.

Bemühung, probieren, Versuch:= attempt, try

jutt, 'bin auch nicht der Weltmeisteeer in englisch ...

war auf jeden Fall nicht negativ gemeint

The reserved space is so that on normal linux installations, where the harddrive is used as a system disk, there's always some space purely reserved for system usage (logs, temporary files, other stuff the system needs to operate).

On non-system partitions/drives it's generally fine to set that to zero.

And on LE it's even more of a cosmetic issue as (almost) everything runs as root (with system privileges) anyways.

so long,

Hias

Quote from popelpenner

May i ask what the reserved space is good for?

from man mkfs.ext4:

-m reserved-blocks-percentage

Specify the percentage of the filesystem blocks reserved for the super-user. This avoids fragmentation, and allows root-owned daemons, such

as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. The default

percentage is 5%.

I wonder why/where the initial 36 GB reserved space came from ?

How do you copy the 4TB back to the HD ?

from what OS ?

over samba share ?

I guess you meant Mbyte/sec ?

AFAIK a RasPi has a 1 Gbit LAN, so network speed should be 100-112 MByte/s

my WesternDigital WD-Black-P10 5TB could write 142 MB/s via USB connection

therefore you should see higher speed !

otherwise I guess with your disk is something fundamental wrong ?

and if so I would start over and delete all partitions from he disk.

I found a user friendly write up:

8 Linux 'Parted' Commands to Create, Resize and Rescue Disk Partitions

www.tecmint.com

be aware: unmount the disk before !

on your PI (with NO external disk attached !):

- connect the external disk

- key in "mount" to find out what's the disk device name is; usually /dev/sdbX

assuming /flash is mounted on /dev/sda1 and /storage is mounted on /dev/sda2, then the next free device name is /dev/sdb (your external disk, usually mounted under /var/media (?!)

(I got no PI here, so please correct me if I'm wrong !)

- unmount it:

either "unmount /var/media" or "unmount /dev/sdb1", but remember the device name, e.g. /dev/sdb

- recheck if it's unmounted with an subseq. "mount"

- after that read under the above linked page:

- how to print the current disk layout

- how to delete a partition

- how to create a new partition table

- how to create a new primary partition

- how to format that new partition with ext4

be aware:

to work on the correct disk (the above mentioned "device name" (/dev/sdb)

[ where "sdb" is the whole disk and "sdb1" is the first partition on that disk]

1. start parted with the correct unmounted device name:

parted /dev/sdb (it starts a sort of subshell indicated by a prefix "(parted)" and operates on the device /dev/sdb"

2. key in "print" to make sure you're on the correct disk

if so

3. rm <the partition number goes here> [see chap. 6 in the linked page]

and if the disk contains more then one partition: repeat until the disk has no partition anymore !

4. now we create a new partition table GPT and a primary partition [see chap. 4 in the linked page]

- adjust "mklabel msdos" to "mklabel gpt" !

- key in "mkpart"

- key in "primary" !

- ext2 is okay (we change it later; btw.: ext4 is an ~enhanced~ ext2)

- Start? is 1 (if parted suggests 2: the disk still contains partitions => goto 3.)

- End? is what parted suggests justed confirmed with enter key

- key in "print"

now the disk should have:

- Partition table: gpt

- one partition => Number is 1 !

- size is 5 TB

- type: primary

- FS: ext2

- flag: don't know

is so ???

5. key in "quit"

you're now out of the parted subshell; the command prompt starts with "LibreELEC:"

6. I'm unsure if parted informs the kernel over the new partition, but it want hurt to key in "partprobe"

7. format the shiny new partition with

mkfs.ext4 /dev/sdb1

or with an disk label:

mkfs.ext4 -L <my-external-disk-label> /dev/sdb1

8. reboot the box and check

- new disk is mounted under /var/media

- has the complete disk size (5TB minus 5%)

- has sufficing speed:

a) change to /var/media (cd /var/media)

b) run for write speed:

dd if=/dev/zero of=tempfile bs=1MB count=10240

c) run for read speed:

dd if=tempfile of=/dev/zero bs=1MB count=10240

d) cleanup

rm tempfile

comments/rotten fruits ?

backup doc's (parted):

Parted User’s Manual

- double post as average Joe's always do => /dev/null -

Quote from popelpenner

@Joe

wow, this is a lot amount of information!

Why is it all so complicated

well, my intention was that you learn something that you're able to help yourself next time.

complicated ?

well, for the first time(s) only, afterwards it becomes common.

Quote from popelpenner

And this HD was the one which stucked from time to time (maybe some bad blocks!?)

stuck:

as said I own a 5 TB WD disk.

compared to another 500 GB WD disk I see some stuckering (?) too during weekly backup via rsync.

I haven't exactly figured out why, it could be that the compare the rsync does is somehow slower, but why ?...

The disk speed is okay, as the the above dd commands showed.

anyway, the main differences is that the smaller disk uses SMR and the bigger CMR

https://www.reichelt.com/magazin/en/guide/smr-cmr-which-hard-drive-is-best-for-which-purpose/

but the bigger one is able to do TRIM (a garbage ~remover~ of delete data) usually for SSD's.

with the attached disk to the Pi:

fstrim -va

should TRIM your disk

more to read:

https://en.wikipedia.org/wiki/Trim_(computing)

===

bad blocks ?

if you find some on the disk: backup the disk, ASAP and go for another disk !

to check the disk and with the external disk attached to the Pi:

usually a

smartctl -a /dev/sdX

(adjust X with b ?)

outputs what's up with bad blocks and other attributes (usually) the disk log's:

consult:

https://en.wikipedia.org/wiki/S.M.A.R.T.

you could run self-tests on the disk to fresh up the attributes with

smartctl -t short /dev/sdX

or

smartctl -t long /dev/sdX

both commands will output when they're done.

afterwards a smartctl -a ... should show the current attributes.

btw.: the "-a" switch also shows - to get an idea - how long each self-test lasts:

search for "recommended polling time:"

be aware:

the disk should be under power as long the self-test runs.

means: sleep mode (suspend, hibernate) or power down shouldn't happen.

background: some disk continues the self-test after sleep mode/power down, some do not, at least my 5TB WD disk does not

===

Quote from popelpenner

As i mentioned, the mkfs.ext4 command led to a stuck of the formatting process with the message "creating journal" by 1 of my 3 HDs.

So i had to format this HD with the external tool, which produced the 36GB.

And this HD was the one which stucked from time to time (maybe some bad blocks!?)

"creating journal" is normal with ext4 (journaling file system) and should last for a 5 TB max ~3 minutes.

what was the "external tool" ?

usually one uses the tools the OS, where the disk later does it's job, offers.

you're better off with them

a differences in space is common and should be minus ~7 %

the cause is manufacturer calculate in powers of 10 and not of 2, so for a nominal 5 TB the real size is ~4656 GB only.

calc:

(5*10^9) / (5*2^30) =0,931

Quote from popelpenner

btw. is this an english only forum? If so, let me know and i'll try to post this in english.again.

I'll give my very best

yup, english !

additional post in english seems to be unnecessary, cause the thread is marked as resolved