synk (Unix)
sync är ett standardsystemanrop i Unix - operativsystemet, som överför all data i kärnfilsystemet till icke -flyktiga lagringsbuffertar , dvs. data som har schemalagts för skrivning via lågnivå- I /O- systemanrop. I/O-lager på högre nivå som stdio kan ha separata buffertar.
Som en funktion i C deklareras sync () -anropet vanligtvis som void sync(void) i <unistd.h> . Systemanropet är också tillgängligt via ett kommandoradsverktyg som även kallas sync , och liknande funktioner på andra språk som Perl och Node.js (i fs-modulen).
Det relaterade systemanropet fsync() överför bara buffrad data som hänför sig till en specificerad filbeskrivning . fdatasync() är också tillgänglig för att skriva ut just de ändringar som gjorts i data i filen, och inte nödvändigtvis filens relaterade metadata.
Vissa Unix-system kör en sorts flush- eller uppdateringsdemon , som anropar synkroniseringsfunktionen regelbundet. På vissa system cron -demonen detta, och på Linux hanterades den av pdflush-demonen som ersattes av en ny implementering och slutligen togs bort från Linux-kärnan 2012. Buffertar töms också när filsystem avmonteras eller ommonteras skrivskyddat , till exempel innan systemet stängs av.
Databasanvändning
För att ge korrekt hållbarhet måste databaser använda någon form av synkronisering för att se till att informationen som skrivs har hamnat i icke-flyktig lagring snarare än att bara lagras i en minnesbaserad skrivcache som skulle gå förlorad om strömavbrott . PostgreSQL kan till exempel använda en mängd olika sync-anrop, inklusive fsync() och fdatasync() , för att commits ska vara hållbara. Tyvärr, för en enskild klient som skriver en serie poster, kan en roterande hårddisk bara utföra en gång per rotation, vilket i bästa fall ger några hundra sådana commits per sekund. Att stänga av fsync-kravet kan därför avsevärt förbättra commit-prestandan, men på bekostnad av eventuellt införande av databaskorruption efter en krasch.
Databaser använder också transaktionsloggfiler (vanligtvis mycket mindre än huvuddatafilerna) som har information om de senaste ändringarna, så att ändringar på ett tillförlitligt sätt kan göras om i händelse av krasch; då kan huvuddatafilerna synkroniseras mer sällan.
Felrapportering och kontroll
För att undvika dataförlust bör returvärden för fsync() kontrolleras eftersom när man utför I/O-operationer som buffras av biblioteket eller kärnan, kanske fel inte rapporteras vid tidpunkten för användning av write()- systemanropet eller fflush () anrop, eftersom data inte får skrivas till icke-flyktig lagring utan endast skrivas till minnessidans cache . Fel från skrivningar rapporteras istället ofta under systemanrop till fsync() , msync() eller close() . Före 2018 misslyckades Linuxs fsync() -beteende under vissa omständigheter att rapportera felstatus, ändra beteende föreslogs den 23 april 2018.
Kontroverser om prestanda
Hårddiskar kan som standard använda sin egen flyktiga skrivcache för att buffra skrivningar, vilket avsevärt förbättrar prestandan samtidigt som det skapar en risk för förlorade skrivningar. Verktyg som hdparm -F kommer att instruera HDD-styrenheten att spola skrivcachebufferten på enheten. Prestandapåverkan av att stänga av cachelagring är så stor att även den normalt konservativa FreeBSD- gemenskapen avvisade inaktivering av skrivcachelagring som standard i FreeBSD 4.3.
I SCSI och i SATA med Native Command Queuing (men inte i vanlig ATA, även med TCQ) kan värden specificera om den vill meddelas om slutförandet när data träffar diskens plattor eller när den träffar diskens buffert (ombord) cache). Om man antar en korrekt hårdvaruimplementering tillåter denna funktion att diskens inbyggda cache används samtidigt som den garanterar korrekt semantik för systemanrop som fsync . Den här hårdvarufunktionen kallas Force Unit Access (FUA) och den tillåter konsekvens med mindre overhead än att spola hela cachen som gjort för ATA (eller SATA icke-NCQ)-diskar. Även om Linux aktiverade NCQ runt 2007, aktiverade det inte SATA/NCQ FUA förrän 2012, med hänvisning till bristen på stöd i de tidiga enheterna.
Firefox 3.0, som släpptes 2008, introducerade fsync- systemanrop som visade sig försämra dess prestanda; anropet introducerades för att garantera integriteten hos den inbäddade SQLite -databasen. Linux Foundations tekniska chef Theodore Ts'o hävdar att det inte finns något behov av att "frukta fsync", och att den verkliga orsaken till Firefox 3-avmattning är den överdrivna användningen av fsync . Han medger dock (citerar Mike Shaver ) det
På några ganska vanliga Linux-konfigurationer, speciellt med ext3 -filsystemet i "data=ordered"-läget, rensar anropet av fsync inte bara ut data för filen den anropas på, utan snarare på all buffrad data för det filsystemet.