the sophtwearteam

Change, break, repair, repeat

Mein File-, Mail- und Webserver, eine virtuelle Debian-Maschine unter VMware, hatte eine ext4-Partition von 3 TB. Jedesmal, wenn die Kiste hochgefahren ist, hat er versucht die 3 TB mit fsck zu prüfen, aber wegen der Größe lief er in einen Timeout. Dann landete er in einer maintenance console und ich musste das Dateisystem ungeprüft manuell mounten und dann mit systemctl default vollständig booten. Das hat zwar meist funktioniert, aber gelegentlich hat er auch mal einen zweiten Anlauf gebraucht. Das hat mich aber dennoch ganz schon genervt und so war ich recht angetan von einer Möglichkeit ein Dateisystem “on the fly” zu konvertieren.

fstranform

Den Hinweis erhielt ich in einem Artikel der englischsprachigen Ausgabe des Linux-Magazin und war froh darüber einen recht einfachen Weg gefunden zu haben, die Sache nun zu einem guten Ende zu führen.

Angefangen habe ich am Freitagabend um 18:50 Uhr und bin gleich mal auf die Nase gefallen, weil das betreffende Dateisystem sich nicht aushängen (unmount) ließ.

2023-08-11 18:50:46 fstransform: saving output of this execution into /var/tmp/fstransform/fstransform.log.5905
2023-08-11 18:50:46 fstransform: preparing to transform device ‘/dev/mapper/data–vg-data’ to file-system type ‘xfs’
2023-08-11 18:50:46 fstransform: device is mounted at ‘/data’ with file-system type ‘ext4′
2023-08-11 18:50:46 fstransform: device raw size = 3298530689024 bytes
2023-08-11 18:50:46 fstransform: creating sparse loop file ‘/data/.fstransform.loop.5905′ inside device ‘/dev/mapper/data–vg-data’…
2023-08-11 18:50:46 dd: 1+0 Datensätze ein
2023-08-11 18:50:46 dd: 1+0 Datensätze aus
2023-08-11 18:50:46 dd: 1 Byte kopiert, 0,000565926 s, 1,8 kB/s
2023-08-11 18:50:46 fstransform: device file-system block size = 4096 bytes
2023-08-11 18:50:46 fstransform: device usable size = 3298530689024 bytes
2023-08-11 18:50:46 dd: 1+0 Datensätze ein
2023-08-11 18:50:46 dd: 1+0 Datensätze aus
2023-08-11 18:50:46 dd: 1 Byte kopiert, 0,000489181 s, 2,0 kB/s
2023-08-11 18:50:46 fstransform: unmounting device ‘/dev/mapper/data–vg-data’ and remounting it read-only using kernel driver
2023-08-11 18:50:46 umount: /data: target is busy.

Also musste erst mal ein Reboot her und das übliche Procedere. Zehn Minuten später also der zweite Versuch. Diesmal lief es gut an, aber es prognostizierte mir einen Tag und 20 Stunden Laufzeit.

