• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Gedanken zu BTRFS

revealed

Guru
/Mitteilungsbedürfnismode On:

Für mich spielen auch diese Argumente hinein:

--Expectation V.S. reality:
Der vorteil eines Perfomance-Gewinn durch den Einsatz gegenüber BTRFS für "/" und Xfs für "/home" ist in dieser Skalierung meiner Meinung nach quasi nicht vorhanden. Das eine Dateisystem sei wohl eher für schnelle Festplattenzugriffe in kleineren Schlücken optimiert. Während das andere seine Muskeln beim Transfer von großen Schlücken erst so richtig spielen lassen kann. So gibt sich das bei entsprechender Skalierung, also beispielsweise dem arbeiten mit Großen Datenbanken messbar im vergleich zu anderen setups die Hand. Wenn man jetz hier und da n bissl Youtube Videos schaut und/oder surft, vielleicht was mit Libre Office macht usw., bissl E-Mails checken.... Man merkt von diesem Vorteil schlicht garnichts. Dazu kommt der höhere Administrationsaufwand. Ohne einlesen gehts momentan nicht.

Was sehr vorteilhaft ist, für den Desktop Nutzer ist bei BTRFS, ist eben das rollback -- egal in welcher Skalierung. Das ist derzeit aber weder mit Xfs noch mit ext4 vorkonfiguriert / machbar (Wiederum durchaus möglicherweise von devs geplant bzw. Grundsteine gelegt). Man hat diesen speziellen vorteil also zunächst mal nur für "/".

Was kein Argument ist. Dass ausschliesslich BTRFS und XFS für eine SSD optimiert seien. (Ein Gerücht dass sich leider in meinen Augen hartnäckig hält.) Keineswegs wurde ext4 einfach so in die Ecke geworfen, weils jetzt BTRFS und Xfs zur Auswahl gibt.

Bei Ext4 müsste man sich wieder weiter auf seine klassischen Backup und recovery Methoden besinnen und einfach das ausgewogene Leistungsverhältnis nutzen.

Große Datei - kleine Datei. Wenn man ext4 ext4 für "/" u. "/home" nimmt, dann ist das im gegebenen Umfang gleich schnell.

Dazu traue ich persönlich bei einer SSD dem Konzept eines Copy on Write filesystems nicht (btrfs)!!!
Es tut mir sehr leid. Aber sehr offensichtlich hat eine SSD eine begrenzte vom hersteller angegebene Kurzlebigkeit. So gibt der hersteller an wie oft Blöcke geschrieben/gelöscht (usw.) werden können. Durch diese ge copy on write -erei und schnappschusserei werden einfach zusätzliche Daten geschrieben die u.U. schlicht nicht benötigt werden.

Wenn mein Rechner nie abstürzt oder ich nie zurückrollen muss, dann schreibe ich 5 Jahre lang bei jeder Änderung unnützes Zeug auf eben genau diese SSD.

[....]

Was ich jetzt aber zugeben muss. Ich sollte mir Xfs nochmal genauer anschauen und evtl beispielsweise abwägen ob ext4 und xfs Sinn macht.

Und wenn in 5 Jahren diese SSD mit egal welchem Dateisystem immernoch lang nicht tot ist, ist mir diese SSD warscheinlich:
1. Zu alt
2. Zu langsam
3. Zu klein
4. Zu --- keine Ahnung was.

Aber reist es das raus?

Mit so ner zwischenzeitlich billigen alten Samsung evo 840 mit 120 GiB:
Code:
wild-thing:/home/disk # hdparm -Tt /dev/sdb

/dev/sdb:
 Timing cached reads:   29804 MB in  2.00 seconds = 14925.72 MB/sec
 Timing buffered disk reads: 1576 MB in  3.00 seconds = 525.30 MB/sec
Das kann ich nicht messen, wie soll ich es im Alltag bemerken?

