grootte backup naar tape berekenen met tar/awk

[bucovaina89]

Mijn vraag
Ik zou graag de grootte van alle bestanden die ik met tar op een tape zet willen berekenen. Nu pipe ik de output van tar -Mcvvf /dev/st0 /path/to/be/backed/up/* naar een file die ik dan "process" met awk.

De output van tar ziet er zo uit. Een erg lange lijst van deze lijnen:

code:

-rwxrwxrwx 1028/138862   25410219 2018-08-15 07:36 mnt/photo/YYYY/MM/DD/ALBUMNAME/IMG_3266.CR2

Met awk ga ik daarover alsvolgt:

code:

awk '/code/,/\/code/ {sum+=$3;} END {printf "%.0f", sum;}' 000004l3.txt

Dat deel ik dan door 1073741824 zodat ik de grootte in GB krijg: 380.14 ... ? Als ik door 1000000000 deel dan krijg ik 408.17GiB.

Ik heb al eens geprobeerd om een backup te nemen van /usr/ met tar naar een file. Daar blijkt ook dat een ls een grotere grootte rapporteert van de tar file dan ik hetzelfde doe met awk.

Dus dan is mij vraag, wat doe ik mis? Of doe ik het juist maar is er iets wat ik niet begrijp?


Relevante software en hardware die ik gebruik
tar,awk,bc op Linux
LTO-3 tapes in native (geen compressie). Die zouden dus in theorie 400GB moeten kunnen opslaan.

Wat ik al gevonden of geprobeerd heb

code:

$ backup_size=$(awk '/code/,/\/code/ {sum+=$3;} END {printf "%.0f", sum;}' 000004l3.txt)
$ echo $backup_size 
408173321351
echo "scale=2; $backup_size/1073741824" | bc
380.14
echo "scale=2; $backup_size/1000000000" | bc
408.17

[vanaalten]

bucovaina89 schreef op woensdag 25 november 2020 @ 09:28:
Dat deel ik dan door 1073741824 zodat ik de grootte in GB krijg: 380.14 ... ? Als ik door 1000000000 deel dan krijg ik 408.17GiB.

Ik heb al eens geprobeerd om een backup te nemen van /usr/ met tar naar een file. Daar blijkt ook dat een ls een grotere grootte rapporteert van de tar file dan ik hetzelfde doe met awk.

Hmmm, ik kan mij voorstellen dat een tar-file de nodige overhead heeft die je met puur een som van alle filesizes niet meeneemt: file attributes en directory names/structure. Dus dat een uiteindelijke tar-file groter wordt dan jouw schatting lijkt mij niet gek.

[bucovaina89]

Lijkt inderdaad logisch als ik deze lees: https://askubuntu.com/que...gger-than-original-folder

[Hero of Time]

Daarbij:

Dat deel ik dan door 1073741824 zodat ik de grootte in GB krijg

en

Als ik door 1000000000 deel dan ... GiB

Dat klopt niet wat je hier zegt. De waarde voor GiB is het binaire getal, dat kan je dus niet door een decimaal getal delen. Je verwisselt de termen. Waar je door 1073741824 deelt, geeft GiB, deel je door 1000000000 dan krijg je GB.

Zo was vroeger een harde schijf van 80 GB effectief 74 GiB.

[bucovaina89]

@Hero of Time : Als ik de waarden die tar in de 3e kolom zet en die awk bij elkaar optelt deel door 1073741824, dan krijg ik het aantal GB. Klopt het dan wel wat ik zeg

[Hero of Time]

bucovaina89 schreef op donderdag 26 november 2020 @ 08:23:
@Hero of Time : Als ik de waarden die tar in de 3e kolom zet en die awk bij elkaar optelt deel door 1073741824, dan krijg ik het aantal GB. Klopt het dan wel wat ik zeg

Nee, want voor de waarde van gigabyte wordt veelal het duizendtal gebruikt. Terwijl voor gibibyte de veelvoud van 1024 is.
1073741824 bytes = 1 GiB
1000000000 bytes = 1 GB

Zie ook Wikipedia: Gibibyte :

The gibibyte is a multiple of the unit byte for digital information. The binary prefix gibi means 230, therefore one gibibyte is equal to 1073741824 bytes = 1024 mebibytes. The unit symbol for the gibibyte is GiB. It is one of the units with binary prefixes defined by the International Electrotechnical Commission (IEC) in 1998.

The gibibyte is closely related to the gigabyte (GB), which is defined by the IEC as 109 bytes = 1000000000bytes, 1GiB ≈ 1.074GB. 1024 gibibytes are equal to one tebibyte. In the context of computer memory, gigabyte and GB are customarily used to mean 10243 (230) bytes, although not in the context of data transmission and not necessarily for hard drive size.