2023-08-11 19:00:01 fstransform: saving output of this execution into /var/tmp/fstransform/fstransform.log.1324
2023-08-11 19:00:01 fstransform: preparing to transform device ‘/dev/mapper/data–vg-data’ to file-system type ‘xfs’
2023-08-11 19:00:01 fstransform: device ‘/dev/mapper/data–vg-data’ not found in the output of command /usr/bin/mount, assuming it is not mounted
2023-08-11 19:00:02 fstransform: device is now mounted at ‘/tmp/fstransform.mount.1324′ with file-system type ‘ext4′
2023-08-11 19:00:02 fstransform: device raw size = 3298530689024 bytes
2023-08-11 19:00:02 fstransform: creating sparse loop file ‘/tmp/fstransform.mount.1324/.fstransform.loop.1324′ inside device ‘/dev/mapper/data–vg-data’…
2023-08-11 19:00:02 dd: 1+0 Datensätze ein
2023-08-11 19:00:02 dd: 1+0 Datensätze aus
2023-08-11 19:00:02 dd: 1 Byte kopiert, 0,000522247 s, 1,9 kB/s
2023-08-11 19:00:02 fstransform: device file-system block size = 4096 bytes
2023-08-11 19:00:02 fstransform: device usable size = 3298530689024 bytes
2023-08-11 19:00:02 dd: 1+0 Datensätze ein
2023-08-11 19:00:02 dd: 1+0 Datensätze aus
2023-08-11 19:00:02 dd: 1 Byte kopiert, 0,000487245 s, 2,1 kB/s
2023-08-11 19:00:02 fstransform: unmounting device ‘/dev/mapper/data–vg-data’ and remounting it read-only using kernel driver
2023-08-11 19:00:03 fstransform: launching ‘/usr/sbin/fsremap’ in simulated mode for pre-validation
2023-08-11 19:00:03 fsremap: setting log level to NOTICE
2023-08-11 19:00:03 fsremap: starting job 1, persistence data and logs are in ‘/var/tmp/fstransform/fsremap.job.1′
2023-08-11 19:00:03 fsremap: analysis completed: 8.00 kilobytes must be relocated
2023-08-11 19:00:03 fsremap: allocated 8.00 kilobytes RAM as memory buffer
2023-08-11 19:00:03 fsremap: primary-storage is 1.00 megabytes, initialized and mmapped() to contiguous RAM
2023-08-11 19:00:03 fsremap: (simulated) starting in-place remapping. this may take a LONG time …
2023-08-11 19:00:03 fsremap: (simulated) progress: 50.0% done, 8.0 kilobytes still to remap
2023-08-11 19:00:03 fsremap: (simulated) clearing 3.00 terabytes free-space from device …
2023-08-11 19:00:03 fsremap: (simulated) job completed.
2023-08-11 19:00:03 fstransform: unmounting device ‘/dev/mapper/data–vg-data’ and remounting it read-write
2023-08-11 19:00:03 fstransform: connected loop device ‘/dev/loop0′ to file ‘/tmp/fstransform.mount.1324/.fstransform.loop.1324′
2023-08-11 19:00:03 fstransform: formatting loop device ‘/dev/loop0′ with file-system type ‘xfs’…
2023-08-11 19:00:06 fstransform: mounting loop device ‘/dev/loop0′ on ‘/tmp/fstransform.loop.1324′ …
2023-08-11 19:00:07 fstransform: loop device ‘/dev/loop0′ mounted successfully.
2023-08-11 19:00:07 fstransform: preliminary steps completed, now comes the delicate part:
2023-08-11 19:00:07 fstransform: fstransform will move ‘/dev/mapper/data–vg-data’ contents into the loop file.

2023-08-11 19:00:07 fstransform: WARNING: THIS IS IMPORTANT! if either the original device ‘/dev/mapper/data–vg-data’
or the loop device ‘/dev/loop0′ become FULL,

YOU WILL LOSE YOUR DATA !

fstransform checks for enough available space,
in any case it is recommended to open another terminal, type
watch df /dev/mapper/data–vg-data /dev/loop0
and check that both the original device ‘/dev/mapper/data–vg-data’
and the loop device ‘/dev/loop0′ are NOT becoming full.
if one of them is becoming full (or both),
you MUST stop fstransform with CTRL+C or equivalent.

2023-08-11 19:00:07 fstransform: moving ‘/dev/mapper/data–vg-data’ contents into the loop file.
2023-08-11 19:00:07 fstransform: this may take a long time, please be patient…
2023-08-11 19:13:47 fsmove: progress: 0.5% done, 1.9 terabytes still to move
2023-08-11 19:23:20 fsmove: progress: 0.9% done, 1.9 terabytes still to move, estimated 1 day and 20 hours left
2023-08-11 19:34:26 fsmove: progress: 1.4% done, 1.9 terabytes still to move, estimated 1 day and 20 hours left

Gut, es war Wochenende, was sollte schon schief gehen und abbrechen konnte ich eh nicht mehr. Die Prognose hat dann ohnehin nicht so ganz gestimmt und es war bereits am Sonntag Vormittag soweit, dass er auf 100 % lief, doch dann hat er noch “remappen” müssen und das hat nochmal solange gedauert.

