Forum: PC Hard- und Software Linux Mint: Partitionierung mit SSD + HD


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Taucher (Gast)


Lesenswert?

Ich möchte meinen neuen Rechner über die SSD booten und die 
Verzeichnisse /home, /var und /tmp auf die HD in eine einzige Partition 
legen. Alle übrigen Verzeichnisse sollen (möglichst vom Mint-Installer) 
auf der SSD angelegt werden.

Für /home und /var geht das mit bind mounts, wie es unter der 2. Antwort 
auf 
https://unix.stackexchange.com/questions/131311/moving-var-home-to-separate-partition 
beschrieben ist.

/tmp soll nicht auf die SSD und auch nicht in eine eigene Partition auf 
der HD. Wie kann ich /tmp auch in die (einzige) Partition auf der HD 
verlegen?

von (prx) A. K. (prx)


Lesenswert?

Motiv dafür, gerade die für eine SSD interessanten Verzeichnisse auf das 
langsame HDD zu legen?

: Bearbeitet durch User
von Taucher (Gast)


Lesenswert?

Ich nutze /tmp mit großen Dateien, die nur einmal kurz benutzt werden – 
das erspart das Aufräumen. Daraus folgt Verschleiß, den man vermeiden 
kann.

von (prx) A. K. (prx)


Lesenswert?

Taucher schrieb:
> Daraus folgt Verschleiß, den man vermeiden kann.

Ich verstehe die Sorge vor Verschleiss. Aber sie ist in den weitaus 
meisten Fällen substanzlos und kein Grund, auf HDD zu gehen.

Ich verwende SSDs seit über 10 Jahren, im Büro und privat. Diese ersten 
beiden, lange Zeit täglich genutzte Crucial m4, sind nach wie vor im 
Einsatz und immer noch wenig abgenutzt. Eine 970 EVO Plus im seit über 
1,5 Jahren gut genutzten Laptop zeigt immer noch 0% Abnutzung. Weitere 
ähnlich.

: Bearbeitet durch User
von Taucher (Gast)


Lesenswert?

Und wie kann man bewerkstelligen, was ich im Eingangsposting geschrieben 
habe?

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Eine SSD nicht verwenden zu wollen wo sie besonders gut geeignet wäre 
wegen Verschleiß. Erinnert mich an meinen Vater der seine neue Brille 
nicht trägt weil er sich erst dran gewöhnen muss.

von Taucher (Gast)


Lesenswert?

Das ist keine Antwort auf meine Frage.

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Im Prinzip musst du einfach die fstab anpassen und update-initramfs 
ausführen. Und die Ordner an den neuen Ort schieben natürlich. Man kann 
die fstab auch direkt bei der Installation editieren.

von Taucher (Gast)


Lesenswert?

Das ist mir "im Prinzip" klar. Nur: wie muss ich das für tmp machen? Die 
/etc/mtab ist ein ziemlicher Brocken mit vielen tempfs, aber den 
Moutpunkt für /tmp finde ich nicht.

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Das ganze hat mit mtab nichts zu tun.

1. Erzeuge ein Verzeichnis tmp in der Partition wo du es haben willst.

2. Füge einen entsprechenden mount zu fstab hinzu bzw ändere den 
existierenden.

3. update-initramfs -u -k all

4. /tmp leeren

5. reboot


mtab enthält einfach nur die aktuellen Mounts. Wenn da kein /tmp drin 
ist heißt das einfach dass tmp aktuell nur ein Verzeichnis unter  ist 
und kein eigener Mountpoint.

: Bearbeitet durch User
von Walter K. (walter_k488)


Lesenswert?

(prx) A. K. schrieb:
> Motiv dafür, gerade die für eine SSD interessanten Verzeichnisse auf das
> langsame HDD zu legen?

Früher überlegte man, ob und wie man RAM abzweigt, um /tmp dorthin zu 
verfrachten - heute legt man /tmp auf die magnetische Platte?   Nun ja …

von Depender (Gast)


Angehängte Dateien:

Lesenswert?

Walter K. schrieb:

> Früher überlegte man, ob und wie man RAM abzweigt, um /tmp dorthin zu
> verfrachten - heute legt man /tmp auf die magnetische Platte?   Nun ja …

It depends.

von Dipl.-Ing. (Uni) (Gast)


Lesenswert?

/tmp wird vom Installer vermutlich sowieso ins RAM gelegt.

Man sollte sich beim Editieren der fstab nicht vertun.
Ein nicht richtig startendes System ist die übliche Folge.

von (prx) A. K. (prx)


Lesenswert?

Taucher schrieb:
> Und wie kann man bewerkstelligen, was ich im Eingangsposting geschrieben
> habe?

Du hast selbst schon festgestellt, dass du mit bind mounts jede 
beliebige Directory an eine andere Stelle mounten kannst. Ich wüsste 
nicht, weshalb das bei /tmp anders sein sollte.

Ob allerdings ausgerechnet der Installer für ein sich explizit an 
normale Anwender richtende Desktopsystem wie Mint eine derartig 
exotische Konstruktion fertig anbietet?

Kann schon sein, dass du dann eben nachträglich selbst für den Eintrag 
in /etc/fstab sorgen musst. Das sollte freilich gerade bei /tmp sehr 
einfach sein, weil im Gegensatz zu /var der vorherige Inhalt irrelevant 
ist.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Dipl.-Ing. (Uni) schrieb:
> Man sollte sich beim Editieren der fstab nicht vertun.
> Ein nicht richtig startendes System ist die übliche Folge.

Bei solchen Experimenten kann es nützlich sein, wenn man es vorher in 
einer VM mit snapshot/rollback übt. Oder sich vorsorglich mit einem 
recovery boot per grub oder DVD/USB anfreundet.

von Dipl.-Ing. (Uni) (Gast)


Lesenswert?

> Bei solchen Experimenten kann es nützlich sein...

Manche Fehler muss der Anfänger mindestens einmal machen.
Sonst fehlt der Lerneffekt.
Auch das händische Editieren der passwd/shadow kann übel enden.

von Peter (Gast)


Lesenswert?

Wieso willst du überhaupt dieses Setup?

Wenn deine Anwendung nur einmalig Dateien schreibt ist /tmp sowieso eine 
schlechte Wahl, auf vielen Systemen liegt das nämlich im RAM. Ggf. wäre 
/opt /var die bessere Wahl.

Und wozu Home auf einer magnetischen Platte?

Damit diese bei jedem Aufruf einer z.B. SSH Verbindung für .ssh/config 
anlaufen muss?

Wenn du irgendwelche selten genutzen großen Dateien hast kannst du diese 
mittels bind mount oder Symlink genauso in deinen Home Ordner leger aber 
gerade für die vielen kleinen Dateien die enormen Vorteile einer SSD 
nutzen. Mit deinem Setup kannst du auch einfach nur eine HDD benutzen, 
der Unterschied wird kaum zu spüren sein.


PS: Ich halte von dieser Aufteilung nach Partitionen (boot/root/EFI 
ausgenommen) rein gar nichts, das ist ein Relikt alter Tage, heutzutage 
hat man andere Methoden und auf einem Desktop ist das zu 99% Blödsinn.

