4k-Platten und Schreib-Schutz-Schalter

[Festplatten]

4k-Platten wären mal nett. Oder sind die schon zu normal-Preisen verfügbar ? Für die Hersteller müssten die ja sogar billiger sein.

Und Schreibschutzschalter wären auch mal nett. Sonst taugen Platten nicht zum Archivieren von beispielsweise VDR-Aufnahmen.
Jede SD-Karte ist schlauer weil schreibschützbar. MicroSD leider nicht, aber das ist wohl ein Platz-Problem.

Neue Festplatten-Techniken waren im Vergleich zu Tesa-Rom, EU-Elektro-Abfall-Verordnung, UMTS-Ausbau, LTE-Ausbau, VDSL, DSL,... nach Berichten in der ct doch sehr schnell in den Platten verfügbar, soweit ich mich erinnere.

[ohhmann]

ohh man soviel nonsense in einem post...sigma?

[Guest]

Du hast Recht, der fehlende Schreibschutz ist ein Unding, und rein vom Implementationsaufwand her eine Trivialität. Man kann Platten komplett sperren, aber nicht den Lesezugriff erlauben - läppsch!

Und der Schritt zu 4k-Blöcken ist wirklich überfällig, aber afaik tut sich da gerade was bei WD.

[Rainer Tsuphal]

ohhmann schrieb:
--------------------------------------------------------------------------------
> ohh man soviel nonsense in einem post...sigma?

siga08154711 oder so ähnlich, unverwechselbar.

[LARUNO]

Guest schrieb:
-------------------------------------------------------------------
> Und der Schritt zu 4k-Blöcken ist wirklich überfällig, aber
> afaik tut sich da gerade was bei WD.
Überfällig ist der wohl kaum. Bei 48 Bit LBA kannst du selbst bei 512Byte Blockgröße noch 128 PiB adressieren.
Momentan sind die Platten aber erst bei 2TByte.
Eine Vervierundsechzigtausendfachung der Kapazität ist in den nächsten paar Jahren jedenfalls extrem unwahrscheinlich.

Das einzige durch größere Blöcke umgehbare Problem wäre die 2TiB-Grenze des MBR, doch da gibt es bereits eine Lösung, die auch schon von einigen Betriebssystemen der letzten Jahre unterstützt wird.

Für einen Schreibschutz braucht es bei den alten ATAPI-Platten übrigens nur ein minimal modifiziertes Anschlusskabel. Pin 25 führt nämlich das Signal für den Schreibmodus. Bleibt der Pin auf logisch 0, dann ist da nichts mit Schreiben, während Lesezugriffe weiter funktionieren. Bei SATA-Platten ist das ganze etwas komplizierter, aber zur Not könnte man sich da mit 2 Adaptern (SATA-IDE und IDE-SATA) hintereinander behelfen und auf dem IDE-Bus wieder den entsprechenden Pin auf 0 setzen.
Es gibt zwar auch fertige Lösungen, aber die sind preislich so angesetzt, dass nur Behörden und Irre da zugreifen.

[512 sind lame]

Bei den 4K gehts auch um den inneren Verwaltungsaufwand für die Blöcke auf der Platte.
Dieselbe Platte hätte bei 4K-Blocks also ein paar Prozent mehr Daten-Volumen.

Wieg mal eine Plastikflasche mit 0,3 l und eine vom gleichen Hersteller mit 1,5 l. Vermutlich ist die 0.3l-Flasche * 5 schwerer als die 1,5l-Flasche. Oder setz eine 3,0001-l-pfandfrei-Flasche dagegen.

[Alf Edel]

LARUNO schrieb:
--------------------------------------------------------------------------------

> dass nur Behörden und Irre da zugreifen.


Hehe, Siga hat ja nur gefragt, er will nicht gleich kaufen...

[LARUNO]

512 sind lame schrieb:
-----------------------------------------------------------------
> Bei den 4K gehts auch um den inneren Verwaltungsaufwand für die Blöcke auf der Platte.
> Dieselbe Platte hätte bei 4K-Blocks also ein paar Prozent mehr
> Daten-Volumen.
Vom Verwaltungsaufwand und der Verwaltungsstruktur im inneren der Platte bekommst du als Nutzer eh nichts mit. Da interessiert nur, was das Betriebssystem aus einer Kapazität von n Sektoren bei Nutzung eines bestimmten Filesystems draus macht. Da üblicherweise aber mehrere Sektoren zu einem Cluster zusammengefasst werden, der meist 4K, aber durchaus auch davon abweichende Größen haben kann, spielt die logische Adressierung der Platte praktisch eh keine Rolle.
Wirklich relevant sind auch in Zeiten von LBA die Blockgrößen hingegen bei Flashmedien. Bei diesen sind aber kleinere Blöcke aufgrund der begrenzten Anzahl von Schreibvorgängen je Block wünschenswert.
Größere Cluster führen im übrigen zu wesentlich mehr Verschwendung von Plattenplatz, als evt. nötige größere Verwaltungsstrukturen, da jede Datei durchschnittlich einen halben Cluster mehr an Platz verbraucht, als eigentlich nötig wäre.