10:16:42 fsremap: (simulated) progress: 99.1% done, 19.2 gigabytes still to remap, estimated 0 seconds left
10:16:42 fsremap: (simulated) progress: 99.7% done, 7.1 gigabytes still to remap, estimated 0 seconds left
10:16:42 fsremap: (simulated) progress: 100.0% done, 439.4 megabytes still to remap, estimated 0 seconds left
10:16:42 fsremap: (simulated) clearing 1.12 terabytes free-space from device …
10:16:42 fsremap: (simulated) job completed.
10:16:42 fstransform: launching ‘/usr/sbin/fsremap’ in REAL mode to perform in-place remapping.
10:16:42 fsremap: setting log level to NOTICE
10:16:42 fsremap: starting job 3, persistence data and logs are in ‘/var/tmp/fstransform/fsremap.job.3′
10:16:42 fsremap: if this job is interrupted, for example by a power failure,
10:16:42 fsremap: you CAN RESUME it with: /usr/sbin/fsremap -q –resume-job=3 — /dev/mapper/data–vg-data
10:16:43 fsremap: analysis completed: 1.88 terabytes must be relocated
10:16:43 fsremap: allocated 1.85 gigabytes RAM as memory buffer
10:19:43 fsremap: primary-storage is 3.69 gigabytes, initialized and mmapped() to contiguous RAM
10:19:43 fsremap: successfully unmounted device ‘/dev/mapper/data–vg-data’
10:19:43 fsremap: starting in-place remapping. this may take a LONG time …
10:24:49 fsremap: progress: 0.1% done, 1.9 terabytes still to remap
03:28:12 fsremap: progress: 39.7% done, 1.1 terabytes still to remap, estimated 1 day and 20 hours left
08:41:35 fsremap: progress: 64.5% done, 684.9 gigabytes still to remap, estimated 1 day left
11:49:58 fsremap: progress: 79.7% done, 392.9 gigabytes still to remap, estimated 15 hours left
13:42:44 fsremap: progress: 88.5% done, 222.4 gigabytes still to remap, estimated 8 hours left
14:50:18 fsremap: progress: 93.6% done, 124.8 gigabytes still to remap, estimated 4 hours left
15:30:21 fsremap: progress: 96.5% done, 69.0 gigabytes still to remap, estimated 2 hours left
15:53:59 fsremap: progress: 98.2% done, 37.0 gigabytes still to remap, estimated 1 hour and 8 minutes left
16:07:26 fsremap: progress: 99.1% done, 19.2 gigabytes still to remap, estimated 30 minutes left
16:16:56 fsremap: progress: 99.7% done, 7.1 gigabytes still to remap, estimated 10 minutes left
16:20:25 fsremap: progress: 100.0% done, 449.4 megabytes still to remap, estimated 25 seconds left
16:20:35 fsremap: clearing 1.12 terabytes free-space from device …

Irgendwann heute Nacht muss er damit fertig gewesen sein, denn ich hatte heute Abend die Erfolgsmeldung.

00:35:45 fstransform: running again ‘/usr/sbin/fsck’ (disk check) on device ‘/dev/mapper/data–vg-data’
00:35:45 fsck: fsck from util-linux 2.38.1
00:35:46 fsck: /usr/sbin/fsck.xfs: XFS file system.
00:35:46 fstransform: completed successfully. device ‘/dev/mapper/data–vg-data’ now contains ‘xfs’ file-system

Doch nun gab es ein neues Problem. Warum die Partitonstabelle auf “dos” stand kann ich nicht erklären, hätte ich anders erwartet. Fakt ist jedenfalls, das nun angeblich nach XFS konvertierte Dateisystem ließ sich nicht dazu übereden eingehängt zu werden.

Plan B

Mit der Gewissheit ein funktionierendes Backup im Rücken zu haben, hab ich also das Dateisystem kurzerhand platt gemacht und mit

sudo mkfs.xfs -f /dev/mapper/data--vg-data

manuell formatiert. Nächster Schritt: Restore eines Backup. Ausgang ungewiss.

TMUX voll ausgespielt

Bei der ganzen Sache hatte ich den Terminal Multiplexer TMUX im Einsatz, sonst wäre das gar nicht gegangen:

Hier konnte TMUX mal zeigen, was es kann. Horizontal dreigeteilter Bildschirm (drei Panes) um zwei Prozesse und deren Meldungen beobachten zu können, ein Teil um eingreifen zu können und zur Laufzeit Infos abzufragen (df) und ein weiteres Fenster zum rüberspringen, wenn es schwierig werden sollte und man mehr Platz auf dem Schirm für lange und breite Ausgaben braucht. Das habe ihc dann tatsächlich gebraucht, um mir dann z. B. die Logdateien anzusehen.