Genauso die fixe Einbindung einer HDD gerade für /var, das ist einfach 
unsinnig. Auch hier würde ich wenn dann einzelne Verzeichnise/Dateien 
umbiegen, aber nicht den ganzen Mount.

von (prx) A. K. (prx)


Lesenswert?

Peter schrieb:
> auf einem Desktop ist das zu 99% Blödsinn.

Yep, sowas ergibt eher bei Servern einen Sinn, damit voll laufende 
Anwendungs- oder Log-Filesysteme dem System nicht die Laune verderben.

Wobei er das ja ähnlich sieht und /tmp, /var und /home deshalb auf der 
gleichen Partition haben will. Nur eben seltsamerweise auf der dafür 
verkehrten Disk.

Ein Kompromiss wäre über LVM machbar. Das sind dann zwar immer noch 
getrennte Partitionen, aber bei Bedarf live vergrösserbar, und das 
geht dann wohl auch im Installer.

: Bearbeitet durch User
von Peter (Gast)


Lesenswert?

LVM wäre mir zu starr, mag ich persönlich auch nicht sonderlich.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_file_systems/assembly_limiting-storage-space-usage-on-ext4-with-quotas_managing-file-systems

https://docs.oracle.com/cd/E19253-01/820-2313/gazud/index.html


Es gibt mittlerweile so viele Möglichkeiten. Bind mounts und starre 
Partitionen sind da so grob die älteste und unflexibelste Struktur die 
man wählen könnte, in den meisten Fällen eh sinnlos. Ich wünsche 
spätestens mit richtigen Containern Spaß mit bind mounts, da darf man 
dann schön Tabellen mit UID Mapping usw pflegen.

Und wenn deine Anwendungen so ein Müll sind, dass diese 200GB logs 
produzieren und dadurch das System lahmlegen, würde ich eher diese fixen 
anstatt starre Partitionslayouts aus dem Jahre 2000 auszugraben. ext4 
reserviert zum Beispiel für root Speicher per Default, wenn deine 
Anwendung nicht als root läuft reicht das in den meisten Fällen schon.

Da kommt dann richtiges Confinement ins Spiel und nicht Methoden aus 
irgendeiner Linux Zeitschrift bei der die Autoren gerade so ein Live 
Image booten können. cgroups, Filesystem Quota, seccomp usw.

Snaps wären z.B. eine Lösung für das Confinement deiner Anwendung.

von Taucher (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Wobei er das ja ähnlich sieht und /tmp, /var und /home deshalb auf der
> gleichen Partition haben will. Nur eben seltsamerweise auf der dafür
> verkehrten Disk.

Na ja, ich setze ja /home nicht bei Null auf, sondern auf einem 
Datenbestand von knapp 3 TiB. Die SSD hat nur ein halbe TiB…

Aber vielleicht habt ihr ja einen heißen Tipp, wie man die Daten auf die 
SSD bekommt.

von Taucher (Gast)


Lesenswert?


von Dieter D. (dieter_dosenkohl)


Lesenswert?

Taucher schrieb:
> Na ja, ich setze ja /home nicht bei Null auf, sondern auf einem
> Datenbestand von knapp 3 TiB. Die SSD hat nur ein halbe TiB…
>
> Aber vielleicht habt ihr ja einen heißen Tipp, wie man die Daten auf die
> SSD bekommt.

Die Frage ist dann eher warum du das ganze Zeug bei /home drin haben 
willst.

Irgendwie ist es witzig. Du hast dir eine Zuordnung u Aufteilung in den 
Kopf gesetzt an der du partout kein Infragestellen zulässt. Schön. Aber 
von jmd der sich selbst so viel Wissen und Erfahrung in diesem Thema 
zutraut, dass er seine Einschätzung als indiskutabel ansieht, müsste die 
Einrichtung nebenbei in 10 Minuten gemacht sein.

Das passt doch nicht zusammen. Entweder du bist selbst der Experte der 
weiß was er tut und warum - dann mach halt.

Oder aber du bist ein Anfänger der schon beim Blick in seine mtab völlig 
überfordert ist. Auch ok. Dann tu aber nicht so als wäre dein Plan die 
beste Lösung während alle dir sagen dass es Quatsch ist.

Du kommst hier rüber wie ein Typ der mir 3h Vorträge übers Autofahren 
hält und ‚worauf es entgegen der Meinung anderer wirklich ankommt‘ - und 
dann wissen will wie er jetzt genau den Motor startet.

von Drago S. (mratix)


Lesenswert?

Taucher schrieb:
> Aber vielleicht habt ihr ja einen heißen Tipp, wie man die Daten auf die
> SSD bekommt.
Live Distro booten, Partitionen einhängen, Daten bzw. Verzeichnisse an 
gewünschte Stellen verschieben, Mountpoints 
eintragen/umbiegen/nachtragen*, rebooten und glücklich sein.

*) Wer das nicht packt, startet eine Neuinstallation und schenkt dem 
Partitionierungsfenster etwas mehr Aufmerksamkeit - wählt dort seine 
Partitionen und trägt Mountpoints ein.

Macht bitte nicht aus jeder Kleinigkeit ein rieeesen 
Raumschiff-Entwicklungs-Projekt.

von Taucher (Gast)


Lesenswert?

Drago S. schrieb:
> Macht bitte nicht aus jeder Kleinigkeit ein rieeesen
> Raumschiff-Entwicklungs-Projekt.

Du weißt, dass /tmp kein normales Verzeichnis ist?

von Drago S. (mratix)


Lesenswert?

Taucher schrieb:
> Du weißt, dass /tmp kein normales Verzeichnis ist?
Weisst du es?

Gegenfrage: was verleitet jemanden 3TB im /home vorzuhalten?
Wie wäre es mit aufräumen/archivieren/umverteilen/auf NAS auslagern...

von Taucher (Gast)


Lesenswert?

Drago S. schrieb:
> Gegenfrage

Wie wärs, wen du dir deinen Kopf über dein eigenes Zeug zerbrichst?

von Drago S. (mratix)


Lesenswert?

Taucher schrieb:
> Wie wärs, wen du dir deinen Kopf über dein eigenes Zeug zerbrichst?
Wie wäre es mit Müll herausbringen? Von Platte (/home, /tmp) und aus der 
Küche auch gleich...

Zurück zum Topic: Was soll ein nichtnormales Verzeichnis sein?
Was ist mit der /tmp?
Erzähl mal...

: Bearbeitet durch User
von Dave (Gast)


Lesenswert?

Taucher schrieb:
> Du weißt, dass /tmp kein normales Verzeichnis ist?

Wenn tmp nicht gerade auf einer Ramdisk liegt (was du ja offensichtlich 
nicht willst), ist es ein ganz normales Verzeichnis. Lediglich ein 
sticky bit und ggf ein noexec flag ist gesetzt; das kannst du aber 
selbst nachholen mit chmod bzw. in /etc/fstab.

von Peter (Gast)


Lesenswert?

Taucher schrieb:
> Aber vielleicht habt ihr ja einen heißen Tipp, wie man die Daten auf die
> SSD bekommt.

