Krautkanal.com

Veröffentlicht am 2014-12-23 22:19:00 in /b/

/b/ 8494939: Dateisysteme

vigobronx Avatar
vigobronx:#8494939

Linux-Bernd, ist ext4 noch das nix+ultra?

Ich habe hier eine groooße Platte und werde sie verwenden.
ButterFS klingt ja auch verführerisch...
Nur zu tief sollte es nicht sein, es kombt auf einen Luks drauf, Falls das für irgendetwas relevant ist.

Auch: Gibt es zu xts schon ausführliche Erfahrungen? Klingt ja prima aber cbc-essiv deucht mir kampferprobt.

vigobronx Avatar
vigobronx:#8494989

>>8494944
Zu spät und schlecht. Schäme dich, Bernd!

>>8494939
Mit ext4 kannst du nicht viel falsch machen. Es gibt keinen Grund, es nicht zu tun :3
BetterFS soll ja ein kühleres ZFS sein, aber Bernd hat bis jetzt noch keine Erfahrungen damit gemacht.

Was spräche denn gegen ext4?

mat_walker Avatar
mat_walker:#8494999

>>8494989
> Es gibt keinen Grund, es nicht zu tun :3
dies. Ist nunmal so.

Andere FS sind nicht wirklich besser, sie sind anders. Einzig etwas wie btrfs wäre interessant aber das bringt auch keinen wirklichen Mehrwert.

lightory Avatar
lightory:#8495002

>>8494989
> Was spräche denn gegen ext4?
Nichts, ist auch schon drauf aber... fragen schadet ja nicht.

leelkennedy Avatar
leelkennedy:#8495012

>>8495002
Für einen Endnutzer ist auch btrfs nicht so interessant. Snapshots sind kühl aber eher für Servierer interessant.

aiiaiiaii Avatar
aiiaiiaii:#8495019

>Linux-Bernd, ist ext4 noch das nix+ultra?
Linux-Bernd hat alle Festplatten auf NTFS umgestellt. Nur auf der Systempartition ist ein ext4. NTFS wird unter Linux inzwischen sehr gut und stabil unterstützt und es können einfach ALLE.jpg Geräte lesen.

ankitind Avatar
ankitind:#8495022

>>8495019
Gott bist du behindert im Kopf :3

georgedyjr Avatar
georgedyjr:#8495043

>>8495019
Kann das überhaupt inzu Besitzer und Hartelfen?

mr_arcadio Avatar
mr_arcadio:#8495092

>>8495043
Selbst als Pinguin-Lüfter muss ich sagen, dass NTFS gar nicht so krebsig ist:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365006%28v=vs.85%29.aspx

Nichtsdestotrotz ist es nicht frei wie in Freiheit (tm).

hota_v Avatar
hota_v:#8495116

>>8495092
Oh, nagut. Aber die Performanz des auf Zündschnur basierenden Treibers stinkt doch zum Himmel und proprietäre Nieschenprodukte.. nääh..

alessandroribe Avatar
alessandroribe:#8495149

>>8495116
Die NTFS-Rechteverwaltung unter Fenster ist sogar sehr gut - vergleichbar mit ZKL von ext3/4. Bernd musste während seiner Ausbildung zum Bitschubser auch mit dem Fenster-Servierer arbeiten. Wieweit diese Rechte auf Linux zu nutzen sind, kann ich nicht sagen.
Wer jedoch wirklich ein rückentwickeltes Dateisystem nutzt, wenn ext4 ebenfalls zur Verfügung steht, scheint schon sehr krebsig zu sein :3
Immerhin gibt es ext3/4-Treiber auch für Fenster.

antonyryndya Avatar
antonyryndya:#8495188

XFS ist okeh
ext4 ist okeh
Rest ist Hüfsterkrebs

ReiserFS4 Herrenrasse reportiert aus

grrr_nl Avatar
grrr_nl:#8495205

Was ist denn mit ZFS? Aufgrund der ganzen Schichtenverletzungen kann man ja interessante Dinge tuen, aber läuft das auch auf Linux?

stuartlcrawford Avatar
stuartlcrawford:#8495207

>>8495019
Bring dich um.

p_kosov Avatar
p_kosov:#8495214

>>8495043
>Kann das überhaupt inzu Besitzer und Hartelfen?
Natürlich, Besitzer, ACLs, Hardlinks, Junctions, Symlinks, alles da. Und es gibt eine gigantische Zahl an Rettungswerkzeugen falls das Dateisystem mal beschädigt wird und das Backup nicht aktuell ist. Außerdem gibt es funktionierende Defragmentierungswerkzeuge. :3 Das für Ext4 wurde ja nie fertig.
>Immerhin gibt es ext3/4-Treiber auch für Fenster.
Die sind aber übelster Krebs. Gleich gar keine Treiber gibt es Tabletten, die Media-Box, das TV, für das Apfel-Notebook von der Schwester oder irgendwas anderes, was mal eine Festplatte von Bernd lesen können muß.
Das Hauptproblem ist, daß der Ext4-Treiber unter der GPL steht. Deswegen kann ihn niemand nach Fenster, Apfel oder sonstwohin portieren, ohne Lizenzen zu verletzen. Alle Fenstertreiber für Linuxdateisysteme sind von Grund auf neu programmiert, mit vielen schönen Bugs darinnen.

