Dateisystem für große Dateien auf NAS, read only, welches ist am besten?

[Fallaxia]

Hi Leute,

ich habe folgendes Anliegen:

Ich möchte auf meinem NAS, welches mittels iSCSI angebunden ist, große Dateien ablegen, Images etc. die nur lesend verfügbar sein sollen.

Beispiel Komplettimage einer Festplatte welches in eine Datei gepackt wurde und auf dem NAS liegt.
Der Nutzer möchte jetzt diese Festplatte mounten und tut dies lokal

mount -o ro /nas/nutzer_xyz/festplatte.img /home/meine_festplatte

Mein Ziel ist möglichst wenig IO Last zu produzieren, also den Netzwerktraffic gering zu halten.
Bei einem NTFS Dateisystem ist sehr viel mehr IO zu beobachten um auf die gleichen Dateien zuzugreifen als z.B. bei exFat oder UDF

Daher meine Frage an euch:

Welches Dateisystem würdet ihr für die Daten, welche als Image abgelegt sind nehmen?
Also nicht das Dateisystem des NAS selbst, sondern das der Images.

exFat hat eine menge Nachteile was die Berechtigungen angeht und ist somit nur bedingt nutzbar
UDF schein gut zu funktionieren für vieles
NTFS produziert zuviel Overhead, zuviele IOs auf dem NAS und damit weniger Durchsatz

Es sollte also ein einfaches Dateisystem sein, welches mit großen Dateien umgehen kann, im ReadOnly modus klar kommt und wenig IO Overhead hat.

 

[DFFVB]

ZFS?

 

[andy_m4]

ZFS!
Und die "Freigabe" im Netz als NFS (4) oder gar nur FTP.

Kommt aber halt auch ein bisschen darauf an, was Dein NAS kann. Je nachdem bist Du ja schon durch die vorhandene Software eingeschränkt.
Wenn Du mehr Infos lieferst, kann Dir auch zielführender geholfen werden.

 

[Fallaxia]

Danke erstmal für die Antworten, aber ich glaube mein Anliegen ist missverständlich formuliert:

Ich suche NICHT das ideale Dateinsystem für das NAS selbst, sondern für die Image Dateien die darauf abgelegt werden.

Für die meisten alltäglichen Dinge ist ZFS nicht ideal bzw. nicht jedes System kann dies einfach so mounten oder nutzen.

Es sollen also diverse Geräte lesend auf jeweils ihre Images zugreifen können, das Dateisystem der Images selbst ist also hier die Frage.

Das NAS ist ein OpenStorage System, welches auf 40 SAS Festplatten a 16TB im Raid6 Verbund basiert, es kommt als Host System UbuntuServer 20.04 zum Einsatz und stellt jedes Image als iSCSI Volume bereit, so dass man sie einfach unter Windows und Linux gleichermaßen als lokales Laufwerk einbinden kann.

Ich habe das NAS aber nicht bei mir daheim stehen, sondern als Colocation im Rechenzentrum geparkt, und somit ist iSCSI über VPN eine bislang sehr schöne und stabile Sache. Nur möchte ich die Zeit minimieren, die es dauert wenn man eine Datei öffnet, bis sich "was tut".

Wenn ich ein einfaches Bild, 5 MB, öffne, und das von einem UDF Dateisystem, dann passiert das praktisch sofort.
Nehme ich NTFS, dann braucht es schonmal 10 Sekunden um nur das Verzeichnis mit den Bildern zu laden, und dann nochmals entliche Sekunden bis man das Bild laden kann.


Daher suche ich hier ein Dateisystem mit wenig Overhead für die Images selbst, nicht aber für das NAS Dateisystem.

Bislang habe ich einfach ausprobiert, halt ExFAT, UDF, NTFS, F2FS, Ext4 usw.
Aber bei einer großen Datenmenge ist es später blöd, wenn ich merke, dass eine andere Wahl als die getroffene viel sinnvoller gewesen wäre. Und daher frage ich euch was ihr als readonly Dateisystem nehmen würdet, so simpel und einfach wie möglich und für readonly Betrieb gut geeignet.

 

[Fortatus]

Hm... Btrfs mit abgeschaltetem CoW (weniger Metadaten und bei Read-Only egal) und auf Anschlag hoch gedrehter Kompression? Müsstest du halt auch mal ausprobieren.

 

[Phrasendreher]

ist ZFS nicht ideal bzw. nicht jedes System kann dies einfach so mounten oder nutzen.

Das ist bestimmt richtig und ich bin skeptisch, ob ZFS das Kriterium "einfaches Dateisystem" erfüllt; aber von den Anforderungen der Client-Systeme hattest Du in Deinem ersten Post auch noch gar nichts geschrieben.

Deswegen halte ich es wie @andy_m4, es kommt drauf an was Dein NAS kann und was die Clients können.

Wird das Ganze in einem aufwändigen RAID laufen?
Falls Du auf Journaling verzichten kannst (zumal das v.a. bei Schreiben relevant wird), nimm halt das uralte Ext2, kann Dateien bis zu 32 TiB. Das FS sollte ausreichend einfach sein.

 

[Garmor]

Früher galt XFS als Besser im Umgang mit großen Dateien als die Ext-Familie.

Edit: Oder Benchmarks auf Phoronix suchen: https://www.phoronix.com/scan.php?page=article&item=linux-58-filesystems&num=1

 

[andy_m4]

Für die meisten alltäglichen Dinge ist ZFS nicht ideal bzw. nicht jedes System kann dies einfach so mounten oder nutzen.

Wieso (lokal) mounten? Ich dachte, das soll über Netzwerk bereitgestellt werden.