Wenn es aktuell nochmal eine Abstimmung geben würde, was für die Partitionierung bei der Installation standardmäßig vorgeschlagen wird. An der ich teilnehmen dürfte. Ich würde ext4, ext4 stimmen.

/Mitteilungsbedürfnismode Off.

Gruß,

R
 

josef-wien

Ultimate Guru
Es hat zwar auch nichts mit dem Thema zu tun, aber:
revealed schrieb:
Dazu traue ich persönlich bei einer SSD dem Konzept eines Copy on Write filesystems nicht
Bei einer SSD gibt es nichts anderes. Wenn Du in einem Sektor auch nur ein einziges Bit änderst, muß der gesamte Sektor neu geschrieben werden (das geht technisch nicht anders und wird von der firmware erledigt, das Dateisystem spielt dabei nicht mit). Ob ein Dateisystem jetzt den ursprünglichen Inhalt nach wie vor "in Evidenz hält" oder einfach vergißt (d. h. ab sofort den logischen Sektor als leer betrachtet und gegebenenfalls die firmware via trim darüber informiert), spielt für die Lebenserwartung einer SSD keine Rolle.

btrfs hat durchaus seine Vorteile, wenn man sie bewußt nutzt (und nicht kritiklos die für den Normalanwender "unglücklichen" openSUSE-Voreinstellungen verwendet); für mich ist ein Dateisystem, das der Entwickler im Herbst 2014 für "stabil" erklärt hat, noch zu jung. Bei xfs sind für mich die Nachteile deutlich stärker als die Vorteile.
 
OP
revealed

revealed

Guru
Ich verstehe es n bisschen so.

Von der gesamten festplatte:
|----------------------------------------|
Nutze ich:
|boot|--btrfs--|------xfs-----|swap|
Irgendwie sind diese blöcke alle möglichst auf die Partitionen zur Gänze zugewiesen.

Das copy on write nutzt eventuell hauptsächlich Blöcke, die schon existent waren. Freilig bleiben bei diesem Gedanken ungenutzte Blöcke zunächst ungenutzt.

Wenn ich aber jetzt mit YaST etwas ändere (Drucker) und der nen Snapshot pre post - bis zu 10x jeweils davon extra macht, alle betroffenen Dateien mit zieht. Da wird doch dann in diesen Blöcken aus dem Fitzel btrfs mehr geschrieben als vorher vorhanden war bis es schliesslich voll ist? Also nicht nur btrfs. Sondern alles das was Snapper zusätzlich tut.

Hab so den Verdacht (btrfs/snapper):
|sane|--dead---|--average---|dead|

Bei Ext4 belibt das halt einfach frei.
|sane|-average-|--average---|dead|

Sollt ich das lieber vergessen? Ich verstehe es schon so, dass all dieses Zusätzlilche irgendwo hin muss. Sonst würde die btrfs Partition nicht voll werden und nur mit gegebenen Mitteln arbeiten.

Gegebene Mittel: Dann hätte Snapper nur zur Verfügung was es eben grad (noch) hat. Und nicht unbedingt, was der User will.

Freilig bekommen wir die Platte in 5 Jahren selbst mit BTRFS nicht kaputt. Schätze ich.

Gruß,

R
 

josef-wien

Ultimate Guru
revealed schrieb:
Von Deinem letzten Beitrag kann ich das nicht behaupten.

Bei einem Schnappschuß werden keine Daten kopiert. Ein Schnappschuß ist eine Liste, welche Dateien bzw. Dateiversionen zu einem bestimmten Zeitpunkt Gültigkeit haben. Das Volllaufen der Partition entsteht dadurch, daß alte Dateiversionen nicht entfernt werden, und je öfter man Pakete aktualisiert, umso schneller passiert es bei der Systempartition.

Nachdem das Ganze mit dem Thema nicht wirklich zu tun hat, solltest Du einen Administ- bzw. Moderator bitten, die Beiträge abzutrennen und ein eigenes Thema zu schaffen.
 