Wie ich bereits schrieb: eine 0815 Installation mit boot/root auf die 
SSD und dann hängst du die paar großen Ordner per Symlink/bind Mount in 
dein home Verzeichnis ein.

Firefox usw kannst ja an die entsprechenden Stellen verschieben...

von marIO (Gast)


Lesenswert?

Taucher schrieb:
> Ich nutze /tmp mit großen Dateien, die nur einmal kurz benutzt werden –
> das erspart das Aufräumen. Daraus folgt Verschleiß, den man vermeiden
> kann.

Es gibt zig Systeme die erzeugen zig Log-Einträge auf SSDs und von 
Verschleiß habe ich noch nix gehört. Angefangen von Handy bis was auch 
immer. Such mal nach 'SSD Lebensdauer'...

Wenn Du einen Ordner beim Runterfahren des Systems z.B. löschen 
möchtest, dann kannst Du das mit systemd machen. Beispiel nicht 
ausprobiert, aber sieht auf den ersten Blick korrekt aus: 
https://www.golinuxcloud.com/run-script-with-systemd-before-shutdown-linux/

Taucher schrieb:
> Du weißt, dass /tmp kein normales Verzeichnis ist?

Ein Ordner ist ein Ordner. Sowie auch /tmp. Alle Verzeichnisoperationen 
funktionieren wie gewohnt.

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Taucher schrieb:
> Du weißt, dass /tmp kein normales Verzeichnis ist?

Also jetzt bin ich aber gespannt auf die Erklärung. Was bitte ist an 
/tmp kein normales Verzeichnis?

von Cartman (Gast)


Lesenswert?

> Was bitte ist an /tmp kein normales Verzeichnis?

Ich habe es tatsaechlich schon erlebt, dass die "lokale" Administration
nicht wusste, dass /tmp nur im RAM liegt. Und sich dann "wunderte"
dass die Daten nach einem Reboot weg waren.
Das war in einer Zeit lange vor dem Aufkommen von SSDs und
das "betroffene" Betriebssystem war Solaris. Zu dieser Zeit,
lag /tmp bei den Linuxen nahezu 100 %ig noch auf einer Platte.

Zu den recbt "speziellen" Wuenscnen des TO mag man eigentlich
gar nichts sagen.
Normalerweise haelt man keine 3 TB Daten im "eigenen" /home.
Ausnahmen moegen in wirklichen "Mehrnutzerumgebungen" wie
Lehreinrichtungen aber vorkommen.
Da sind TB-grosse Homeverzeichnisse wohl nichts ungewoehnliches.
Weil die Benutzer eben ihr "ganzes" Zeug nur dort unterbringen
koennen.

> /home, /var und /tmp auf die HD in eine einzige Partition legen
Partition erstellen und z.B. unter /mnt mounten. Dann:
Einfach die Verzeichnisse auf der HD unter /mnt anlegen und mit
loop/bind-Mounta nach /home, /var und /tmp mounten.
Der Mount /mnt muss natuerlich erhalten bleiben.
Idh wuerde schonmal Wetten darauf abschliessen, dass das dem TO
natuerlich auch nicht passt :).

von Cartman (Gast)


Lesenswert?

P.S.:
Wenn du vorhaben solltest, ein solches Setup bei einem $KUNDEN
zu duplizieren, koennte es sein, dass die dortige "Aministration"
nur einmal den Kopf schuettelt und mit Verweis auf
z.B. Backup, Security, Bla... das Ansinnen ebenso zuegig
wie umfassend ablehnt.

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Cartman schrieb:
>> Was bitte ist an /tmp kein normales Verzeichnis?
>
> Ich habe es tatsaechlich schon erlebt, dass die "lokale" Administration
> nicht wusste, dass /tmp nur im RAM liegt. Und sich dann "wunderte"
> dass die Daten nach einem Reboot weg waren.
> Das war in einer Zeit lange vor dem Aufkommen von SSDs und
> das "betroffene" Betriebssystem war Solaris. Zu dieser Zeit,
> lag /tmp bei den Linuxen nahezu 100 %ig noch auf einer Platte.

Allerdings liegt /tmp unter Mint standardmäßig nicht im RAM oder?

von rbx (Gast)


Lesenswert?

Cartman schrieb:
> Idh wuerde schonmal Wetten darauf abschliessen, dass das dem TO
> natuerlich auch nicht passt :).

In auf der in der Eingangsfrage verlinkten Internetseite steht u.a.:

"can someone guide me on this"

Trivial ist die Geschichte nicht, und /tmp sowie etwas blödsinnig 
eingerichtet.
Jetzt nicht grundsätzlich - aber:

Ich hatte mal in Windows den Partitionsplatz für das Betriebssystem 
etwas zu knapp eingerichtet. Prinzipiell kein Problem, aber ich musste 
halt auf ein paar liebgewonnene Programme verzichten. Schönes schlankes 
System gewissermaßen.

Jetzt aber die Haskell Plattform: Standardmäßig wird alles über /tmp 
ausgepackt (oder /temp) und da reicht der knapp bemessene Platz für das 
OS nicht mehr.

Man musste also den automatischen Eintrag auf einen Bereich, wo mehr 
Platz ist (z.B. einen USB-Stick) umbiegen. Ist das erledigt, dann kommt 
die Meldung in etwa "Windows zu alt" (Windows ME). Naja, schade.

/tmp muss man sich ja sinnvollerweise als "Neuanfang bei Reboot" denken. 
Also nichts festes.

Aber irgendwie müsste man /tmp auch umleiten können, bzw. swappen, was 
auch nicht so einfach zu sein scheint.

Ich habe unter Linux ein ganz ähnliches Problem mit Steam und Wine. 
Eigentlich brauche ich nur die größere HD um sie für /home zu nutzen, 
d.h. es wäre schön, am unproblematischsten, wenn /home von der SSD 
einfach auf die größere Platte swappen könnte.

Unmöglich ist das alles nicht - Arroganz oder Persönlichkeitsdiagnostik 
aus dem Kaugummiautomaten sind hier fehl am Platz (ich nutze da eher 
mein Know How aus der Persönlichkeitspsychologie und weiß genau, dass 
selbst diese professionellen Programme da recht schwammig oder 
fragwürdig sind - was ja auch ganz OK ist).

von Reinhard S. (rezz)


Lesenswert?

Dieter D. schrieb:
> Allerdings liegt /tmp unter Mint standardmäßig nicht im RAM oder?

Bei mir (Mint 19.2) ist /tmp nicht in der Ausgabe von mount/mtab 
aufgelistet, es sind aber nur Dateien vorhanden, die nach dem letzten 
Neustart erstellt wurden.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Mint / Ubuntu Standardinstallationen: Nur ein Filesystem, kein Mount, 
kein Symlink. Aber systemd räumt auf, siehe /usr/lib/tmpfiles/tmp.conf 
und
   man systemd-tmpfiles
   man tmpfiles.d

: Bearbeitet durch User
von Dieter D. (dieter_dosenkohl)


Lesenswert?