> Wieg mal eine Plastikflasche mit 0,3 l und eine vom gleichen Hersteller mit
> 1,5 l. Vermutlich ist die 0.3l-Flasche * 5 schwerer als die 1,5l-Flasche.
> Oder setz eine 3,0001-l-pfandfrei-Flasche dagegen.
Nicht alles, was hinkt, ist ein Vergleich.
Die Sektorengrößen bei Festplatten sind reine Adressierungsangaben. Sie haben nicht unbedingt etwas mit der tatsächlichen physikalischen Struktur der Daten auf der Festplatte zu tun.

[4k rules]

LARUNO schrieb:
--------------------------------------------------------------------------------
> > Daten-Volumen.
> Vom Verwaltungsaufwand und der Verwaltungsstruktur im inneren der Platte
> bekommst du als Nutzer eh nichts mit. Da interessiert nur, was das
> Betriebssystem aus einer Kapazität von n Sektoren bei Nutzung eines
> bestimmten Filesystems draus macht. Da üblicherweise aber mehrere Sektoren

In der ct stand mal, größere Blöcke hätten geringeren Overhead.


> Größere Cluster führen im übrigen zu wesentlich mehr Verschwendung von
> Plattenplatz, als evt. nötige größere Verwaltungsstrukturen, da jede Datei
> durchschnittlich einen halben Cluster mehr an Platz verbraucht, als
> eigentlich nötig wäre.
Dummes File-System.
Wer mal dieses kostenlose Windows xml-backup-programm genutzt und die xml-dateien angesehen hat, weiss, das NTFS die Inhalte sehr kleiner Dateien in den Metadaten hält, und dafür gar nicht erst einen weiteren Block anfängt.
Dumme Filesysteme fallen bei 4k-Blocks natürlich eher negativ auf.

Das man ultra-kleine Dateien bis unter 4k zusammenrottet, sollte klar sein. Das hat auch andere Gründe also Vorteile, wie man beispielsweise an den Kommentaren zu /usr/ports und Änderungen bei der Allokation bei BSD-ufs in den CHANGES vor einer Weile lesen konnte.

> Die Sektorengrößen bei Festplatten sind reine Adressierungsangaben. Sie
> haben nicht unbedingt etwas mit der tatsächlichen physikalischen Struktur
> der Daten auf der Festplatte zu tun.

Das mag sein. Trotzdem bin ich sicher, das in der ct von Vorteilen berichtet wurde.
Auch spricht dagegen, das Blöcke einzeln geschrieben werden. Dann müsste man bei Änderung eines Blockes immer die Blöcke drumherum schreiben, was die schreib-Performance mindern könnte. Siehe auch golem-Text von wegen "kleinere Schreib-Bereiche".

[ichwersonst]

4k rules schrieb:
--------------------------------------------------------------------------------
> LARUNO schrieb:
> ---------------------------------------------------------------------------
> -----
> > > Daten-Volumen.
> > Vom Verwaltungsaufwand und der Verwaltungsstruktur im inneren der Platte
> > bekommst du als Nutzer eh nichts mit. Da interessiert nur, was das
> > Betriebssystem aus einer Kapazität von n Sektoren bei Nutzung eines
> > bestimmten Filesystems draus macht. Da üblicherweise aber mehrere
> Sektoren
>
> In der ct stand mal, größere Blöcke hätten geringeren Overhead.
>
> > Größere Cluster führen im übrigen zu wesentlich mehr Verschwendung von
> > Plattenplatz, als evt. nötige größere Verwaltungsstrukturen, da jede
> Datei
> > durchschnittlich einen halben Cluster mehr an Platz verbraucht, als
> > eigentlich nötig wäre.
> Dummes File-System.
> Wer mal dieses kostenlose Windows xml-backup-programm genutzt und die
> xml-dateien angesehen hat, weiss, das NTFS die Inhalte sehr kleiner Dateien
> in den Metadaten hält, und dafür gar nicht erst einen weiteren Block
> anfängt.
> Dumme Filesysteme fallen bei 4k-Blocks natürlich eher negativ auf.
>
> Das man ultra-kleine Dateien bis unter 4k zusammenrottet, sollte klar sein.
> Das hat auch andere Gründe also Vorteile, wie man beispielsweise an den
> Kommentaren zu /usr/ports und Änderungen bei der Allokation bei BSD-ufs in
> den CHANGES vor einer Weile lesen konnte.
>
> > Die Sektorengrößen bei Festplatten sind reine Adressierungsangaben. Sie
> > haben nicht unbedingt etwas mit der tatsächlichen physikalischen
> Struktur
> > der Daten auf der Festplatte zu tun.
>
> Das mag sein. Trotzdem bin ich sicher, das in der ct von Vorteilen
> berichtet wurde.
> Auch spricht dagegen, das Blöcke einzeln geschrieben werden. Dann müsste
> man bei Änderung eines Blockes immer die Blöcke drumherum schreiben, was
> die schreib-Performance mindern könnte. Siehe auch golem-Text von wegen
> "kleinere Schreib-Bereiche".