Tja, im Ergebnis gibt es nun zwei proprietäre und patentierte Dateisysteme, die so gut wie überall laufen, nämlich NTFS und FAT. Und es gibt einen Haufen Dateisysteme wie Ext und Butter, die ausschließlich unter Linux gehen, also quasi OS-proprietär sind (Schon unter BSD sitzt man auf dem Trockenen.) Dumm gelaufen, aber Slackware-Bernd paßt sich halt der Heimnutzer-Realität an.

kuldarkalvik Avatar
kuldarkalvik:#8495216

>>8495205
>ZFS

Ist mir nicht klassisch genug.

justinrhee Avatar
justinrhee:#8495218

>>8495205
ZFS ohne ECC-Speicher ist Datenselbstmord.

jffgrdnr Avatar
jffgrdnr:#8495224

>>8495214
Weshalb sollte die GPL eine Portierung verhindern?

arashmanteghi Avatar
arashmanteghi:#8495230

>>8495214
>Das Hauptproblem ist, daß der Ext4-Treiber unter der GPL steht. Deswegen kann ihn niemand nach Fenster, Apfel oder sonstwohin portieren, ohne Lizenzen zu verletzen.

Bist du tatsächlich so retardiert?

vocino Avatar
vocino:#8495245

>>8495214
Immerhin versucht.

emileboudeling Avatar
emileboudeling:#8495255

>>8495224
Bernds letzte Info war, daß die Lizenzen von GPL und IFS SDK inkompatibel sind. Aus den gleichen Gründen gibt's kein ASIO im offiziellen Audacity und kein ZFS im Linux-Kernel.

kennyadr Avatar
kennyadr:#8495284

Bentze btrfs fuer alle meine Platten ausser den Backupplatten (die ham ext4). Zwei Mal in zwei Jahren war das FS komplett kaputt (einmal vor zwei Jahren und einmal neulich bim 3.15er kernel). Wenn man Backups hat ist btrfs natuerlich ne runde und feine Sache (Snapshots, compression). Ohne Backups wuerde ich es noch nicht empfehlen.

Ansonsten habe ich schlechte Erfahrungen mit xfs gemacht (kompilieren und viele kleine Dateien loeschen/verschieben ist schnarchlangsam auf xfs) und jfs war vom dateisystem noch schlimmer als btrfs was stabilitaet angeht: Da waren einfach Mal Dateien ploetzlich verschwunden oder mit Nullen aufgefuellt ohne dass jemals irgendeine Fehlermeldung in den logs auftauchte.

wiljanslofstra Avatar
wiljanslofstra:#8495285

>>8495255
Das ist etwas völlig anderes.

agromov Avatar
agromov:#8495297

>Linux-Bernd, ist ext4 noch das nix+ultra?
Wenn du Fragen musst, dann nimm einfach Ext4.

joemdesign Avatar
joemdesign:#8495307

>>8495284
Butter, ZFS und Co ohne ECC-RAM zu verwenden ist Selbstmord, Bernd.

tmstrada Avatar
tmstrada:#8495324

>>8495307

Qualle? Fuer dedup brauchst du das bei ZFS aber doch nicht bei btrfs.



Ian Hinder posted on Sat, 18 Jan 2014 01:23:41 +0100 as excerpted:

> I have been reading a lot of articles online about the dangers of using
> ZFS with non-ECC RAM. Specifically, the fact that when good data is
> read from disk and compared with its checksuP, e stM error can cause the
> read data to be incorrect, causing a checksum failure, and the bad data
> might now be written back to the disk in an attempt to correct it,
> corrupting it in the process. This would be exacerbated by a scrub,
> which could run through all your data and potentially corrupt it. There
> is a strong current of opinion that using ZFS without ECC RAM is
> "suicide for your data".
>
> I have been unable to find any discussion of the extent to which this is
> true for btrfs. Does btrfs handle checksum errors in the same way as
> ZFS, or does it perform additional checks before writing "corrected"
> data back to disk? For example, if it detects a checksum error, it
> could read the data again to a different memory location to determine
> if the error existed in the disk copy or the memory.

Given the license issues around zfs and linux, zfs is a non-starter for
me here, and as a result I've never looked particularly closely at how it
works, so I can't really say what it does with checksums or how that
compares to btrfs.

I /can/ however say that btrfs does /not/ work the way described above,
however.

When reading data from disk, btrfs will check the checksum. If it shows
up as bad and btrfs has another copy of the data available (as it will in
dup, raid1 or raid10 mode, but not in single or raid0 mode, I'm not
actually sure how the newer and still not fully complete raid5 and raid6
modes work in that regard), btrfs will read the other copy and see if
that matches the checksum. If it does, the good copy is used and the bad
copy is rewritten. If no good copy exists, btrfs fails the read.

So while I don't know how zfs works and whether your scenario of
rewriting bad data due to checksum failure could happen there or not, it
can't happen with btrfs, because btrfs will only rewrite the data if it
has another copy that matches the checksum. Otherwise it (normally)
fails the read entirely.

It is possible to turn off btrfs checksumming entirely with a mount
option, or to turn off both COW and checksumming on an individual file
using xattributes, but that's definitely not recommended in general (tho
it is on specific types of files, generally large internal-write files
that otherwise end up hugely fragmented due to COW).

As George Mitchell mentions in his followup, there's another thread
discussing ECC memory and btrfs already. However, the OP in that thread
didn't explain the alleged problem with zfs (which again, I've no idea
whether it's true or not, since due to the licensing issues zfs is a flat
non-starter for me so I've never looked into it that closely) in that
regard, so all we were able to say was that ECC and btrfs aren't related
in that way. At least here you explained a bit about the alleged
problem, so we can say for sure that btrfs doesn't work that way.