Reinhard S. schrieb:
> Dieter D. schrieb:
>> Allerdings liegt /tmp unter Mint standardmäßig nicht im RAM oder?
>
> Bei mir (Mint 19.2) ist /tmp nicht in der Ausgabe von mount/mtab
> aufgelistet, es sind aber nur Dateien vorhanden, die nach dem letzten
> Neustart erstellt wurden.

Ergo ein stinknormaler Ordner dessen Inhalt beim Herunterfahren gelöscht 
wird..

Und wer den jetzt gern woanders haben will schreibt einfach einen (bind) 
mount in die fstab. Fertig.

: Bearbeitet durch User
von Pepe (Gast)


Angehängte Dateien:

Lesenswert?

Wie kommt man in der zeit wo 1gb SSD 70 eur kosten auf die idee eine HDD 
einzubauen?

von Reinhard S. (rezz)


Lesenswert?

Pepe schrieb:
> Wie kommt man in der zeit wo 1gb SSD 70 eur kosten auf die idee eine HDD
> einzubauen?

70€ für 1 GB ist aber teuer...

Aber vielleicht reicht dem TO ja 1 TB auch nicht und als Datengrab will 
er halt was richtig großes, was als SSD halt auch noch richtig teuer 
ist.

von Cartman (Gast)


Lesenswert?

> > Wie kommt man ... auf die idee
Unter anderem bricht die Schreibleistung einer SSD oberhalb eines
gewissen Schwellwertes recht dramatisch ein.
Kommerziell loest man das einfach durch Striping und eine gewisse
Ueberdimensionierung des Platzes auf der/n SSD.

Des weiteren fallen SSDs auch einem Sparzwang der Hersteller zum
Opfer, die bewaehrte Technologien durch andere ersetzen.
Das was fuer bisherige Generationen galt, kann morgen nichts mehr
wert sein.

> Aber irgendwie müsste man /tmp auch umleiten können, bzw. swappen, was
> auch nicht so einfach zu sein scheint.

Doch ist es. Einfach einen CMD.EXE starten und ein:
set TEMP=C:\TMP ggfs. auch ein set TMP=C:\TMP ausfuehren
und dann im selben(!) CMD beherzt SETUP.EXE starten.
Von wenigen "duemmlichen" Ausnahmen, wie nicht anders zu erwarten
von M$ selbst, sollte dann alles seinen Gang gehen.

von (prx) A. K. (prx)


Lesenswert?

Cartman schrieb:
> Unter anderem bricht die Schreibleistung einer SSD oberhalb eines
> gewissen Schwellwertes recht dramatisch ein.

Böte es sich im Kontext dieses Threads also an, eine HDD als 
Schreib-Cache für eine SSD zu verwenden? ;-)

von Cartman (Gast)


Lesenswert?

Ach so: Bei Altsystemen CMD.EXE durch COMMAND.COM ersetzen.

Bei diesem Altzeug habe ich immer noch eine externe schnelle (15k)
146 GB-SCSI-Platte in stiller Reserve. Das reicht auch
als TMP fuer die Installation groesserer Software z.B.
Altera Quartus Pro wo der Installer schon 67 GB gross ist.

von Cartman (Gast)


Lesenswert?

> Böte es sich im Kontext dieses Threads also an, eine HDD als
> Schreib-Cache für eine SSD zu verwenden? ;-)

Solche Gedankengaenge sind dem TO sicher nicht fremd.

Bei mir: Wenn es eine "unregelmaessige" Uebung ist, also
z.B. ein Imagebackup anfertigen: Platte.
Die hat nebenbei auch als Einzelstueck mehr Platz.
Wenn es "regelmaessig" von normalen Nutzern genutzt wird:
SSD-Stripe.

von Drago S. (mratix)


Lesenswert?

Um das ganze abzukürzen:
1
sudo mkdir -p /tmp # verzeichnis anlegen
2
sudo chmod 1777 /tmp # sticky bit setzen
3
#sudo chmod +rwxt /tmp # oder auch so
4
5
# /etc/fstab: mode=1777 muss hinein; rest nach belieben
6
echo "tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=1g 0 0" | sudo tee -a /etc/fstab
7
sudo mount /tmp
8
df -h /tmp

Hier noch etwas Lesestoff. Die beiden letzten links sind sehr nützlich.
https://wiki.ubuntuusers.de/fstab/
https://wiki.ubuntuusers.de/SSD/Auslagerung/
https://www.pcwelt.de/ratgeber/Wichtige-Dateisysteme-im-Ueberblick-7115007.html
What is Fstab in Linux: 
https://www.linuxhowto.net/what-is-fstab-in-linux-an-introduction-to-linux-etc-fstab-file/
Unterschied zwischen tmpfs und ramfs: 
https://techgoat.net/index.php?id=87
How to create temporary files using mktemp: 
https://linuxconfig.org/how-to-create-temporary-files-using-mktemp-on-linux

Und hört bitte auf 'bind' mit 'mount" zu vertauschen - das sind 2 Paar 
Schuhe.

Schönen Sonntag noch.

von (prx) A. K. (prx)


Lesenswert?

Drago S. schrieb:
> Und hört bitte auf 'bind' mit 'mount" zu vertauschen - das sind 2 Paar
> Schuhe.

Das Kindchen heisst aber nun einmal bind mount.

von Drago S. (mratix)


Lesenswert?

Dieter D. schrieb:
> Und wer den jetzt gern woanders haben will schreibt einfach einen (bind)
> mount in die fstab. Fertig.
Genau das macht man nicht!

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Drago S. schrieb:
> Um das ganze abzukürzen:
> …
>
> Und hört bitte auf 'bind' mit 'mount" zu vertauschen - das sind 2 Paar
> Schuhe.

Ähm, er wollte nicht wissen wie man tmp in den RAM legt. Und wer 
vertauscht bind mit mount? Ich habe es zusammen genannt weil er eben das 
eine oder das andere braucht, je nachdem ob tmp nun eine eigene 
Partition oder nur ein Verzeichnis auf einer anderen Partition sein 
soll.

von Cartman (Gast)


Lesenswert?

> Wenn es "regelmaessig" von normalen Nutzern genutzt wird:
> SSD-Stripe.

Um das mit Zahlen zu unterlegen:
Fuer eine, im weitesten Sinne physikalische Berechnung,
gehen ca. 2 TB Rohdaten ein, ueber die dann gerechnet wird.
In der Summe entstehen dabei 10 - 16 TB Daten auf den SSDs.
Es kann passieren, dass 2 - 3 von diesen Rechnungen/Daten
vorgehalten werden muessen:
Da stecken dann 8 x 8 TB SSDs im Rechner.
Dabei kommt es weder beim "Einlesen" noch bei der "Rechnung"
zu diesen Einbruechen. Ausserdem ergeben sich exquisite
Lese-/Schreibleistungen.

Als weiteres "Zwischenlager" stehen nochmal ca. 100 TB an HD
ueber SAS angeschlossen bereit.

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Drago S. schrieb:
> Genau das macht man nicht!

Das erklären wir ihm ja auch die ganze Zeit aber er will es ja 
unbedingt…

von Drago S. (mratix)


Lesenswert?

