Warum…

[Grolox]

Linux , einfach MacOS und es gibt kein Problem mit Datenverlust .

[masterx244]

Asahi-Linux Reverse-engineert die Apple-hardware und das Getrickse das in Mac-OS versteckt ist. Der "Pfusch" mit dem Cache der nicht sofort geschrieben wird steckt auch im Apple-OS drin



1 mal bearbeitet, zuletzt am 17.02.22 13:52 durch masterx244.

[Enrico der Eunuche]

Grolox schrieb:
--------------------------------------------------------------------------------
> Linux , einfach MacOS und es gibt kein Problem mit Datenverlust .

Genau darum geht es doch. Den möglichen Datenverlust hast du genauso unter MacOS. Siehe auch den vorletzten Absatz des Artikels.



1 mal bearbeitet, zuletzt am 17.02.22 13:58 durch Enrico der Eunuche.

[yumiko]

Grolox schrieb:
--------------------------------------------------------------------------------
> Linux , einfach MacOS und es gibt kein Problem mit Datenverlust .
Andersherum - bei MacOS gibt es Datenverlust, da der Cache nicht garantiert geschrieben wird und bei Linux passt es dann. Zum Apple-TV schauen reicht es aber mit MacOS, da ist Datenverlust nicht schlimm, nur wenn man (wichtige) Sachen auf dem Rechner erstellt - dann besser zu einem Linux oder Windows-System greifen (falls man als normaler User dies in MacOS nicht aktivieren kann). Mehr kann man nicht rausziehen aus den gelieferten Informationen.

[Maslmaus]

APFS hat doch (genauso wie z.B. ZFS) Copy-On-Write, d.h. Daten werden sofort geschrieben.

Versteh jetzt ehrlich gesagt das Problem mit dem Cache nicht.

[MarcusK]

Maslmaus schrieb:
--------------------------------------------------------------------------------
> APFS hat doch (genauso wie z.B. ZFS) Copy-On-Write, d.h. Daten werden
> sofort geschrieben.
>
> Versteh jetzt ehrlich gesagt das Problem mit dem Cache nicht.

sie werden in den Cache geschrieben - strom weg - daten weg.

[Allandor]

Maslmaus schrieb:
--------------------------------------------------------------------------------
> APFS hat doch (genauso wie z.B. ZFS) Copy-On-Write, d.h. Daten werden
> sofort geschrieben.
>
> Versteh jetzt ehrlich gesagt das Problem mit dem Cache nicht.

Die Transaktion gilt als quasi schon als komplett, obwohl die Daten bislang nur im Cache liegen und noch nicht weggeschrieben wurden.
Das kann zu erheblichen Datenverlusten führen. Falls du dich an die "guten alten" Fat32 Zeiten erinnerst ... da konnte Windows sich immer mal wieder kaputt schreiben weil Sachen einfach nicht zu ende geschrieben wurden. Davon ist man vermutlich entfernt, aber wenn bei einem Update mal der Strom weg ist (Akku leer oder Stromausfall und kein Akku im Gerät) kann das durchaus mal schlecht sein.

[0xffff]

Achtung: hier werden Details vermischt.
CopyOnWrite sorgt dafür das Daten nicht unnötig zwei mal geschrieben werden müssen so sie identisch sind nachdem sie kopiert wurden. Da wird quasi nur ein inode angelegt der auf die selbe Datei zeigt.
Das andere is journaling bei der man atomar Dinge schreiben kann aber die Änderungen erst am Ende der Operation sieht.
Das schlimmste für einen Endkunden also passieren kann ist eher das ein Download dich nicht ganz fertig ist oder so.
Für eine Datenbank sieht das schon schlechter aus.
Aber auch nicht so schlimm dass es die datenintegrität beeinträchtigen würde.
Änderungen die bei einem Stromausfall nicht fertig geschrieben wurden würden eingach gar nicht im Filesystem auftauchen, und die Datenbank dadurch nicht ernsthaft beeinträchtigen.
Postgres z.B. würde nach einem reboot locker recovery so lange die Alten datafiles da und lesbar sind. Die unfertige Transaktion würde einfach fallengelassen.

[NeuerManuel]

"But on macOS, fsync() only flushes writes to the drive. Instead, they provide an F_FULLSYNC operation to do what fsync() does on Linux."

Das ist ein doofes wording von Apple.

"So effectively macOS cheats on benchmarks"

Definitiv nein. macOS hat einfach per default fsync off. Genau so wie jedes Windows oder jede SMB Freigabe.

"Of course, in normal usage, this is basically never an issue on laptops; given the right software hooks, they should never run out of power before the OS has a chance to issue a disk flush command. But it certainly is for desktops. And it's a bit fragile re: panics and such."

100% einverstanden, wenn das Wort "desktops" durch Workstations/Servers ersetzt wird.

"Not flushing means we cannot guarantee ordering of writes, which means you could end up with actual data corruption in e.g. a database"