Es geht hier um Sektorprüfsummen, Gaps usw. Der Vergleich mit den Flaschen war also angebracht und stimmig. Man sollte auch nicht das OS Filesystem mit der inneren Festplattenverwaltung verwechseln.

[Guest]

LARUNO schrieb:

> Überfällig ist der wohl kaum. Bei 48 Bit LBA kannst du selbst bei 512Byte
> Blockgröße noch 128 PiB adressieren.

Darum geht es nicht, sondern darum, daß man 512 Byte-Blöcke auf der HDD verwaltet, während seit Jahren das RAM sogar schon in 4k Pages verwaltet wird. Das ist wirklich lächerlich.

> Für einen Schreibschutz braucht es bei den alten ATAPI-Platten übrigens nur
> ein minimal modifiziertes Anschlusskabel.

Wirklich eine professionelle Lösung, sowohl PATA ist tot, als auch Rumgefrickel am Kabel im Business-Umfeld.

[Guest]

LARUNO schrieb:
> Sie
> haben nicht unbedingt etwas mit der tatsächlichen physikalischen Struktur
> der Daten auf der Festplatte zu tun.

Das ist FALSCH, sorry. CHS wird emuliert, die Blockgröße hingegen nicht. Ein 512 Byte-Block wird auf einer Festplatte mit Prüfsumme und Fehlerkorrektur, sowie Preamble auf das Medium geschrieben. Mit entsprechend ungünstigerem Verhältnis zwischen Nutz- und Gesamtdaten.

[4k rules]

Gibt es Infos wieviel Prozent mehr man auf die "gleichen" Scheiben bekommen könnte ?
"Platter" kennt hier keiner und zettelt gleich einen Rechtschreib-Stalinisten-Aufstand mit zig Mitläufern im Forum an wie beim letzten Mal, als Golem das Wort verwendet hat.
Und ganz gleich sind die Platter natürlich auch nicht, weil man ja die hard-Sectorierung ändert wie Guest schon beschrieben hat. Aber schlaue Leute würden das wissen und keinen Kleinkrieg von sowas anfangen.

Vermutlich ändert sich etwas an den Prüfsummen bzw. Recovery-Daten. Ob die kleiner werden können, weiss ich aber nicht.
Für IT-Anfänger: Bei Daten-CD-Roms sind die 2048-Bytes-Blöcke auf die Musik-CD-Blockgröße von 2323 (RAW) aufgebläht durch Recovery-fähige Prüfsummen für die 2048 Byte Nutzdaten. Macht man bei DVB auch und nennt sich dort sowas wie vorwärts-fehler-korrektur.
Das könnte bei größeren Blöcken schlechter aussehen oder vielleicht fettere Prüfsummen erfordern, um Fehler gleich gut zu entdecken.

[Guest2]

Danke, der erste vernünftige post hier.

Guest schrieb:
--------------------------------------------------------------------------------
> LARUNO schrieb:
> > Sie
> > haben nicht unbedingt etwas mit der tatsächlichen physikalischen
> Struktur
> > der Daten auf der Festplatte zu tun.
>
> Das ist FALSCH, sorry. CHS wird emuliert, die Blockgröße hingegen nicht.
> Ein 512 Byte-Block wird auf einer Festplatte mit Prüfsumme und
> Fehlerkorrektur, sowie Preamble auf das Medium geschrieben. Mit
> entsprechend ungünstigerem Verhältnis zwischen Nutz- und Gesamtdaten.

[It's Me]

Siga hat einen anderen Stil das ist wirklich unverwechselbar ;D

Schönen Samstag noch

Just Me.
[e-mail]