SMR - partitioner och filsystem?

Du får titta med tex crystal disk info-programmet vad det är för disk inne i kabinettet, så kan du troligen se att det är olika diskar mellan nya och äldre externa cabinett.

---

NTFS sämst för att varje fil som skrivs så är man och pilla i $MFT på nästan samma ställe hela tiden - det fyller SMR-disken PMR-del fort.

FA16/32 och exFAT förmodligen lika dåligt som NTFS av samma orsak och du tappar också massor av metadata, rättigheter, användare, har inte hårda länkar etc. eftersom det inte finns plats för sådant i deras filsystems metadata.

ext4 ca 4 ggr bättre än NTFS innan det går trögt

BTRFS 10 ggr mer till att nedsölning aldrig inträffar innan man är klar

Är det mycket småfiler som läggs till och tas bort eller kört programmet 'bees' för block-deduplicering så bör man köra BTRFS 'balance' på filsystemet efter för att plocka ihop de 'fluffiga' chunken med massor av gluggar i till massiva dito igen. Då att fylla ut utrymmet i dom 'fluffiga' shunken med filer igen för att småfiler och block tagits bort kan gör att man åker in i SMR-väggen ganska fort även med BTRFS.

ZFS vet inte, men tror inte att det är så farligt med ZFS på en enskild lagringsdisk. - det är i RAID som faran finns med SMR-diskar med ZFS-filsystem

HFS+ - inte en aning - men gissar att de i grunden är en UFS-filsystem och har förmodligen liknande egenskaper som ext4.

---

Jag kör BTRFS på all backuplagring på SMR-diskar (har ett antal och inte ännu råkat på att BTRFS inte skulle vara monterbar när man ansluter disken igen trots missöden med glappa spänningsmatning och USB-sladdar under full skrivning, hängande program/OS etc. - dessutom ligger alla på LUKS-crypt i botten så innehållet är tämligen värdelöst om man inte har rätt passord)

- en viktig orsak är att på ingen tid alls så gör man en snapshot av subolymen man har sin backuppträd i innan man kör synkningen mot tex. NAS och skulle det vara så att den del filer på NAS börja ha krypterats av en ransomware-virus via någon klientdator så finns den friska versionen från förra backuppen kvar i snapshot - det enda det gör är att förändrade filer tar mer plats.

Snapshot i BTRFS är inte hierarkisk på samma sätt som i ZFS med farfar, far, son-förhållande i ett dataset vilket gör att man kan plocka bort en subvolym vilken ordningsföljd som helst, när som helst i BTRFS.

Snapshot i BTRFS är att det genereras en förfylld filträd i en ny subvolym med kopia av annan subolyms innehåll och efter snapshot-momentet är det som vilken subvolym som helst och du kan göra precis vad du vill inom subvolymen utan att det påverkar någon annan fil utanför subvolymen på BTRFS-filsystemet, inklusive att radera subvolymen igen (vilket går mycket fortare än att radera fil för fil inom filträdet med 'rm' då en garbage collector i BTRFS gör städjobbet en tid framöver).

Skapa en snapshot i BTRFS handlar om 1-5 sekunder i tid även för en 8TB dataset med 3 miljoner filer.

subvolym ser normalt ut som vilken filmap som helst, lite som att det är en monterad disk eller nätverksvolym med mount under mappnamnet och med samma restriktion att man tex. inte kan ha hårda länkar mellan filnamnen mellan subvolymer, bara inom subvolymen.

Man kan också göra read-only subvolymer där absolut ingenting under detta kan ändras, bara att ta bort hela subvolymen igen. tekniskt sett så gör man det genom att sätta quotan till 0 och eftersom varje ändring sker genom att det skrivs på ny sektor så måste man ha ledig plats på disken, det gäller också metadatan för subvolymen - och det finns inte och alltså kan inget ändras.

subvolymer kan också konfigureras (med "chattr +c subvolymmappen") att alla filer och skapade nya mappar som läggs i mappen komprimeras automatiskt och helt osynligt. - mycket värdefullt om man sparat på diskimages.