OP
revealed

revealed

Guru
Mach ich mal hiermit gleich: ---> Bitte ! Abtrennen ! <---

Und entschuldige mich auch hiermit hoffentlich ausreichend beim TE. Und bedanke mich auch gleich für den Extra Aufwand.

Falls nötig, eventuell Titel soetwas wie "Nachhilfe für revealed zu BTRFS"

-> Entschuldige!

Gruß,

R
 
OP
revealed

revealed

Guru
Es will immernoch nicht ganz rein.

Ich hab jetz hier so nen Gedankengang wie:

Btrfs:
Ein Feld voller Tretminen. Auf jeden freien Fleck, auf den man tritt legt man eine neue ab, bis das Feld voll ist.

Ext4:
Ein teil des Feldes wird für Tretminen genutzt. Diese liegen mehr oder weniger am gleichen Fleck.
 
A

Anonymous

Gast
Also ich habe auf meiner 120er SSD diese Aufteilung

Code:
/dev/sda1 -   2,01 GiB  
/dev/sda2 - 40,0   GiB  btrfs  (Mounted on /, /boot/grub2/i386-pc, /boot/grub2/x86_64-efi, /opt, /.snapshots, /srv, /tmp, /usr/local, /var/crash, /var/lib/mailman, /var/lib/named, /var/lib/pgsql, /var/log, /var/opt, /var/spool, /var/tmp)
/dev/sda3 - 73,2  GiB  xfs

Bisher hatte ich auf dieser Platte/Partition(en) noch keine Probleme; auf der HDD schon eher :D

Btrfs:
Ein Feld voller Tretminen. Auf jeden freien Fleck, auf den man tritt legt man eine neue ab

Was meinst du mit Tretminen?
 
OP
revealed

revealed

Guru
Copy on write. Einen Schreibvorgang. Beispielsweise eine geänderte Konfigurationsdatei. Die alte lasst man gekennzeichnet liegen. Dafür legt man eine neue an. Wenn ich die nochmal ändere, dann hab ich schon zwei alte gekennzeichnete liegen. Und die neue. Dann setz ich mal n Limit von 10 dafür. Und fange dann wieder bei der ersten an.
 
A

Anonymous

Gast
War der Meinung (so hatte ich das auch in einem Beitrag verstanden) dass btrfs bei Anlegen einer (bereits vorhandenen) Datei diese überschreibt und dann speichert; kann man es nicht einstellen, oder ein Script schreiben, dass beim neu erstellen die Alte überschrieben, bzw. ein Duplikat gelöscht wird?
Ist das bei xfs bzw. dem alten Dateisystem unter Linux auch so, dass so viel "Müll" produziert wird?
 
OP
revealed

revealed

Guru
Ja halt eben Snapper.

Aber wenn copy on write dann so umherwandert auf der Platte und immer halt nen Block hernimmt der grad mal frei ist und eventuell auch nich zusammenhängt?

Und ext4 so entwickelt wurde, dass Fragmentierung grundlegend vermieden wird. Bedeutet für mich auch dass Dateien immer zusammenhängen irgendwie. Da macht sich bei mir wieder der Gedanke breit, btrfs schreibt mehr als ext4.

Ich wandere gerade auf dem Grad warum ich bei dem Performanceeinbruch den ich auf meinem Laptop messbar hatte durch btrfs und xfs zu dieser offensichtlichen Missdeutung gekommen bin. ext4 läuft auf dem Ding viel schneller.

Dass ich mir da n bissl was zusammengereimt habe und das noch immer tue kann man ja sehen.

Gruß,

R
 

josef-wien

Ultimate Guru
revealed schrieb:
dass Fragmentierung grundlegend vermieden wird
Die firmware einer SSD interessiert das überhaupt nicht, die speichert so, daß die einzelnen Speicherzellen möglichst gleichmäßig verwendet werden. Im übrigen ist jede Speicherzelle gleich schnell erreichbar.