(prx) A. K. schrieb:
> Das Kindchen heisst aber nun einmal bind mount.
bind ist nicht für diesen Fall da.

Mit bind hängt man etwas in die Struktur hinein. Nicht on top, als 
Mountpoint.
z.B. das eingehängte Audioarchiv in die /home/$USER/Musik.

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Drago S. schrieb:
> (prx) A. K. schrieb:
>> Das Kindchen heisst aber nun einmal bind mount.
> bind ist nicht für diesen Fall da.
>
> Mit bind hängt man etwas in die Struktur hinein. Nicht on top, als
> Mountpoint.
> z.B. das eingehängte Audioarchiv in die /home/$USER/Musik.

Du bringst hier gerade alles durcheinander. Er will wenn bestimmtes 
Verzeichnis auf einer HDD als tmp nutzen. Dafür braucht er einen bind 
mount

von Cartman (Gast)


Lesenswert?

> Das Kindchen heisst aber nun einmal bind mount.

In den aelteren Dialekten auch noch: loop mount.
Wobei das Linux loop mount noch etwas anderes meint und ist.

von (prx) A. K. (prx)


Lesenswert?

Cartman schrieb:
>> Wenn es "regelmaessig" von normalen Nutzern genutzt wird:
>> SSD-Stripe.
>> Da stecken dann 8 x 8 TB SSDs im Rechner.
>
> Als weiteres "Zwischenlager" stehen nochmal ca. 100 TB an HD
> ueber SAS angeschlossen bereit.

Also ein ganz normaler Nutzer von nebenan. ;-)

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Meine verehrten Damen und Herren, sehen Sie heute Drago S. in:

„Wie gebe ich TO eine Anleitung für etwas was er gar nicht wollte und 
erkläre allen anderen wie falsch sie liegen, während ich die Frage noch 
nicht mal verstanden habe“ 😂

von Drago S. (mratix)


Lesenswert?

Dieter D. schrieb:
> Du bringst hier gerade alles durcheinander. Er will wenn bestimmtes
> Verzeichnis auf einer HDD als tmp nutzen. Dafür braucht er einen bind
> mount
Naja.
Für solche Spezialanforderungen gibt es 'mktemp'.
Und für den TO habe ich extra size=1g eingetragen. Was man natürlich 
nicht macht, er aber braucht.

Dieter D. schrieb:
> Meine verehrten Damen und Herren, sehen Sie heute Drago S. in:
Dieter, lass gut sein.

: Bearbeitet durch User
von Cartman (Gast)


Lesenswert?

> Also ein ganz normaler Nutzer von nebenan. ;-)

Naja, es ist nicht nur ein Rechner. Es sind schon ein paar. :)
Und es werden noch mehr.

Schneller, hoeher und weiter! Auf zum Atem!

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Drago S. schrieb:
> Dieter D. schrieb:
>> Du bringst hier gerade alles durcheinander. Er will wenn bestimmtes
>> Verzeichnis auf einer HDD als tmp nutzen. Dafür braucht er einen bind
>> mount
> Naja.
> Für solche Spezialanforderungen gibt es 'mktemp'.
> Und für den TO habe ich extra size=1g eingetragen. Was man natürlich
> nicht macht, er aber braucht.
>
> Dieter D. schrieb:
>> Meine verehrten Damen und Herren, sehen Sie heute Drago S. in:
> Dieter, lass gut sein.

Er will keine ramdisk. Wie kommst du da drauf? 😂👌

Ich meine nix für ungut. Vielleicht liege ich ja falsch. Dann lasse ich 
es mir gerne erklären. Bin kein Linux Profi. Aber so wie ich deine Posts 
verstehe gehen sie einfach komplett am Thema vorbei.

: Bearbeitet durch User
von Drago S. (mratix)


Lesenswert?

Dieter D. schrieb:
> Er will keine ramdisk. Wie kommst du da drauf? 😂👌
Wenn er die ersten 5 links durchgekaut hat, bekommt er das 
Problem/Anforderung gelöst.
Kommt vielleicht aus Einsicht und Überzeugung die Beratungsresistenz 
abzulegen.

So, das wird mir nun zu doof... ich gehe zurück in den Garten und spiele 
mit dem Grill & trinke ein Radler.

Schönen Sonntag, euch allen.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Dieter D. schrieb:
> Aber so wie ich deine Posts
> verstehe gehen sie einfach komplett am Thema vorbei.

Man merkwürdig anmutenden Fragestellungen kann man antworten, indem man 
exakt die Frage beantwortet, egal wieviel Sinn das ergibt. Oder indem 
man erst einmal rauszukriegen versucht, ob die vom Fragesteller 
angepeilte Lösung vielleicht schon auf dem Holzweg liegt.

von (prx) A. K. (prx)


Lesenswert?

Drago S. schrieb:
> Wenn er die ersten 5 links durchgekaut hat, bekommt er das
> Problem/Anforderung gelöst.

Das kollidiert dann aber ein wenig damit:

Taucher schrieb:
> möglichst vom Mint-Installer

von Dieter D. (dieter_dosenkohl)


Lesenswert?

(prx) A. K. schrieb:
> Dieter D. schrieb:
>> Aber so wie ich deine Posts
>> verstehe gehen sie einfach komplett am Thema vorbei.
>
> Man merkwürdig anmutenden Fragestellungen kann man antworten, indem man
> exakt die Frage beantwortet, egal wieviel Sinn das ergibt. Oder indem
> man erst einmal rauszukriegen versucht, ob die vom Fragesteller
> angepeilte Lösung vielleicht schon auf dem Holzweg liegt.

Völlig richtig. Es hat ja aber niemand die Frage exakt beantwortet ohne 
es infrage zu stellen. Es wurde erklärt wie es geht und warum es Quatsch 
ist.

Da fand ich Drago jetzt einfach zu geil der einfach ohne Erklärung eine 
Anleitung hinknallt und so tut als wäre das die Lösung - obwohl sie 
etwas völlig anderes macht - und dann noch die Erläuterungen von vorher 
aus dem Zusammenhang reißt und so tut als hätte das jmd empfohlen.

Man möchte meinen er hat den Thread gelesen ohne ihn gelesen zu haben - 
und dann auf Schlagworte reagiert. Stichwort bind und mount verwechseln 
- hat niemand getan einfach 😄

von Taucher (Gast)


Lesenswert?

Dave schrieb:
> Lediglich ein
> sticky bit und ggf ein noexec flag ist gesetzt; das kannst du aber
> selbst nachholen mit chmod bzw. in /etc/fstab.

Und wer löscht den Inhalt bis zum nächsten Reboot?

von Taucher (Gast)


Lesenswert?

Cartman schrieb:
> dass /tmp nur im RAM liegt.

Das halte ich für ein Gerücht – ich habe schon zu viele GBs nach tmp 
herunter geladen und es hatte danach immer noch Platz…

von Taucher (Gast)


Lesenswert?