Dafür ist ein Linux auf M1 Hardware eben schlicht nicht gemacht. Genau darum gibt es Serverhardware!
Dort kann ich sync writes von Datenbanken per ZFS SLOG auf persistente SSDs schreiben.

Der ganze Thread liest sich ein bisschen, wie wenn ich mich darüber beschwere, dass eine Samsung 980 Pro keine Server SSD ist und darum einen Stromunterbruch nicht sauber handhaben kann.
Tja, dafür ist sie eben nun mal nicht gemacht. Trotzdem ist es natürlich gut, wenn Apple den Bug beheben kann.

[MarcusK]

0xffff schrieb:
--------------------------------------------------------------------------------
> Achtung: hier werden Details vermischt.
> CopyOnWrite sorgt dafür das Daten nicht unnötig zwei mal geschrieben werden
> müssen so sie identisch sind nachdem sie kopiert wurden. Da wird quasi nur
> ein inode angelegt der auf die selbe Datei zeigt.

nein

> Bei Dateisystemen bedeutet Copy-On-Write, dass geänderte Blöcke nicht überschrieben,
> sondern zunächst vollständig an einen freien Platz kopiert werden.[

https://de.wikipedia.org/wiki/Copy-On-Write
das Sorgt dafür das eine Datei nicht kaputt geht, weil das original nicht verändert wird.
( wobei die Frage ist ob sich das wirklich auf Datei oder nur Cluster bezieht, wenn ich in einer 10GB Datei 1 byte ändere, wird hoffentlich nicht die ganze Datei kopiert )

[NeuerManuel]

MarcusK schrieb:
--------------------------------------------------------------------------------
> 0xffff schrieb:
> ---------------------------------------------------------------------------
> -----
> > Achtung: hier werden Details vermischt.
> > CopyOnWrite sorgt dafür das Daten nicht unnötig zwei mal geschrieben
> werden
> > müssen so sie identisch sind nachdem sie kopiert wurden. Da wird quasi
> nur
> > ein inode angelegt der auf die selbe Datei zeigt.
>
> nein
>

Doch! Du vermischt hier zwei Dinge.
ZFS ist immer COW.
ZFS ist nicht zwingend sync.


> das Sorgt dafür das eine Datei nicht kaputt geht, weil das original nicht verändert wird.

Darum geht es nicht. Meine Datenintegrität geht kaputt, wenn der Client meint etwas sei geschrieben worden, obwohl es in Realität noch gar nicht geschrieben wurde. Beispiel iSCSI oder NFS Client mit einer Datenbank, dessen Festplatte auf einem async TrueNAS liegt. Das wäre natürlich doof.


Das was du meinst mit hilft in einem anderen Fall. Angenommen ich habe ich ein SMB share (per default asynchron) und bearbeite ein eine bestehende Datei. Im Falle eines Unterbruches, können die Änderungen nicht aus dem RAM auf die Festplatte geschrieben werden. Da ZFS aber COW ist, bleibt einfach die alte Datei. Die Datei ist also konsistent. Die Datei ist vielleicht veraltet, aber sie ist NICHT korrupt. Wie eine Datenbank ist ZFS atomic.



2 mal bearbeitet, zuletzt am 17.02.22 16:15 durch NeuerManuel.

[jak]

0xffff schrieb:
--------------------------------------------------------------------------------
> Achtung: hier werden Details vermischt.
> CopyOnWrite sorgt dafür das Daten nicht unnötig zwei mal geschrieben werden
> müssen so sie identisch sind nachdem sie kopiert wurden. Da wird quasi nur
> ein inode angelegt der auf die selbe Datei zeigt.

Ähm nein. Also wenn du eine Kopie machst ja, aber bei einem write zeigt die inode dann natürlich auf die modifizierten Blöcke.

> Das andere is journaling bei der man atomar Dinge schreiben kann aber die
> Änderungen erst am Ende der Operation sieht.

Jein.

Das ist jetzt stark vereinfacht:

Meine Disk speichert Daten 0->a, 1->b, 2->x und Inodes 10->0, 11->1, ...

Nun möchte ich aber das 10 statt dem a ein x enthält.

Mit dem gängigen Metadaten Journaling ersetze ich das a in 0 durch ein x habe als 0->x, 1->b.

Mit Datenjournaling (langsam) schreibe ich journal = journal + [0->x], dann 0->x, und entferne dann x->0 aus dem journal. Ich muss alle Daten also doppelt schreiben, huch, nervig.

Mit CoW schreibe ich zuerst 2->x, dann schreibe ich 10->2, und markiere die 0 als frei. Die Metadaten kann man dann wieder in einem journal ablegen. Ich muss die Daten nur einmal schreiben und habe trotzdem die gleichen Garantien wie bei Datenjournaling. Krass!

[0xffff]

Einigen wir uns also darauf dass wir uns uneinig sind? ¯\_(ツ)_/¯

Ichs sehe zumindest kein Problem auf der Apple Seite was Datenintegrität angeht.
Wir es Linux in dem Fall anders handhabt kann ich allerdings auch nicht ganz verstehen.
Die Erklärungen hier ufern für mich leider etwas aus, aber ich denke es is am Ende des Tages kein echtes Problem und nur ein etwas aufgebauscht "News" Artikel, oder?

[nate]

> Ichs sehe zumindest kein Problem auf der Apple Seite was Datenintegrität
> angeht.

Dann schreib mal was auf die SSD, rufe "sync" auf (was eigentlich die Daten garantiert wegschreiben sollte) und ziehe den Stecker.

> Wir es Linux in dem Fall anders handhabt kann ich allerdings auch nicht
> ganz verstehen.

Im Gegenteil, das ist völlig verständlich: Linux möchte keine Daten verlieren. Wenn man Linux sagt "schreibe die Sachen aus dem Cache *jetzt* auf die Platte", dann tut es das auch. Das ist auch genau das, was der POSIX-Call fsync() verlangt. macOS hingegen ignoriert das einfach und sagt der SSD erst beim Ausschalten, dass der Cache wirklich weggeschrieben werden soll. Kann man auf einem Notebook machen, wo man einen plötzlichen Spannungsverlust nicht zu befürchten hat, aber Apple macht's auf Desktops genauso. Und das ist inakzeptabel.

[jak]

nate schrieb:
--------------------------------------------------------------------------------
> > Ichs sehe zumindest kein Problem auf der Apple Seite was Datenintegrität
> > angeht.
>
> Dann schreib mal was auf die SSD, rufe "sync" auf (was eigentlich die Daten
> garantiert wegschreiben sollte) und ziehe den Stecker.
>
> > Wir es Linux in dem Fall anders handhabt kann ich allerdings auch nicht
> > ganz verstehen.
>
> Im Gegenteil, das ist völlig verständlich: Linux möchte keine Daten
> verlieren. Wenn man Linux sagt "schreibe die Sachen aus dem Cache *jetzt*
> auf die Platte", dann tut es das auch. Das ist auch genau das, was der
> POSIX-Call fsync() verlangt. macOS hingegen ignoriert das einfach und sagt
> der SSD erst beim Ausschalten, dass der Cache wirklich weggeschrieben
> werden soll. Kann man auf einem Notebook machen, wo man einen plötzlichen
> Spannungsverlust nicht zu befürchten hat, aber Apple macht's auf Desktops
> genauso. Und das ist inakzeptabel.

Apple könnte es ja einfach lösen in dem sie einen Akku in die Desktops bauen sodass man dann noch den Cache flushen kann.

[NeuerManuel]

0xffff schrieb:
--------------------------------------------------------------------------------
> Einigen wir uns also darauf dass wir uns uneinig sind? ¯\_(ツ)_/¯

Meinst du mich? Ich bin ja deiner Meinung :)