revealed schrieb:
Performanceeinbruch
Bei der ersten SSD, die mit der Zeit die gespeicherten Daten vergißt, sehe ich andere Ursachen. War das vor oder mit der firmware-Version, die regelmäßig die Daten umspeichert?
 
OP
revealed

revealed

Guru
Nein eine alte Laptop HDD rotational im Thinkpad T60 ab werk mit aktueller firmware .. 60 oder 80 GiB ca..

Ich versuchs mal so, da ich das offensichtlich nicht wirklich kapiere -- auch mit Lesen nicht.
Also muss ich bezüglich mehr oder weniger schreibvorgängen echt keine Angst haben? Dann mach ich sowas wie (noch mehr hirnzellen platzen lassen) und das vergessen.

Das T60 is mir regelrecht in die Knie gegangen mit BTRFS. Und seit ich es mit ext4 aufgesetzt habe läufts super flott. Im rahmen der Fähigkeiten, entsprechend dem alter der Hardware.

Am Desktop mit TW und der SSD kam mir btrfs noch nicht in den Sinn. Noch weniger seit der Erfahrung mit dem Laptop.

Die Festplatte hat gar nicht mehr aufgehört zu Rödeln beim T60. Und da bin ich empfindlich, weil -- da läuft zwar das Betriebssystem auf der einzigen Festplatte. Aber in jeder freien Minute durch cache tuning usw. browserprofile im RAM,. etc... kann ich es erreichen, dass die Festplatte auch mal bis zu 3 minuten im Betrieb abschaltet (auf Akku).

War mir im btrfs einsatz nicht möglich. Und boot dauerte viel länger. Jegliches Öffnen etwäiger Anwendungen. (Schlimm). -- Gut ist auch schon wieder ne weile her. Und auf der Kiste ist jetzt Leap mit ext4 -- und vorher war es 13.2 mit btrfs / xfs.

Gruß,

R
 

josef-wien

Ultimate Guru
revealed schrieb:
Also muss ich bezüglich mehr oder weniger schreibvorgängen echt keine Angst haben?
Hinsichtlich der Schnappschüsse sehe ich keine Gefahr einer "vorzeitigen Abnützung". Die
josef-wien schrieb:
Liste, welche Dateien bzw. Dateiversionen zu einem bestimmten Zeitpunkt Gültigkeit haben
(wie auch immer sie technisch realisiert ist) muß natürlich gespeichert werden, und die bei jeder Sitzung in Deinem Heimatverzeichnis geänderten Konfigurationsdateien nützen Deine SSD viel, viel mehr ab (aber auch das wird sie verkraften).
 
OP
revealed

revealed

Guru
Irgendwie fuxt mich das.

Es währe sehr interessant für mich etwas zu sehen wie:
- Vorgabe: Etwas wie -- Eine Ordnerstruktur mit einigen Unterverzeichnissen und Inhalten kopieren, verschieben und wieder löschen. (evtl. 2x)
- Eine Gegenüberstellung von blk/wrtn von einem BTFS mit konfiguriertem Snapper und ext4 beim selben Vorgang.
- (Passiv ohne dass das Betriebssystem läuft).

Und dann noch hdparm -tT oder sowas jeweils.

Müsste mal schauen. Kann mir kaum vorstellen, dass sowas noch nicht gemacht wurde. Ansonsten überleg ich gerade n bisschen ob ich evtl. zwei qcow2 auf diese art an eine VM anhänge und das selber probiere.

Könnte die blk/wrtn ja beispielsweise mit 'iostat' anschauen.

Messergebnisse vom Profi wären mir allerdings lieber.
Hier beispielsweise: http://www.phoronix.com/scan.php?page=article&item=linux-40-ssd&num=3
Geht es denk ich nur darum welches mal grad unter jener und welcher Bedingung schneller ist, nicht was (ökonimischer) arbeitet. Oder hab ich es nich gesehen. Vielleicht auf Seite 2? Ne, die test sind alle: "More is better".

