http://bugzilla.suse.com/show_bug.cgi?id=1149148 Kai Dupke changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #816609|0 |1 is obsolete| | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1149148 http://bugzilla.suse.com/show_bug.cgi?id=1149148#c2 Ancor Gonzalez Sosa changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ancor@suse.com Flags| |needinfo?(aschnell@suse.com | |) --- Comment #2 from Ancor Gonzalez Sosa --- I'm pretty sure this is the reason: https://github.com/openSUSE/libstorage-ng/blob/master/storage/Filesystems/Bl... As you can see there, to stay safe libstorage-ng multiplies the 14T that the system reports as the minimum size. Fun enough, in this case that results in the minimum being even bigger than the current and the maximum sizes. For completeness, some relevant lines from the logs. AppUtil.cc:171 path:/tmp/[...] blocks:5461618852 bfree:1728779100 bsize:4096 size:22370790817792 free:7081079193600 BlkFilesystemImpl.cc:288 on-disk resize-info:resize-ok:true reasons:192 min-size:22548544749568 max-size:17592186044416 block-size:1 Arvin, can't we adjust that 1.5 to something more reasonable? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1149148 http://bugzilla.suse.com/show_bug.cgi?id=1149148#c4 --- Comment #4 from Kai Dupke --- (In reply to Arvin Schnell from comment #3)

Depends on what is reasonable. It will likely need research for every filesystem.

I wonder if this has to be a factor, or if a fixed amount (i.e. 250GB) would do as well.

Another problem is that the maximal size for ext4 is set to 16 TiB. This is done since ext4 needs the 64bit feature to handle larger devices (https://www.netways.de/blog/2017/12/13/how-to-use-ext4-beyond-16tib/). E.g. an ext4 normally created on SLE12 SP3 cannot be grown beyond 16 TiB. So strictly speaking the 64bit feature must be checked (using dumpe2fs).

In the shrinking case, this can't be an issue, can it be? In case a size bigger then 16TB, 64bit must be already enabled, right? So shrinking does not need to check this flag. I wonder if it is checked for extending, but at least for openSUSE I am not aware of any notice when I extended a FS beyond 16TB (this system alone has 2 FS > 16TB) resp. created a FS that big. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1149148 http://bugzilla.suse.com/show_bug.cgi?id=1149148#c5 --- Comment #5 from Arvin Schnell --- (In reply to Kai Dupke from comment #4)

(In reply to Arvin Schnell from comment #3)

...

Depends on what is reasonable. It will likely need research for every filesystem.

I wonder if this has to be a factor, or if a fixed amount (i.e. 250GB) would do as well.

Likely not a good idea, e.g. for an almost empty 200 GiB filesystem.

...

Another problem is that the maximal size for ext4 is set to 16 TiB. This is done since ext4 needs the 64bit feature to handle larger devices (https://www.netways.de/blog/2017/12/13/how-to-use-ext4-beyond-16tib/). E.g. an ext4 normally created on SLE12 SP3 cannot be grown beyond 16 TiB. So strictly speaking the 64bit feature must be checked (using dumpe2fs).

In the shrinking case, this can't be an issue, can it be? In case a size bigger then 16TB, 64bit must be already enabled, right? So shrinking does not need to check this flag.

The library provides the possible range for resizing. For the range to be correct the flag is needed and that was the use-case I had in mind.

I wonder if it is checked for extending, but at least for openSUSE I am not aware of any notice when I extended a FS beyond 16TB (this system alone has 2 FS > 16TB) resp. created a FS that big.

The libstorage provides the maximal allowed value for a FS. Whether the UI code uses it I cannot say. BTW: The resize operation might have to move several TiB on the disk. That could take several hours. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1149148 http://bugzilla.suse.com/show_bug.cgi?id=1149148#c6 Arvin Schnell changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS Target Milestone|--- |Leap 15.2 --- Comment #6 from Arvin Schnell --- The YaST team decided to use the value reported by resize2fs. Since resize2fs was also improved (see bug #1154295) for this and we cannot be sure that the improved version is installed on the system the YaST team also decided to fix this only for Leap 15.2. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1149148 http://bugzilla.suse.com/show_bug.cgi?id=1149148#c8 Arvin Schnell changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #8 from Arvin Schnell --- SR: https://build.opensuse.org/request/show/751053 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1149148 http://bugzilla.suse.com/show_bug.cgi?id=1149148#c10 --- Comment #10 from Kai Dupke --- Thank you all! -- You are receiving this mail because: You are on the CC list for the bug.