rbx schrieb:
> Unmöglich ist das alles nicht - Arroganz oder Persönlichkeitsdiagnostik
> aus dem Kaugummiautomaten sind hier fehl am Platz (ich nutze da eher
> mein Know How aus der Persönlichkeitspsychologie und weiß genau, dass
> selbst diese professionellen Programme da recht schwammig oder
> fragwürdig sind - was ja auch ganz OK ist).

Danke. Schön dass es in diesem verkorksten Land auch noch vernünftige 
Leute gibt…

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Taucher schrieb:
> Dave schrieb:
>> Lediglich ein
>> sticky bit und ggf ein noexec flag ist gesetzt; das kannst du aber
>> selbst nachholen mit chmod bzw. in /etc/fstab.
>
> Und wer löscht den Inhalt bis zum nächsten Reboot?

Das macht systemd. Und du denkst jetzt /tmp wäre deshalb kein normaler 
Ordner mehr oder wie?

von Εrnst B. (ernst)


Lesenswert?

Dave schrieb:
> Lediglich ein
> sticky bit und ggf ein noexec flag ist gesetzt; das kannst du aber
> selbst nachholen mit chmod bzw. in /etc/fstab.

Vorsicht, manche (z.B. electron-) Anwendungen erwarten, dass sie aus 
"/tmp" binaries ausführen können.
Ein echter Sicherheitsgewinn ist es eh nicht, per 
"/lib64/ld-linux-x86-64.so.2 /tmp/irgendwas" kann man das "noexec"-Flag 
umgehen.

Taucher schrieb:
> Na ja, ich setze ja /home nicht bei Null auf, sondern auf einem
> Datenbestand von knapp 3 TiB. Die SSD hat nur ein halbe TiB…
>
> Aber vielleicht habt ihr ja einen heißen Tipp, wie man die Daten auf die
> SSD bekommt.

bcache, lvm-cache.