Gruß,

R
 

Bequimão

Member
Hi,

Mein erster Kontakt mit btrfs: ein Vortrag von Josef Bacik 2010 in São Paulo, Ich benutze btrfs seit ca. 2 Jahren produktiv. Eine SSD habe ich nicht und werde erst in ca. 2 Jahren über eine Neuanschaffung nachdenken. Ich habe zuerst openSUSE 13.1 mit btrfs als Test installiert, bin aber nicht dazu gekommen, tiefer einzusteigen. Mitte 2014 war ich zunehmend unzufrieden mit Debian testing und sid, so daß openSUSE mein Hauptsystem wurde. Um Benchmarks habe ich mich nie gekümmert. Gefühlt war btrfs den vorherigen Systemen gleichwertig. OpenSUSE 13.2 und Leap habe ich jeweils neu installiert. Konfigurationsdateien von Snapper habe ich nie geändert. Die besonders fetten post-install Snapshots habe ich möglicherweise manuell gelöscht. Die Installationen habe ich jetzt nicht mehr.

@ Cerberos: Futzeldateien werden kaum 10 x geändert, und wenn macht das nichts aus. Interessant ist, wie btrfs mit großen Dateien umgeht. Hier werden nur geänderte Blöcke gespeichert. Das Verfahren ist also sehr effektiv. Die Empfehlung, doppelten Speicher zu nehmen, hat sich bei mir bewährt. Im Übrigen hast du ja kürzlich ein # snapper rollback erfolgreich ausgeführt.

@ revealed: Ich benutze btrfs als logische Partition in einem LVM. Backups mache ich nur von den /home- und Datenpartitionen meines Multi-Bootsystems. Bei ext4 habe ich früher Images mit rsync auf eine externe HD kopiert und damit eine Installation geklont, bzw. auf einen anderen Rechner verschoben. Das scheint mir bei btrfs eine größere Operation zu werden. Schließlich muß man alle Subvolumes einrichten und vor dem Kopieren mounten. Ich werde das mal in Angriff nehmen.

Viele Grüße
Bequimão
 
OP
revealed

revealed

Guru
Bequimão schrieb:
Schließlich muß man alle Subvolumes einrichten und vor dem Kopieren mounten
Entzieht sich meiner Logik, wenn man (RAW Daten) kopiert. Mal abgesehen vom Bootsektor.

Das kopiert es doch alles mit, wenn du die komplette sda in ein Image schiebst. Nicht?

Bin bei dem ganzen Thema grad irgendwie aufgelaufen.

Ich hab irgendwie im Hinterkopf. Ich könnte mich von BTRFS evtl noch gänzlich überzeugen lassen. Aber ich bräuchte vorher was wie ein Testsetup:

K.a.
- Irgend eine VM einrichten.
- 2 qcow extra separat erstellen. Eine mit BTRFS, die auch an Snapper angebunden wird. Eine mit ext4.
- Jeweils k.a. vielleicht ne openSUSE ISO drin ablegen und eine Struktur mit größeren und kleinen Dateien.
- Dann den kompletten Inhalt jeweils hin / und herschieben.
- Dann löschen.
- Und mit iostat die kb_wrtn anschauen?

Überlege mir gerade für jede qcow2 evtl ca. 10 gib vergeben. VirtIO müsste passen. Der VM geb ich mal 2 GIB RAM und 4 cpu's.

Hab hier eine Tumbleweed VM mit Xfce. Glaube ich nehme die. (KVM/qemu).
Code:
revealed@linux-rqyt:~> lsb-release -a
LSB Version: n/a
Distributor ID: openSUSE project
Description: openSUSE Tumbleweed (20160417) (i586)
Release: 20160417
Codename: n/a

