Wie lange dauert denn das formatieren der SSD ?
Habe gerade überlegt mit mkntfs --quick würde er ja nur eine Schnellformatierung machen.
… würde ja (wahrscheinlich) reichen - wenn ntfs eine prinzipiell gute Option wäre.
(wenn man wüßte was da tatsächlich geschrieben wird - und wenn ntfs überhaupt eine gute Option wäre …)
… wieso würde eine (wie auch immer große) Löschoperation
auf einer SSD
eine halbe Stunde dauern?
Das dauert ja nicht mal auf einer HDD (spinning disk) so lange - nicht mal annähernd …
ganz egal, wie viele Dateien da sind …
does not compute …
Ja, ich meine natürlich eine Schnellformatierung. Das geht innerhalb einer Sekunde. Eine vollständie Formatierung macht man doch seit Jahrzehnten nicht mehr, außer vielleicht letztens auf ein paar 3,5"-Disketten mit MS-DOS-Originalen, die nicht mehr wollten 
Ext4 macht das immer noch, nur eben verzögert dank lazyinit. Eine volle Formatierung beinhaltet auch die Suche nach Badblocks (schlechten Sektoren), meines wissens, und soll ja bei rotierenden Festplatten nützlich sein, wurde mir mal so nebenbei gesagt.
2 Likes
re:
mkntfs --quick
man mkntfs
-f, --fast, -Q, --quick
Perform quick (fast) format. This will skip both zeroing of the volume and bad sector checking.
… I think it’s important to know what is (or is not) happening …
it could be fast - but it will also bite you, eventually …
1 Like
Ja, ich habe hier auch nur zur Vereinfachung sdb5 geschrieben. Ich lasse die Partition aber in der fstab über die UUID mounten. Deshalb werden ich mkfs.j2fs -U verwenden, da weiß ich sicher, wie es funktioniert.
Gut, da ich j2fs verwende wird das “lazy-init-Problem” wohl nicht existieren, da j2fs ja unötige Writes vermeiden soll.
I don’t think j2fs is a good choice.
A very bad one, actually.
But: do go ahead …
1 Like
Das liegt eventuell nur am verwendeten Dateisystem 
Zitat aus der Wikipedia:
Es wird zwar Linux unterstützt, aber die Defragmentierung wurde bislang noch nicht auf Linux portiert. Dies kann dazu führen, dass durch das Anlegen und Löschen vieler kleiner Dateien (einige KiB) das Dateisystem fragmentiert und vor allem die Schreibzugriffe sich etwas verlangsamen und eine höhere CPU-Last erzeugen.
Everyone decides according to their own knowledge
Dass das Filesystem gerade beim Verarbeiten großer Dateienzahlen eine sehr wichtige Rolle spielt und es teils dramatische Unterschiede gibt ist sicher richtig und mir bekannt. Auf Grund der Vorteile die J2FS bezüglich der Lebensdauer der SSD bietet, möchte ich dabei bleiben und mit einer Schnellformatierung ist das Problem ja gelöst.
Of course.
But this is, if I recall correctly, the file system that is used on devices like routers
that run OpenWRT, for example
the memory they have is some kind of flash memory - and this filesystem suits this.
… does NOT apply to ssd (hard disk) memory - it’s decidedly different
It’s just the TOTALLY wrong tool for the job here …
I mean it.
It’s the wrong thing ™ .
… but: it’s your decision, it’s your device …
1 Like
Sorry, there may have been a typo or confusion by myself in this thread somewhere. I am using ‘f2fs’ not ‘jffs2’.
Hallo!
Ich habe nun Beides gebaut, das neue unit-file und das neue Skript. Noch funktioniert es nicht - die Dateien auf dem Desktop und in Downloads werden so nicht gelöscht.
Natürlich ist das nun schwierig zu debuggen, weil ja nach dem Reboot Nichts mehr davon zu sehen ist, und wohl auch das Journal nicht geschrieben werden kann wenn die Filesystems schon unmounted wurden.
Ich vermute im Moment, dass es wohl einfach daran liegt, dass ein oder mehrere benötigte Binaries im Moment der Ausführung nicht mehr zur Verfügung stehen. Nach dem Alles unmountet wurde steht ja nur noch rootfs zur Verfügung, oder? Vielleicht gibt es sogar /bin/bash selbst schon gar nicht mehr? (Ich weiss nicht, was im Boot-Image von Manjaro so existiert…).
Was den Rest angeht, nach dem Löschen:
Es könnte wohl auch passieren, dass zur Neuerstellung der Ordner /tmp nicht mehr zur Verfügung steht? Dann wäre es vielleicht möglich den Startpunkt der unit so zu legen, dass sie nach dem Unmounten der physischen Laufwerke aber vor dem Unmounten von /tmp aktiv wird?
Falls das nicht klappt, wäre meine nächste Idee ein Minimalimage (nur belegte Blöcke) der Partition zu erstellen und die Partition einfach per mit ihrem leeren Ausgangszustand zu überschreiben.
Oder, im schlimmsten Fall, das Erstellen/Zurückkopieren der neuen leeren Ordner auf den Boot zu verlagern, was ich aber gerne vermeiden würde umd en Vorgang kompakt und übersichtlich zu belassen.
Unit:
[Unit]
Requires=umount.target
After=umount.target
Before=shutdown.target final.target
#ExecStart=/usr/bin/wipefs --all /dev/sdXY
#Besser wäre (bin mir aber nicht sicher ob die UUID bestehen bleibt nach einem Wipe, aber sdXY kann sich bei jedem Start ändern):
#ExecStart=/usr/bin/wipefs --all /dev/disk/by-uuid/<UUID>
[Service]
ExecStart=/opt/scripts/formatdeskdown.sh
Und das Skript:
#!/bin/bash
targetuuid=$(a851c5cb-dae1-4b96-90f2-d0ae270e00d4)
mkfs.f2fs /dev/disk/by-uuid/"$targetuuid" -U "$targetuuid" -f
mkdir /tmp/"$targetuuid"
mount /dev/disk/by-uuid/"$targetuuid" /tmp/"$targetuuid"/ -o noatime
fstrim -a
sudo rsync -aAX /ladminfolders/desktop /tmp/"$targetuuid"/
sudo rsync -aAX /ladminfolders/downloads /tmp/"$targetuuid"/
umount /dev/disk/by-uuid/"$targetuuid"
sync
(Anstatt die Ordner im Skript neu zu erstellen lasse ich per rsync nun eine Kopie der leeren Ordner zurückkopieren, da ich diese damals glaube ich mit einigen ACLs behandeln musste, damit das Ersetzen des Desktopordners für den Desktophintergrund einwandfrei funktionierte. Um diese ACL-Fummelei zu umgehen arbeite ich nun also einfach mit einer Kopie der leeren Ordner im Originalzustand)
Die Idee mit den systemd-tmpfiles habe ich erst mal hintenan gestellt, weil ich mich da noch ordentlich einlesen müsste…
Ich habe das Skript auf dem normal laufenden Desktop mit einer Testpartition ausprobiert, wo es einwandfrei funktionierte. Geradee deshalb habe ich natürlich den Verdacht, dass es an fehlenden Binaries liegen könnte, die nach dem Unmounten von / usw nicht mehr zur Verfügung stehen. Wie könnte ich der Sache auf die Spur kommen?
Ist also nach " umount.target" /bin noch gemountet, oder nur noch das rootfs, oder bootimage, wie auch immer es auf Manjaro heißt, verfügbar?
Während des Shutdowns fiel mir keine Fehlermeldung diesbezüglich auf, aber der geht ja nun auch zu schnell um viel zu sehen.
Danke! 