Interessante Funktion im neuen Linuxkernel 3.15

[Djfe]

Es wäre so cool wenn Windows folgendes beherrschen würde:
http://www.heise.de/open/artikel/Kernel-Log-Was-3-15-bringt-1-Dateisysteme-und-Storage-2183256.html

Schreibvermeidung
ASCII-Art-Beschreibung einer Funktion, aus der die Fallocate-Operationen COLLAPSE_RANGE hervorgegangen ist. Vergrößern
Bild: Screenshot von gmane.org Das VFS (Virtual File System) von Linux bietet jetzt die Fallocate-Operation ZERO_RANGE, die Dateibereiche durch Nullen ersetzt, ohne diese tatsächlich schreiben zu müssen. Ebenfalls neu ist die Fallocate-Operation COLLAPSE_RANGE. Video-Schnitt-Software kann mit ihr schnell Bereiche aus Dateien herausschneiden, ohne dazu die anderen Bereiche der Datei kopieren zu müssen; das Entfernen von Werbung aus einer Fernsehaufzeichnung gelingt so in Sekundenschnelle. Dateisystem-seitig beherrschen allerdings vorerst nur Ext4 und XFS die beiden neuen Operationen (1, 2, 3, 4).

Der TSD würde in vielen Fällen kaum noch schreiben müssen (zumindestens fürs Schneiden) und könnte in derselben Datei arbeiten und sich so sehr viele Schreibzugriffe sparen.

Das ist Innovation!
Hoffentlich kommt MS mal auf ähnliche Ideen... (solange es Windows noch vorherrschend ist)

[Mam]

Es wäre so cool wenn Windows folgendes beherrschen würde:
Hoffentlich kommt MS mal auf ähnliche Ideen... (solange es Windows noch vorherrschend ist)

Windows beherrscht sowas Ähnliches schon seit fast 30 Jahren, allerdings nur beim Erzeugen einer Datei. Nennt sich "SPARSE_FILE", und wird von einigen Programmen benutzt, die große Dateien vorab anlegen wollen, wie z.B. Filetransfer(Copy), Emule, Torrent usw.

Das, was Du beschreibst, "löscht" Bereiche innerhalb einer bestehenden Datei. Der Doc geht aber immer vollständig durch und kopiert die Daten in eine neue Datei um. Da hilft Dir Dein "Fallocate" überhaupt nichts, denn der Doc schreibt die auszulassenden Bereiche eh nicht mehr in die neue Datei.
Insgesamt fände ich die Anwendung des (durchaus netten) Features für zu gefährlich, denn ein falscher Mausklick, und schwupps sind die (Original)Daten weg!
Kein Undo, Aufnahme zerstört... nee nee... bitte nich...

[Djfe]

...und man hätte überall leere Stellen zwischen den Aufnahmen/mehrere Fragmente, oder nicht?

wird auch für den Doc deshalb nicht viel helfen, weil er nicht bloß schneidet sondern auch repariert und die Timings ändern muss (er muss also die ganze Datei anpacken)
außerdem hätte die ganze Datei Lücken, wenn man eine Tonspur entfernt

fands trotzdem ne Erwähnung wert.

[Mam]

...und man hätte überall leere Stellen zwischen den Aufnahmen/mehrere Fragmente, oder nicht?

Nö, zumindest keine leeren Stellen. Das Feature wird wohl durch einen speziellen Eintrag im Verzeichnis realisiert werden. Für den Anfangsblock würde die Anzahl der gültigen Bytes notiert, alle vollen Blöcke dazwischen würden als "frei" wieder zurückgegeben, und beim Endblock müsste wieder notiert werden, welche Bytes vorne zu überspringen sind.
Fragmente gibts natürlich zwangsläufig. Aber, wer hat noch keine SSD? 

Ich befürchte allerdings, dass einige vorhandene Tools bei solchen Dateien "ins Essen brechen" werden, denn, wenn sie blockorientierte IO machen, müssen sie plötzlich mit "halben Blöcken" rechnen und darauf reagieren. Oder, sie produzieren volle Matsche, weil sie die Ausschlüsse ignorieren und die "leeren" Bytes trotzdem verarbeiten.
Also, insgesamt, nicht wirklich vertrauenseinflössend und nur geeignet für sequentiellen Zugriff...