Convert from btrfs to xfs: lseek error

[systemcrash]

I reach the fsremap stage later on, after the simulated ... step completes successfully. It always stops with

ERROR I/O error in device lseek(fd = 5, offset = 89688313856, SEEK_SET): Invalid argument. The actual error in the log file goes: ERROR [io/io_posix.flush_copy_bytes (1128)] I/O error in device lseek(fd = 5...)

This 89688313856 exists in the loop_extents.txt files for that job, so it's a legitimate entry. The disk is an 80GB disk if it matters. The disk was prepped and OK after an offline btrfsck --repair.

This is reproducible (I can roll back the disk changes and try again). Any ideas?

Does this mean that the holes of free-space are not big enough to accommodate the incoming data? Is there an easy fix?

=== BTW, this might be a bug, but if I supply --opts-fsremap=' -f ' to fstransform at first run, this -f option is not included the first time fsremap is called. But subsequent invocations honour it.

e.g. fstransform logs:

18:48:38 ERROR! fstransform: command '/usr/sbin/fsremap -q -n -- /dev/sda3 /tmp/fstransform.mount.2410/.fstransform.loop.2410' failed (exit status 234)

Other terminal:

sudo fsremap -f --questions=yes -n -- /dev/sda3 /tmp/fstransform.mount.2410/.fstransform.loop.2410
setting log level to INFO
fsremap: starting job 2, persistence data and logs are in '/var/tmp/fstransform/fsremap'
device length is 77.67 gigabytes
'/dev/sda3' is device 0x0803, but loop-file /tmp/fstransform.mount.2410/.fstransform. loop.241 is contained in device 0x0033, continuing AT YOUR OWN RISK due to '-f'
analyzing device/dev/sda3, this may take some minutes
device effective block size = 4096
using reduced (32 bit) remapping algorithm
analysis completed: 8.00 kilobytes must be relocated
primary-storage: located 77.67 gigabytes (8 fragments) usable in device (free, invariant, contiguous and aligned)
primary-storage: actually using 1.00 megabytes (1 fragment) from device
allocated 8.00 kilobytes RAM as memory buffer
not creating secondary-storage, primary-storage is large enough
primary-storage is 1.00 megabytes, initialized and mmapped () to contiguous RAM
(simulated) starting in-place remapping. this may take a LONG time (simulated) filling storage by moving 8.00 kilobytes from device 
(simulated) storage filled
(simulated) progress: 50.0% done,    8.0 kilobytes still to remap
(simulated) moving 8.00 kilobytes from storage to target
(simulated) finished moving from storage to target
(simulated) blocks remapping completed.
(simulated) clearing 77.67 gigabytes free-space from device
(simulated) device free-space cleared
(simulated) job completed.

CONTINUE in first terminal and eventually ERROR I/O error in device lseek(fd = 5, offset = 89688313856, SEEK_SET): Invalid argument

[cosmos72]

Hi Paul, sorry for the extremely late reply, I did not notice your issue.

Can you post the output of fdisk -lu /dev/sda ? It seems there is some disagreement between the length of partition /dev/sda3 and the length of the btrfs filesystem inside it...

On Mon, Jun 24, 2024, 22:38 Paul Donald @.***> wrote:

I reach the fsremap stage later on, after the simulated ... step completes successfully. It always stops with

ERROR I/O error in device lseek(fd = 5, offset = 89688313856, SEEK_SET): Invalid argument. The actual error in the log file goes: ERROR [io/io_posix.flush_copy_bytes (1128)] I/O error in device lseek(fd = 5...)

This 89688313856 exists in the loop_extents.txt files for that job, so it's a legitimate entry. The disk is an 80GB disk if it matters. The disk was prepped and OK after an offline btrfsck --repair.

This is reproducible (I can roll back the disk changes and try again). Any ideas?

Does this mean that the holes of free-space are not big enough to accommodate the incoming data? Is there an easy fix?

=== BTW, this might be a bug, but if I supply --opts-fsremap=' -f ' to fstransform at first run, this -f option is not included the first time fsremap is called. But subsequent invocations honour it.

e.g. fstransform logs:

18:48:38 ERROR! fstransform: command '/usr/sbin/fsremap -q -n -- /dev/sda3 /tmp/fstransform.mount.2410/.fstransform.loop.2410' failed (exit status 234)

Other terminal:

sudo fsremap -f --questions=yes -n -- /dev/sda3 /tmp/fstransform.mount.2410/.fstransform.loop.2410 setting log level to INFO fsremap: starting job 2, persistence data and logs are in '/var/tmp/fstransform/fsremap' device length is 77.67 gigabytes '/dev/sda3' is device 0x0803, but loop-file /tmp/fstransform.mount.2410/.fstransform. loop.241 is contained in device 0x0033, continuing AT YOUR OWN RISK due to '-f' analyzing device/dev/sda3, this may take some minutes device effective block size = 4096 using reduced (32 bit) remapping algorithm analysis completed: 8.00 kilobytes must be relocated primary-storage: located 77.67 gigabytes (8 fragments) usable in device (free, invariant, contiguous and aligned) primary-storage: actually using 1.00 megabytes (1 fragment) from device allocated 8.00 kilobytes RAM as memory buffer not creating secondary-storage, primary-storage is large enough primary-storage is 1.00 megabytes, initialized and mmapped () to contiguous RAM (simulated) starting in-place remapping. this may take a LONG time (simulated) filling storage by moving 8.00 kilobytes from device (simulated) storage filled (simulated) progress: 50.0% done, 8.0 kilobytes still to remap (simulated) moving 8.00 kilobytes from storage to target (simulated) finished moving from storage to target (simulated) blocks remapping completed. (simulated) clearing 77.67 gigabytes free-space from device (simulated) device free-space cleared (simulated) job completed.

CONTINUE in first terminal and eventually ERROR I/O error in device lseek(fd = 5, offset = 89688313856, SEEK_SET): Invalid argument

— Reply to this email directly, view it on GitHub https://github.com/cosmos72/fstransform/issues/57, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO3NBW765TFW2ZTRS5YF63ZJB7VFAVCNFSM6AAAAABJ2QRRO2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGM3TCMBVGA2TSMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[systemcrash]

No worries @cosmos72 - you might be right but I did not retain the source disk to play with it. I just used good old rsync with a new target disk of equal size.

Thanks for the interesting tool - I will try it again at some point!