Das möchte ich wissen. (Schnelligkeit würde ich mal aktuell noch relativieren). Da man so im Konsumerdesktopbereich weder BTRFS noch XFS noch ext4 richtig auslastet. Das is genauso wie sich ein striping einrichten und dann damit Counter-Strike zocken. Des rockt erst so richtig bei großen Dateien. Computerspiel daddeln wäre damit quatsch.

Sicherheit / Robustheit. Da bin ich wohl immer noch mit ext4 auf der sicheren Seite.

Mal nur 2 komische leere virtual disks auf dem selben Datenträger einer rotational disk des Hostsystems angelegt:
- (hdparm aus der VM) Ergebnis ist reproduzierbar:
linux-rqyt:/mnt # mount | egrep "vdb|vda"
/dev/vda1 on /mnt/BTRFS type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)
/dev/vdb1 on /mnt/EXT4 type ext4 (rw,relatime,data=ordered)
linux-rqyt:/mnt # hdparm -Tt /dev/vda

/dev/vda:
Timing cached reads: 21212 MB in 2.00 seconds = 10621.95 MB/sec
Timing buffered disk reads: 7876 MB in 3.00 seconds = 2625.29 MB/sec
linux-rqyt:/mnt # hdparm -Tt /dev/vdb

/dev/vdb:
Timing cached reads: 21884 MB in 2.00 seconds = 10958.94 MB/sec
Timing buffered disk reads: 4244 MB in 3.01 seconds = 1410.03 MB/sec
linux-rqyt:/mnt #

Jetz hab ich mal beide Platten eingehängt. Und folgendes für die BTRFS abgesetzt:
Code:
snapper create-config /mnt/BTRFS
Jetzt frage ich mich... wird dieses '.snapshot' auf der BTRFS-Platte angelegt oder auf der System-Platte vom GAST, eh der VM?
Antwort: Scheint mir auf der BTRFS angelegt worden zu sein. <-

Hmm... Nunr Daten zusammenstellen. Nehme auf jeden Fall eine runtergeladene ISO... Und vielleicht kopier ich noch eine Struktur dazu... k.a. ehm:
- Leap (ca. 4.3 GIB).
- Den inhalt von /var/ (ca. 423M)

Das leg ich dann im Wurzelverzeichnis ab in "/TESTFILES" damit ich das von dort aus dann jeweils auf die BTRFS und Ext4 Rüberschieben und beobachten kann usw.

- Dann installier ich mal iostat...
Code:
zypper in sysstat
Hatte dann zum monitoring an folgenden Befehl gedacht:
Code:
watch -n1 iostat

Problemstellung: Muss die Zähler auf 0 setzen irgendwie??
- Schnall ich nicht, deswegen erstmal die Ordnergröße:
Code:
du -hs /TESTFILES/

ACHTUNG:
(Hätte gerne alles rüber kopiert, aber ich bekomme ne Fehlermeldung bei beiden Dateisystemen):
Code:
Value too large for defined data type
tp://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Value-too-large-for-defined-data-type
- Denke Es liegt an der 32 Bit VM.

Dann erstmal zu VDA1. BTRFS:
- Vor dem kopieren der Struktur ist der Basiswert von: kb_wrtn 10156
- Ich setze dann folgenden Befehl ab:
Code:
cp -pr /TESTFILES /mnt/BTRFS; rm -rf /mnt/BTRFS/TESTFILES
- kb_wrtn nach dem Vorgang: 4968620
- Macht eine Differenz (Ergebnis von): 4958464

Dann das gleiche für VDB1. ext4:
- Vor dem kopieren der Struktur ist der Basiswert von: kb_wrtn 298340
- Ich setze dann folgenden Befehl ab:
Code:
cp -pr /TESTFILES /mnt/EXT4; rm -rf /mnt/EXT4/TESTFILES
- kb_wrtn nach dem Vorgang: 5225668
- Macht eine Differenz (Ergebnis von): 4927328

Unteschied beim test:
- Ext4 schreibt bei meinem Test 31136 Zähler weniger als BTRFS
- BTRFS schreibt bei meinem Test 31136 Zähler mehr als Ext4