da sind dann die häufig benötigten Dateien (~/.bashrc, ~/.ssh/*, 
Firefox-Profil usw.) auf der SSD, und die 3 TiB Datenberge bleiben auf 
der HDD.
Vollautomatisch.

von Cartman (Gast)


Lesenswert?

Taucher schrieb:
> Cartman schrieb:
>> dass /tmp nur im RAM liegt.
>
> Das halte ich für ein Gerücht – ich habe schon zu viele GBs nach tmp
> herunter geladen und es hatte danach immer noch Platz…

Ich habe hier aktuell "einige" Systeme mit 512 GB RAM.
Da koennte eine Ramdisk schon etwas groesser ausfallen.
Aber selbst die wuerde fuer die typischerweise anfallenden
Rohdaten nicht reichen. Also schiebt man sie direkt in
gestripte SSDs. Ein /tmp in dem Sinne gibt es nur als
Systemdefault, wird aber fuer die Berechnungen quasi nicht
genutzt. Siehe auch meine anderen Beitraege.

Was du fuer ein Geruecht haeltst, ist mir egal.

Aber /tmp in eine Ramdisk zu legen, war/ist bei Solaris z.B.
seit Jahrzehnten gaengige Praxis. Auch das kannst du gerne
fuer ein Geruecht halten.
Die Linuexe haben sich das irgendwann auch zu eigen gemacht.

Das /tmp nun ins normale Rootfilesystem umgezogen ist, naja
wenn sie es dort schoen finden.

Ich persoenlich verwende Ramdisks ausgesprochen gern,
z.B. fuer FPGA-Projekte wo sehr viele Dateien als
Zwischenergebnis in der Synthese anfallen.
Und eine Ramdisk ist normalerweise auch heute noch der
schnellste filebasierte Speicher in einem System.

von Johannes (Gast)


Lesenswert?

Der TO trollt doch nur. Ich wette der tritt auch unter dem Namen VM 
Freak auf :D

von Taucher (Gast)


Lesenswert?

Cartman schrieb:
> Aber /tmp in eine Ramdisk zu legen, war/ist bei Solaris z.B.
> seit Jahrzehnten gaengige Praxis.

Das mag sein, gilt aber für Mint mit Sicherheit nicht – dort gibt es 
keine harte Begrenzung für /tmp.

Εrnst B. schrieb:
> bcache, lvm-cache.

Das ist ein interessanter Tipp.

Dieter D. schrieb:
> Das macht systemd. Und du denkst jetzt /tmp wäre deshalb kein normaler
> Ordner mehr oder wie?

Offensichtlich ist er das nicht – er erfährt eine Sonderbehandlung, die 
andere Ordner nicht erfahren und damit ist es eben kein "normaler" 
Ordner mehr. Und bei Mint ist es auch kein tempfs – die liegen nämlich 
wirklich im RAM…

von Cartman (Gast)


Lesenswert?

Eine erschoepfende Analyse meiner Ausfuehrungen wuerde ergeben,
dass ich "Mint" ueberhaupt nicht erwaehnt habe.

Ich habe einen $NACHBARN der sammelt und installiert Linuexe
scheinbar im Akkord. Der scheint hier aber nicht mitzulesen.
Ansonsten ist bei seinen Installationen aber auch mehr kaputt
und nicht funktional als ueblich.

Ich im Gegensatz, installiere einen Rechner oft nur genau einmal.
Und vermutlich werde ich "Mint" auch in den naechsten 12 Monaten
nicht installieren. Er ist mir also herzlich egal, wohin der
"Mint"-Installer sein /tmp packt.
Aus der "Poetteringschen" Spezialbehandlung von /tmp eine
Sonderstellung von /tmp zu implizieren, halte ich fuer etwas
weit hergeholt. Er tut ja nur das, was ein "Blackout" sonst
auch taete und was keiner speziell findet.

Sicherlich kann mit mit "speziellen" Loesungen versuchen sein
Problem zu loesen, aber je exotischer etwas ist, um so laenger
halten sich auch Bugs und Peculiarities im Code.
Im allgemeinen ist man mit K.I.S.S. am besten bedient.

von Taucher (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Aber systemd räumt auf, siehe /usr/lib/tmpfiles/tmp.conf

/usr/lib/tmpfiles/ gibts bei Mint 19 nicht – bei 21 hab ich nicht 
nachgesehen.

von Markus W. (dl8mby)


Lesenswert?

Also ich für meinen Teil bin noch auch aus der SUN-Zeit geformt
und lege für alles mögliche eine separate Partition an, auch wenn
es mit btrfs heute nicht mehr zwingend nötig ist.

Ich hoffe meine fstab ist kein abschreckendes Beispiel aber sie
ist schon etwas länger.
1
>cat /etc/fstab
2
LABEL=ROOT      /           btrfs  defaults        0  0
3
/dev/mmcblk0p1  /mnt/mmcblk0p1 ext4 noatime,ro 0 0
4
/dev/mmcblk0p2   /mnt/mmcblk0p2 ext4 noatime 0 0
5
LABEL=HOME      /home       xfs    defaults        0  0
6
LABEL=BOOT      /boot       btrfs  noatime         0  0
7
LABEL=BOOT_EFI  /boot/efi   vfat   codepage=437    0  0
8
LABEL=BCK       /bck        xfs    noatime,noexec,nosuid,nodev        0  0
9
LABEL=SWAP      swap        swap   pri=0,x-systemd.device-timeout=10           0  0
10
LABEL=VAR       /var        btrfs  noatime         0  0
11
LABEL=USR_LOC   /usr/local  btrfs  noatime         0  0
12
LABEL=TMP       /tmp        btrfs  noatime,noexec,nosuid,nodev        0  0
13
LABEL=SRV       /srv        btrfs  noatime         0  0
14
LABEL=ROOT      /root       btrfs  subvol=/@/root  0  0
15
LABEL=OPT       /opt        btrfs  noatime         0  0

Für temporäre Arbeiten bewege ich mich meist auf /dev/shm, das
in meinem Fall mit 32GB für meine Belange reicht.
1
>df -h
2
Filesystem                                            Size  Used Avail Use% Mounted on
3
devtmpfs                                              4.0M     0  4.0M   0% /dev
4
tmpfs                                                  32G  566M   31G   2% /dev/shm
5
tmpfs                                                  13G  2.1M   13G   1% /run
6
/dev/nvme0n1p2                                        256G   35G  222G  14% /
7
/dev/mmcblk0p1                                        119M   26K  110M   1% /mnt/mmcblk0p1
8
/dev/mmcblk0p2                                         15G   24K   14G   1% /mnt/mmcblk0p2
9
/dev/nvme0n1p1                                        1.0G  246M  658M  28% /boot
10
/dev/nvme0n1p2                                        256G   35G  222G  14% /root
11
/dev/nvme0n1p3                                        128G   14G  114G  11% /opt
12
/dev/nvme1n1p2                                        666G  457G  209G  69% /srv
13
/dev/nvme1n1p1                                        256G  6.0G  250G   3% /usr/local
14
/dev/sda3                                             256G  437M  254G   1% /tmp
15
/dev/sda1                                             500M  5.1M  495M   2% /boot/efi
16
/dev/sda2                                             128G   14G  113G  11% /var
17
/dev/mapper/cr_ata-ST2000LM015-2E8174_WDZPQV5A-part5  1.5T  1.2T  354G  77% /home
18
/dev/mapper/cr_ata-ST2000LM015-2E8174_ZDZ9X1LX-part4  1.5T  925G  549G  63% /bck

Es bedeutet zwar immer etwas Mühe beim Installieren der Systeme
die Partitionierung zu machen aber hat sich bis dato nicht negativ
ausgewirkt, wenn man von der benötigten Zeit absieht.

Wenn man die Filesysteme mit Ihren Parametern sichert, kann man sie
auch gut wieder reparieren, wenn was schief geht, sofern die Disk
noch in Ordnung ist.

Soweit mein Senf zu der Thematik. Ob es jetzt für den TO eine Hilfe
ist, muss er selbst beurteilen.

LG
Markus

von Reinhard S. (rezz)


Lesenswert?

Taucher schrieb:
> (prx) A. K. schrieb:
>> Aber systemd räumt auf, siehe /usr/lib/tmpfiles/tmp.conf
>
> /usr/lib/tmpfiles/ gibts bei Mint 19 nicht

Bei mir gibts ein /usr/lib/tmpfiles.d/tmp.conf

von Taucher (Gast)


Lesenswert?

@Markus W.:
Die Aufteilung auf verschiedene Partitionen stammt aus der Zeit der 
kleinen Platten. Als sie größer wurden, teilte man die in mehrere 
Partitionen auf und um das etwas flexibler zu machen, wurden die 
Partitionen mit lvm verwaltet.

Der Idealfall – finde ich jedenfalls – ist eine riesige Speicherwiese, 
die man frei verwenden kann. Das wird aber vermutlich nie erreicht 
werden, weil Speichermedien immer zu klein sind, egal wie groß…

Man muss also irgend einen Kompromiss finden, der möglichst wenig 
Restriktionen im praktischen Anwendungsfall mit sich bringt.

Reinhard S. schrieb:
> Bei mir gibts ein /usr/lib/tmpfiles.d/tmp.conf

Welche Mint-Version ist das?

von Taucher (Gast)


Lesenswert?

Wie /tmp und andere temporären Verzeichnisse administriert werden, ist 
unter

   man tmpfiles.d

beschrieben. Damit kann man tmp-Verzeichnisse nach belieben anlegen, die 
beim Boot leer geputzt sind – danke prx.

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Taucher schrieb:
>
> Offensichtlich ist er das nicht – er erfährt eine Sonderbehandlung, die
> andere Ordner nicht erfahren und damit ist es eben kein "normaler"
> Ordner mehr. Und bei Mint ist es auch kein tempfs – die liegen nämlich
> wirklich im RAM…

Nur weil ein Service regelmäßige Aktionen in dem Ordner durchführt ist 
es trzd ein stinknormaler Ordner. Und erst recht im Kontext deiner 
Frage. Du kannst da mounts oder bind mounts drauf zeigen lassen und ganz 
normale fstab Einträge vornehmen wie bei jedem anderen Ordner auch. In 
jedem Systemordner führt das System automatisch Operationen durch. In 
/home genauso wie in /var, /dev, /tmp usw. Jeder einzelne davon bekommt 
eine Sonderbehandlung. Und jeden einzelnen davon kannst du mounten und 
bind mounten und wie und was du willst. Denn jeder einzelne davon ist am 
Ende des Tages ein stinknormaler Ordner.

Und wie kann man bitte wenn man offensichtlich absolut 0 Ahnung hat 
trotzdem so hart diskutieren? Trollst du oder bist du wirklich so hart 
hängengeblieben? Hast du es denn in deiner so umfangreichen Expertise 
wenigstens inzwischen hingekriegt oder glotzt du immer noch wie ein 
Schwein vorm Uhrwerk in deine mtab und fragst dich was du machen sollst? 
Oder sollen wir dir lieber einen guten Psychiater suchen?

: Bearbeitet durch User
von Taucher (Gast)


Lesenswert?

Du bist ein großer Klugsch....

von Dieter D. (dieter_dosenkohl)


Lesenswert?

So einen Typen wie dich hatten wir im 1. und 2. Semester im Studium 
auch. Der hat sich immer benommen wie der mega Experte. Einmal hat er 
erzählt er würde zuhause gerade einen mega Audio Verstärker entwickeln 
der besser ist alles was man so kaufen kann. In der nächsten Elektronik 
VL wusste er nicht mal was Class A Betrieb ist. Seine Hausaufgabe fürs 
Lab - eine einfache Arbeitspunkt Auslegung - hatte er nicht hinbekommen. 
Naja, er hat dann abgebrochen. Möchte echt zu gerne wissen was in Köpfen 
von solchen Typen wie euch vorgeht. 😂

von Cartman (Gast)


Lesenswert?

> Markus W.:
> Die Aufteilung auf verschiedene Partitionen stammt aus der Zeit der
> kleinen Platten. Als sie größer wurden, teilte man die in mehrere
> Partitionen auf und um das etwas flexibler zu machen, wurden die
> Partitionen mit lvm verwaltet.

So stellt Annalena Baerlauch sich das vielleicht vor.

@ Markus W.:
Hoer blos nicht auf "solche" Erklaerungen. Musst du ja auch nicht.
Du weisst ja wie es geht...

Die Aufteilung auf einzelne Filesysteme war eher dazu gedacht,
Filesysteme auf die wenig bis gar nicht geschrieben wurde
von denen mit viel Schreibleistung zu separieren um im Falle
eines Systemcrashs/Blackout/etc. den Aufwand fuer Reparaturmassnahmen
zu minimieren. Unter Solaris konnte man z.B. /usr read only mounten.
Das erleichterte natuerlich auch den Export per NFS fuer
Maschinen ganz ohne Platten.
Das kleinere Backups schneller gehen ist auch eine Tatsache.

Und das Maximum an Flexibilitaet erreichte der LVM vom AIX
ebenfalls schon vor Jahrzehnten. Da wird die ganze Platte naemlich
in winzige Haeppchen (PPs) aufgeteilt, die man einzelnen "Logical
Volumes" zuteilen kann auf denen dann die Mountpoints sitzen.
Solchen Zirkus machte man schon mit 300 MB Platten...
Und mirroring und striping und softraid und physical mapping und ...
ging damit auch noch. Man konnte sogar Filesysteme im laufenden
Betrieb vergroessern!

Da du bislang auch nicht schluessig darlegen konntest, fuer was der
"Unfug" mit /home /var und /tmp in einer Partition gut sein soll
klinke ich mich hier jetzt aus.

Jemand, der nicht gerade der absolute Anfaenger ist, haette
der Stichpunkt "bind mount" allemal gereicht.
Und das nun gleich vom Installer zu verlangen, zeugt auch
von einer gewissen Unkenntnis.

von Taucher (Gast)


Lesenswert?

Cartman schrieb:
> Jemand, der nicht gerade der absolute Anfaenger ist, haette
> der Stichpunkt "bind mount" allemal gereicht.
> Und das nun gleich vom Installer zu verlangen, zeugt auch
> von einer gewissen Unkenntnis.

Oh, mal wieder ein richtiger Experte… Mein Rat: bewirb dich beim Zirkus 
als "Kluger Hans".

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Alter hör doch auf zu trollen. Du bist einfach nur lächerlich. Geh 
weiter deine mtab anstarren.

von Drago S. (mratix)


Lesenswert?

OT: Da klöppeln sie sich 3 Tage lang gegenseitig die Köppe ein.. ;)

Habt ihr Jungs keine Freizeit, Hobbys, geht ihr keiner Arbeit nach? Habt 
ihr gerade Ferien und noch keinen Job?

Schade, das wieder mal ein Thread zerfleischt wurde.

@Mod: Ab Mitte kann man abschneiden, dass wenigstens die Nachwelt noch 
was hat.

Schönen Tag. Seid lieb zueinander.

von Markus W. (dl8mby)


Lesenswert?

Was mich noch interessieren würde ist die Aussage
weiter oben, dass man die noexec Konfiguration einer
Partition bzw eines FS umgehen kann - ist das so?
Da habe ich wohl noch eine Wissenslücke.


>> Lediglich ein
>> sticky bit und ggf ein noexec flag ist gesetzt; das kannst du aber
>> selbst nachholen mit chmod bzw. in /etc/fstab.

>Vorsicht, manche (z.B. electron-) Anwendungen erwarten, dass sie aus
>"/tmp" binaries ausführen können.
>Ein echter Sicherheitsgewinn ist es eh nicht, per
>"/lib64/ld-linux-x86-64.so.2 /tmp/irgendwas" kann man das "noexec"-Flag
>umgehen.

Markus

von Markus W. (dl8mby)


Lesenswert?

Habe es jetzt selber nachgestellt und es geht nicht.
Ist eventuell bei früheren Linux Versionen möglich gewesen.
Falls ich einen Fehler beim Erzeugen des shared Bineries
gemacht haben sollte, so bitte aufzeigen.
Für mich war der Test jetzt schlüssig und widerlegt die
o.g. Behauptung - hätte mich auch etwas entsetzt ;-)

Markus
1
>pwd
2
/tmp
3
mw@linux-kwm1:/tmp
4
5
>cat testsomw.c
6
#include<stdio.h>
7
8
const char my_interp[] __attribute__((section(".interp"))) = "/lib64/ld-linux-x86-64.so.2";
9
10
int entry()
11
{
12
  printf("%s\n","Es geht");
13
  exit(0);
14
}
15
16
gcc -shared -fPIC -e entry testsomw.c -o testsomw.so
17
18
>ldd testsomw.so
19
        linux-vdso.so.1 (0x00007ffd3a767000)
20
        libc.so.6 => /lib64/libc.so.6 (0x00007f16662a6000)
21
        /lib64/ld-linux-x86-64.so.2 (0x00007f166650f000)
22
23
/dev/sda3 on /tmp type btrfs (rw,nosuid,nodev,noexec,noatime,space_cache,subvolid=5,subvol=/)
24
25
>/lib64/ld-linux-x86-64.so.2 ./testsomw.so
26
./testsomw.so: error while loading shared libraries: ./testsomw.so: failed to map segment from shared object
27
28
/dev/sda3 on /tmp type btrfs (rw,nosuid,nodev,noatime,space_cache,subvolid=5,subvol=/)
29
30
>/lib64/ld-linux-x86-64.so.2 ./testsomw.so
31
Es geht

von Εrnst B. (ernst)


Lesenswert?

Markus W. schrieb:
> Habe es jetzt selber nachgestellt und es geht nicht.

Ohje, ich werd alt...

Im Kernel 2.6.0 ist der Check dazugekommen, dass kein PROT_EXEC mmap 
mehr von "noexec"-gemounteten Dateisystemen zulässig ist.

hättest übrigens nicht extra ein .so für deinen Test kompilieren müssen, 
ein
1
gcc -o test_noexec test_noexec.c
2
/lib64/ld-linux-x86-64.so.2 ./test_noexec
erfüllt denselben Zweck.

von Markus W. (dl8mby)


Lesenswert?

@Εrnst B.

ich dachte Dein Einwandt bezieht sich auf Bineries,
die shared libs nachladen, deshalb diese Art der Compilierung.
Aber ich bin da kein Experte, was das Nachladen von Objekten
in Linux angeht, und lerne gerne dazu.

LG
MArkus

von Εrnst B. (ernst)


Lesenswert?

Markus W. schrieb:
> ich dachte Dein Einwandt bezieht sich auf Bineries,

Nö, eigentlich Binaries generell.

Analog zu

./x.sh # <- geht nicht bei noexec
bash x.sh # <- geht trotz noexec

war's früher

./binary # <- geht nicht wegen noexec
...ld.so ./binary # <- umgeht noexec

Über den mmap-PROT_EXEC - Fix wird letzteres jetzt auch verhindert.
ld.so will das binary per mmap ausführbar in den RAM mappen, und das 
geht nicht.
Nachladen von *.so-Dateien würde ebenso ein mmap verwenden, und ist 
genauso geblockt.

Wenn man sich einen elf-loader bastelt, der statt mmap einfach ein 
read() verwendet, könnte man das umgehen. Aber: Henne-Ei-Problem, wie 
kriegst du diesen Loader ausgeführt :)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.