Idag så är minnes-kedjan i rätt många steg
Först processorregister och i detta finns pipeline-hantering, därefter cache - både en första nivå, sedan en andra nivå sedan börjar den egentliga primär-minnet - kallad RAM-minne, och den i sin tur kan också ha en cache i minnescontroller eller lokalt på minnesstickorna. Dessa minnen anropas primärt med adressering på Byte-nivå även om när anropet exekveras är minst på ordnivå typ 32, 64 eller 128 Bitar eller annan bus-bredd storlek samtidigt (i praktiken växlas in i 4K-block av minneshanteraren)
Sekundärminne avser oftast data som är kvar även efter avstängning/strömavbrott och anropas i LBA-adressering i antingen 512-bytesblock eller 4K-bytesblock och adresseras inte på Byte-nivå.
Idag är sekundärminne också en kedja mellan med ibland snabba mellanlagringsminnen som börjar med att en del av RAM-minne allokeras som både fil-cache (håller reda på en fil) och diskcache (lagrar på LBA-blocknivå) - i en del fall har man snabba SSD läs och skriv-cache som intel optane men även snabb SSD av mer traditionell sort och helst på NVMe (för ofta anropade sektorer eller för att bygga en fil till längre sammanhängande stycke) innan det går vidare ut på masslagring av antingen SSD eller snurrdisk.
Både SSD och Snurrdiskar har i sin tur mer eller mindre stora RAM-cache där alla inkomna LBA-kedjor sorteras i rätt ordning i ytterligare en omgång för att packa i större klumpar (för att minimera antal skrivningar till så få block som möjligt i SSD) eller för bästa skriv och läshastighet beroende på hur läsarmen på snurrdisken för tillfället är positionerat för att skriva/läsa data med så minimala rörelser och korta delayer som möjligt då söktiden är stor.
På SSD har man med MLC, TLC och QLC- minnen också både RAM-cache (men inte så stor som används för att lagra sektorer som många tror - utan det mesta är för SSD:s egna interna hantering när det läser in och skriver om hela block fast det kanske är bara enstaka bitar som ändras) och olika hierarkier av snabb och långsam Flashminne, då multilevel-flash tar mycket längre tid att skriva än singel-level flash. I somliga fall kan samma fysiska flash ha olika moder för att användas som singel eller multilevel för olika skrivhastigheter.
Av den anledningen så märker man ofta i främst de billigare SSD/NVMe att man bara kan skriva ett antal, kanske enstaka tiotal GB väldigt snabbt för att sedan blir rätt långsam - kort sagt när SLC-delen blir full i SSD så måste skrivhastigheten gå ned till den verkliga hastigheten som MLC, TLC och QLC kan skrivas med, ja om man inte ger SSD lite andrum och får tömma sina SLC-cache igen.
Och sedan har man längst ned på kedjan - att skicka data över nätverk, att bränna det på DVD/BR eller att lagra på bandbackup.
I många fall får man i dessa fall (dvs. i lagring/backup på molntjänst - inte som ren filserverfunktion) ge upp det är med snabb slumpmässiga sökningar utan data lagras i containrar eller arkiv, alltså i stora stycken - antingen som man skapas själv (zip-arkiv, tar-arkiv, ISO-images), görs av använda backupprogram ( upphuggna arkiv som tar-arkiv, i zippade chunk mm.) och i slutändan också görs - förvisso ibland kamouflerad som filsystem i använda klientprogram av molntjänster, som block i S3, B2 i buckets och chunk.
Backup på bandarkiv är väldigt sekventiellt där filerna, kontainrarna och arkiv-volymerna måste läggas i sekvens då man måste spola fram och tillbaka på bandet för att hitta dem och skriva/läsa av dem - bandarkiv är verkligen inte lämpliga för slumpmässiga sökningar... det innebär också att man inte kan modifiera enskilda stycken/sektorer på bandet utan det hela är uppdelat i sessioner där när man väl startat så måste man köra hela vägen vare sig vid skrivning eller läsning och man kanske bara är intresserad en liten bit av det.
Många moderna molntjänster är byggda på samma sätt - man kan skriva en fil, ta bort en fil men inte ändra i en redan befintlig fil, backupprogram som arbetar mot molntjänster vet om detta och när man tar bort gamla backup-sessioner så kan en del av chunken till största delen består av inaktuell data och mindre bitar med fortfarande aktuell data och backupprogrammen tar då och packa om dessa genom att läsa in det som fortfarande gäller ur dessa chunk, skapa nya chunk med aktuella datat och sedan radera de gamla och nu helt inaktuella chunken och man återvinner plats - både Duplicati och borg-backup kör på detta sätt, och säker många av molntjänsternas backupprogram också.
---
Att Tape Archiver (aka TAR-arkiv) ser ut som det gör, är präglat av väldigt mycket på hur man hanterade bandbackupper förr i tiden och att dessa inte var 100% pålitliga pga. hanteringen av bandrullarna, och också varför formatet är relativt robust även om arkivfilen inte skulle vara komplett (tex bit saknas i mitten för att det blev bandtrassel, läsfel på ett antal sektorer eller annat fel) och det finns ingen master-block i början eller slutet (rättare sagt det finns en magic word inför varje fil och är komplett med path, namn rättigheter etc. för full återställning) utan all metadata är distribuerad och alltid i början av själva datadelen på varje fil inom arkivet och därför inte har samma svagheter som tex. zip, ISO-fil eller de flesta andra arkivformat där en skada eller bara enstaka bit-fel precis i början och/eller slutet gör hela arkivet komplett odugligt. - inte så roligt att på en arkiv på flera 100 GB är oräddningsbar bara för att en 512-bytes sektor i början/slutet saknas/skadas av en snabbt avbruten påbörjad överskrivning.
med Tar så förlorade man bara den filen i arkivet som är påverkad av skadan/överskrivning medans resten kan återskapas.
Av detta skall man aldrig gzippa en tarfil (om det är viktiga datafiler i denna) men man kan gzippa alla filer innan man gör en tar-arkiv av dessa.