Das wären ca. 31 MB Unterschied bei der Datenmenge. (Ohne Haarspaltereien und Diskussion über MiB / MB). Demnach wäre, wenn ich an eine weit größere Datenmenge verteilt über das ganze Jahr, ext4 direkt schonend.

Jetzt aber... ich bin kein PRO. Würde so ein Test bitte ein Profi machen? Wer schreibt mehr?

Gruß,

R

PS: Bitte Gegenbeweise anzuführen. Ich kann mir selbst nicht glauben.
 
A

Anonymous

Gast
Irgendwie bis du total auf dem Holzweg mit deinem Testsetup, was willst du mit diesen Tests den beweisen?

- Irgend eine VM einrichten.
- 2 qcow extra separat erstellen. Eine mit BTRFS, die auch an Snapper angebunden wird. Eine mit ext4.
- Jeweils k.a. vielleicht ne openSUSE ISO drin ablegen und eine Struktur mit größeren und kleinen Dateien.
- Dann den kompletten Inhalt jeweils hin / und herschieben.
- Dann löschen.
- Und mit iostat die kb_wrtn anschauen?

Überlege mir gerade für jede qcow2 evtl ca. 10 gib vergeben. VirtIO müsste passen. Der VM geb ich mal 2 GIB RAM und 4 cpu's.

damit legst du geschätzte 8 bis 12 Treiber übereinander die ihrerseits noch an mehreren Stellen gecacht oder gebuffet sind und das in der Mitte wahrscheinlich noch eine 100% virtuelle Schicht als sparse qcow Platte ? Diese ist wird dann bei ersten beschreiben in dem Dateisystem in dem sie liegt extrem hoch fragmentiert abgelegt.
Dann schreibst du im größerem Stiel in ein neues Dateisystem sequenziell irgendwelche Daten um sie hinterher sofort wieder zu löschen. Mal abgesehen von der Treiberhirachie die du jedes mal bemühen musst bevor auch nur ein einziger Block mal bis zur wirklichen physikalischen Festplatte vorankommt, es sind dort massenweise verfälschende Faktoren im Spiel die alle Tests schon im Vorhinein mehr oder weniger wertlos machen.

Wie hoch ist die Wahrscheinlichkeit, dass du mit deinem Dateisystem nichts weiter machst als eine größere Dateimenge sequentiell in ein neues Dateisystem zu schreiben und dann alle wieder löscht?
ZB: bei dem Befehl hier: (nur mal aus der Sichtweise der VM und ohne Berücksichtigung das die VM gar nicht selbst auf eine richtige physikalische Platte schreibt)
Code:
cp -pr /TESTFILES /mnt/EXT4; rm -rf /mnt/EXT4/TESTFILES
würden die letzten was weiß ich viele zig bis 100 MB gar nicht erst mehr geschrieben, weil sie schon im Speicher wieder gelöscht würden bevor der Sync vom ext4 sie versuchen würde auf platte zu schreiben.
Ich denke mal dieses Testszenario würde eventuell für Test für ein Backupdateisystem geeignet sein, aber nicht dem Entsprechen was du tag täglich für Anspüche auf ein /daten /home oder gar Root-Dateisystem hast.

Wenn du ergründen willst was dir das eine oder andere Dateisystem für Vorteile oder Nachteile bringt, dann fährst du mit folgendem Testszenario bestimmt besser wie folgt

  • nimmt 3 gleichgroße Platten.
    auf die erste machst du eine Neuinstallation ext4 und ohne separates /home (also alles in ein Dateisystem)
    auf die zweite machst du eine Neuinstallation btrfs und ohne separtes /home
    die dritte bleibt erstmal unbenutzt liegen.
