Many thanks for your input!!

V.

There is a bug as the help says is supports T for tebibytes which is does not ; you have to specify the size in gibibytes (careful that 1 tebibyte = 1024 gibibytes)
You can display your volume size in gibibytes with

# btrfs filesystem show –gbytes

For the second error that may be because it is tried to be wrongly interpreted as an argument.
I had the same issue and worked around by specifying the target size instead.

# btrfs resize filesystem 18232G /volume1

Everything went fine this way.

Unfortunatelly, I can’t help. Your command seems correct. Really no clue what’s wrong.

root@ds1517:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vg1/volume_1 7.3T 4.0T 3.3T 56% /volume1

root@ds1517:~# btrfs filesystem resize 5T /volume1
Resize ‘/volume1’ of ‘5T’
ERROR: unable to resize ‘/volume1’: Invalid argument

root@ds1517:~# btrfs filesystem resize -3T /volume1
btrfs filesystem resize: invalid option — ‘3’
usage: btrfs filesystem resize [devid:][+[?]/-][kKmMgGtTpPeE]|[devid:]max

Resize a filesystem

If ‘max’ is passed, the filesystem will occupy all available space
on the device ‘devid’.
[kK] means KiB, which denotes 1KiB = 1024B, 1MiB = 1024KiB, etc.
If ‘+’ is followed by ‘?’, it is dry-run mode to query if it can expand for
a specific size

It is more than 10TB … so I decided remove these disks and restore what I can.

Thank you anyway!

Have a great Holidays 🙂

Your partition is a 1.5TB, right? I guess it can take several days to be resized based on my experience with similar operations on large disks.
That being said, I really hope it will work (and you have a backup ?!). My attempts here above were successful but all experimental (and with smal disks)!

Wait as long as you can before stopping the process as it would nuke the partition (quite sure)
And, unfortunatelly, I didn’t experiment yet how to restore the partition into its initial state after an aborted resized…

V.

Dear Valery,

I hope you are doing well.

I received this one after execute “e2fsck -f /dev/vg1000/lv”

If I hit “yes” to abort I can not execute “resize2fs -M /dev/vg1000/lv” so I selected “no”, then it asks to fix it or not.
Well I had to put a small weight on the “y” button and it is running since yesterday afternoon (more than 12 hours already).

At this point I think I lost all my data on the volume, am I right?

I have unfortunately no experience with this error yet…

At which step are you in the process? Did you already resize the partition?

If you did, you can try one of those two fixes: https://www.linuxquestions.org/questions/blog/kostya-519950/fixing-superblock-problems-4012/

I’m stucked here
e2fsck 1.42.6 (21-Sep-2012)
The filesystem size (according to the superblock) is 3168398336 blocks
The physical size of the device is 3045227520 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? yes

What can I do in this situation?

Thank you in advance