> Kann man auf einem Notebook machen, wo man einen plötzlichen Spannungsverlust nicht zu befürchten hat, aber Apple macht's auf Desktops genauso. > Und das ist inakzeptabel.

Kann man auf jeder consumer hardware machen. Die Fsync Implementierung ist aber wirklich inakzeptabel und wird hoffentlich gefixt.


> Apple könnte es ja einfach lösen in dem sie einen Akku in die Desktops bauen sodass man dann noch den Cache flushen kann.
Wozu? Für die paar Nasen, die sync nutzten? Die brauchen es eh nur für Tests und nicht produktiv. Unabhängig vom Strom kann es auch andere Gründe geben, die das Schreiben auf die SSD verhindern. Ist also auch keine richtige Lösung.

[M.P.]

Dann sei mutig, zieh den Stecker SOFORT. Und berichte in 3 Minuten, was passiert ist ...

[NeuerManuel]

M.P. schrieb:
--------------------------------------------------------------------------------
> Dann sei mutig, zieh den Stecker SOFORT. Und berichte in 3 Minuten, was
> passiert ist ...

Habe keinen mac mini. Aber vielleicht beglückst du uns mit deiner Weisheit was genau geschehen sollte? Oder noch besser, wie es sich zu meinem Windows PC unterscheidet, wenn ich dort den Stecker ziehe?

[bernstein]

NeuerManuel schrieb:
--------------------------------------------------------------------------------
> Dafür ist ein Linux auf M1 Hardware eben schlicht nicht gemacht.

WTF? Linux ist genauso geeignet als Desktop OS wie macOS auch.

[bernstein]

jak schrieb:
--------------------------------------------------------------------------------
> Apple könnte es ja einfach lösen in dem sie einen Akku in die Desktops
> bauen sodass man dann noch den Cache flushen kann.
Dafür brauchts keinen Akku u.U. reicht der Strom in den Kapazitoren aus.