dann richtest du die beiden Systeme (einmal ext4 und einmal btrfs) alle so her wie du sich brauchst, fährst sie jeden tag hoch und machst auf dem Rechner was immer du sonst auch machst, machst regelmäßig alle Updates usw. Und das ganze machst du mit beiden Platten ein viertel Jahr lang also ganz normal mit beiden Platten arbeiten, egal ob da auf der einen nur 100 oder 1000MB. oder aber das eine oder andere Paket mehr oder weiniger drauf ist, ist vollkommen egal. Wichtig dabei, das sie für dich typisch in Verwendung waren.

Dann nimmt du die erste dieser Platten und machst mit dd eine Kopie auf die dritte Platte
die dritte Platte wird dann getestet, hier kannst du jetzt deine massenweise Test Dateien hinschaufeln und nach einem sync oder umount/mount dann später wieder löschen und dabei den IO und das eine oder andere noch mit geeigneten Tools mitprotokolieren

Dann nimmst du die zweite Platte und machst mit dd eine Kopie auf die dritte Platte
und auch dieses Kopie auf der 3. Platte dann genauso getestet wie mit dem Image von der ersten Platte.

Dann kannst du dich darüber her machen die IO und anderen aus den Tests gewonnenen Daten zu vergleichen. Du wirst sehen oder auch nicht wie unterschiedlich sich die beiden gleichgroßen nur im Dateisystemformat unterschiedlichen und längere Zeit normal benutzten Dateisysteme beim schreiben/lesen ... dann verhalten.
Zudem hast du dann ja auch noch die Erfahrungswerte von dem viertel Jahr das du beide Dateisysteme in einem annähernd identischen System ausprobiert hast.

meine Meinung zu btrfs und OpenSuse habe ich schon vor länger Zeit zB hier im Thread mal geschrieben. Gutes bis geniales Dateisystem für Leute die wissen was sie tun und was sie wollen, aber bitte nicht für Otto Normallinuxer als Default root. Diese ist und war eine politische Lösung in Vorbereitung und Weitsicht auf SLES12 und weil man in SLES ext4 vollkommen verschlafen und Stiefmütterlich behandelt hat. Aber wie es immer so schön heißt, wer bezahlt, der sagt auch wo es hingeht.

robi
 
OP
revealed

revealed

Guru
Ich will wissen ob und wieviel mehr Daten auf eine Festplatte und in welcher Größenrelation BTRFS im vergleich zu ext4 schreibt.

Das mit den Treibern kann ich insofern nicht wirklich nachvollziehen, da die VM einfach die selben Mechanismen verwendet. Warum sollte iostat in einer VM etwas anderes anzeigen als auf echter Hardware.

kb ist kb.

Dumm nur, dass meine 64 Bit VM grad anderweitig urlaub hat. Wiederum kann ich so einen Aufbau mit 'echter' Hardware hier garnicht realisieren. Hoffe ich werde jetzt nicht niedergemacht, weil ich darum bitte.

Gruß,

R
 

marce

Guru
revealed schrieb:
Ich will wissen ob und wieviel mehr Daten auf eine Festplatte und in welcher Größenrelation BTRFS im vergleich zu ext4 schreibt.
Doofe Frage: Was erwartest Du Dir davon? Die Frage ist für den tagtäglichen Einsatz rein akademisch, fern jeder Praxisrelevanz.
 
OP
revealed

revealed

Guru
Ganz einfach. Ein Dateisystem, das weniger unnütze Daten schreibt bzw. generiert, arbeitet effizienter.

Ich will ja auch wissen "wieviel".

*Angenommen: Die Nutzung von BTRFS "würde" die Lebensdauer eines Datenträgers signifikant vermindern.

Dann würde ich mir den Einsatz schwer überlegen.

Und jetzt sagt bitte nicht einfach wieder: Dann nimm Ext4, weil du es sowieso nicht verstehst und das nicht Praxis bezogen wäre. Hast du Zahlen? Bitte zeige sie mir. Ich bettel schon förmlich.

Das geht schon so weit dass ich mir irgendwelche Tests überlege.

Gruß,

R
 
Oben