Das ist bestimmt richtig und ich bin skeptisch, ob ZFS das Kriterium "einfaches Dateisystem" erfüllt

Wenn es einfach und gleichzeitig schnell sein soll, könnte man auch (da bin ich mit Dir einer Meinung) ext2 in Betracht ziehen. Das lässt sich auch von allen möglichen Systemen her mounten. Das nehme ich auch gern für solche Zwecke.
Der Nachteil bei ext2 ist, es hat kein Journaling. fsck dauert dann ggf. bei großen Datenträgern eine Weile.

Früher galt XFS als Besser im Umgang mit großen Dateien als die Ext-Familie.

Notfalls lässt sich ja ext2 auch tunen. Wobei man auch sagen muss, das in der Konstellation das Dateisystem fast egal ist. Es geht ja hier nicht um einen Hochlast-Server.

 

[Fallaxia]

Das ist bestimmt richtig und ich bin skeptisch, ob ZFS das Kriterium "einfaches Dateisystem" erfüllt; aber von den Anforderungen der Client-Systeme hattest Du in Deinem ersten Post auch noch gar nichts geschrieben.

Deswegen halte ich es wie @andy_m4, es kommt drauf an was Dein NAS kann und was die Clients können.

Wird das Ganze in einem aufwändigen RAID laufen?
Falls Du auf Journaling verzichten kannst (zumal das v.a. bei Schreiben relevant wird), nimm halt das uralte Ext2, kann Dateien bis zu 32 TiB. Das FS sollte ausreichend einfach sein.

Steht in der Mitte in meinem vorherigen Post drin, die Struktur und der Aufbau des NAS Systems.
Die Client Systeme sind mir da relativ egal, da flexibel. Die meisten Clients sind Linux basiert und können daher fast alles mounten, es muss ja auch nicht immer das gleich Dateisystem sein, was verwendet wird, können ja auch zwei verschiedene sein, je nach System Linux/Windows die sich gut eignen.

Ich werde ext2 und XFS jetzt mal testen.

Ergänzung (10. Juni 2021)

Wieso (lokal) mounten? Ich dachte, das soll über Netzwerk bereitgestellt werden.

Das NAS stellt den Speicher. Darauf liegen Images (Festplatten/Disks)
Diese werden per iSCSI zur Verfügung gestellt.
Die Clients verbinden sich mit dem gewünschten iSCSI Volume und binden dieses "lokal" ein.
Das System des Clients behandelt die iSCSI Volumes wie lokale Laufwerke, es macht keinen Unterschied zu einer Festplatte die lokal verbaut ist. Es bootet davon, wenn es will, es nutzt das Ding halt wie eine lokale Festplatte auch.

Dabei hilft es aufgrund der unvermeidlichen Latenz zwischen Client und NAS von etwa 20ms, wenn die Abfolge der IOs für eine gegebene Datei möglichst kurz ist, denn sonst wartet man je nach Dateisystem sehr unterschiedlich lange für exakt den gleichen Vorgang, einfach aufgrund der Tatsache, dass einige Dateisysteme mehr Interaktionen für eine Aufgabe benötigen als andere. Und ich suche einfach ein Dateisystem was möglichst wenige serielle Transaktionen (IOs) ausführen muss um die gewünschten Daten bereit zu stellen.

Wenn es einfach und gleichzeitig schnell sein soll, könnte man auch (da bin ich mit Dir einer Meinung) ext2 in Betracht ziehen. Das lässt sich auch von allen möglichen Systemen her mounten. Das nehme ich auch gern für solche Zwecke.
Der Nachteil bei ext2 ist, es hat kein Journaling. fsck dauert dann ggf. bei großen Datenträgern eine Weile.


Notfalls lässt sich ja ext2 auch tunen. Wobei man auch sagen muss, das in der Konstellation das Dateisystem fast egal ist. Es geht ja hier nicht um einen Hochlast-Server.

Ext2 probiere ich jetzt mal.
Bei Ext4 lässt sich das journaling abschalten?

 

[Phrasendreher]

Bei Ext4 lässt sich das journaling abschalten?

Ja,
$ man ext4
sagt:
has_journal
Create a journal to ensure filesystem consistency even across
unclean shutdowns. Setting the filesystem feature is equivalent
to using the -j option with mke2fs or tune2fs. This feature is
supported by ext3 and ext4, and ignored by the ext2 file system
driver.

 

[andy_m4]

Und ich suche einfach ein Dateisystem was möglichst wenige serielle Transaktionen (IOs) ausführen muss um die gewünschten Daten bereit zu stellen.

Wie gesagt. ext2
Aber wenn ext4 für Dich gut funktioniert spricht auch nix dagegen das zu nehmen.

Bei Ext4 lässt sich das journaling abschalten?

Wie mein Vorredner schon sagte, kannst Du das Journaling als Dateisystem-Eigenschaft definieren. Also schon bei der Erstellung:
mkfs.ext4 -O ^has_journal /dev/yourpart

 

[jb_alvarado]

Hm... Btrfs mit abgeschaltetem CoW (weniger Metadaten und bei Read-Only egal) und auf Anschlag hoch gedrehter Kompression? Müsstest du halt auch mal ausprobieren.

Das geht so nicht. Btrfs kann nur komprimieren wenn CoW an ist.

Vielleicht ist das noch interessant: https://www.nerd-supreme.de/2009/12...-jfs-reiserfs-btrfs-und-ntfs-3g-im-vergleich/

 

[Uridium]

IOPS könnten sich u.U. mit Squashfs reduzieren lassen, zu Lasten der CPU. Wobei sich die Kompression konfigurieren lässt (inkl. aussetzen ganzer FS Teile, z.B. data blocks oder Metadaten). Könnte man mal testen.