Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

[David Dal Ben]

The "XFS (md1): EXPERIMENTAL online shrink feature in use. Use at your
own risk!" alert is appearing in my syslog/on my console.  It started
after I upgraded a couple of drives to Toshiba MG09ACA18TE 18Tb
drives.

Strangely the alert appears for one drive and not the other.  There
was no configuring or setting anything up wrt the disks, just
installed them straight out of the box.

Is there a real risk?  If so, is there a way to disable the feature?

Kernel used: Linux version 5.14.15-Unraid

Syslog snippet:

Mar  6 19:59:21 tdm emhttpd: shcmd (81): mkdir -p /mnt/disk1
Mar  6 19:59:21 tdm emhttpd: shcmd (82): mount -t xfs -o noatime
/dev/md1 /mnt/disk1
Mar  6 19:59:21 tdm kernel: SGI XFS with ACLs, security attributes, no
debug enabled
Mar  6 19:59:21 tdm kernel: XFS (md1): Mounting V5 Filesystem
Mar  6 19:59:21 tdm kernel: XFS (md1): Ending clean mount
Mar  6 19:59:21 tdm emhttpd: shcmd (83): xfs_growfs /mnt/disk1
Mar  6 19:59:21 tdm kernel: xfs filesystem being mounted at /mnt/disk1
supports timestamps until 2038 (0x7fffffff)
Mar  6 19:59:21 tdm root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl
failed: No space left on device
Mar  6 19:59:21 tdm root: meta-data=/dev/md1               isize=512
 agcount=32, agsize=137330687 blks
Mar  6 19:59:21 tdm root:          =                       sectsz=512
 attr=2, projid32bit=1
Mar  6 19:59:21 tdm root:          =                       crc=1
 finobt=1, sparse=1, rmapbt=0
Mar  6 19:59:21 tdm root:          =                       reflink=1
 bigtime=0 inobtcount=0
Mar  6 19:59:21 tdm root: data     =                       bsize=4096
 blocks=4394581984, imaxpct=5
Mar  6 19:59:21 tdm root:          =                       sunit=1
 swidth=32 blks
Mar  6 19:59:21 tdm root: naming   =version 2              bsize=4096
 ascii-ci=0, ftype=1
Mar  6 19:59:21 tdm root: log      =internal log           bsize=4096
 blocks=521728, version=2
Mar  6 19:59:21 tdm root:          =                       sectsz=512
 sunit=1 blks, lazy-count=1
Mar  6 19:59:21 tdm root: realtime =none                   extsz=4096
 blocks=0, rtextents=0
Mar  6 19:59:21 tdm emhttpd: shcmd (83): exit status: 1
Mar  6 19:59:21 tdm emhttpd: shcmd (84): mkdir -p /mnt/disk2
Mar  6 19:59:21 tdm kernel: XFS (md1): EXPERIMENTAL online shrink
feature in use. Use at your own risk!
Mar  6 19:59:21 tdm emhttpd: shcmd (85): mount -t xfs -o noatime
/dev/md2 /mnt/disk2
Mar  6 19:59:21 tdm kernel: XFS (md2): Mounting V5 Filesystem
Mar  6 19:59:22 tdm kernel: XFS (md2): Ending clean mount
Mar  6 19:59:22 tdm kernel: xfs filesystem being mounted at /mnt/disk2
supports timestamps until 2038 (0x7fffffff)
Mar  6 19:59:22 tdm emhttpd: shcmd (86): xfs_growfs /mnt/disk2
Mar  6 19:59:22 tdm root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl
failed: No space left on device
Mar  6 19:59:22 tdm root: meta-data=/dev/md2               isize=512
 agcount=32, agsize=137330687 blks
Mar  6 19:59:22 tdm root:          =                       sectsz=512
 attr=2, projid32bit=1
Mar  6 19:59:22 tdm root:          =                       crc=1
 finobt=1, sparse=1, rmapbt=0
Mar  6 19:59:22 tdm root:          =                       reflink=1
 bigtime=0 inobtcount=0
Mar  6 19:59:22 tdm root: data     =                       bsize=4096
 blocks=4394581984, imaxpct=5
Mar  6 19:59:22 tdm root:          =                       sunit=1
 swidth=32 blks
Mar  6 19:59:22 tdm root: naming   =version 2              bsize=4096
 ascii-ci=0, ftype=1
Mar  6 19:59:22 tdm root: log      =internal log           bsize=4096
 blocks=521728, version=2
Mar  6 19:59:22 tdm root:          =                       sectsz=512
 sunit=1 blks, lazy-count=1
Mar  6 19:59:22 tdm root: realtime =none                   extsz=4096
 blocks=0, rtextents=0
Mar  6 19:59:22 tdm emhttpd: shcmd (86): exit status: 1

Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

[Gao Xiang]

Hi,

On Mon, Mar 07, 2022 at 08:19:11PM +0800, David Dal Ben wrote:
> The "XFS (md1): EXPERIMENTAL online shrink feature in use. Use at your
> own risk!" alert is appearing in my syslog/on my console.  It started
> after I upgraded a couple of drives to Toshiba MG09ACA18TE 18Tb
> drives.
> 
> Strangely the alert appears for one drive and not the other.  There
> was no configuring or setting anything up wrt the disks, just
> installed them straight out of the box.
> 
> Is there a real risk?  If so, is there a way to disable the feature?
> 
> Kernel used: Linux version 5.14.15-Unraid
> 
> Syslog snippet:
> 
> Mar  6 19:59:21 tdm emhttpd: shcmd (81): mkdir -p /mnt/disk1
> Mar  6 19:59:21 tdm emhttpd: shcmd (82): mount -t xfs -o noatime
> /dev/md1 /mnt/disk1
> Mar  6 19:59:21 tdm kernel: SGI XFS with ACLs, security attributes, no
> debug enabled
> Mar  6 19:59:21 tdm kernel: XFS (md1): Mounting V5 Filesystem
> Mar  6 19:59:21 tdm kernel: XFS (md1): Ending clean mount
> Mar  6 19:59:21 tdm emhttpd: shcmd (83): xfs_growfs /mnt/disk1
> Mar  6 19:59:21 tdm kernel: xfs filesystem being mounted at /mnt/disk1
> supports timestamps until 2038 (0x7fffffff)
> Mar  6 19:59:21 tdm root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl
> failed: No space left on device

...

May I ask what is xfsprogs version used now?

At the first glance, it seems that some old xfsprogs is used here,
otherwise, it will show "[EXPERIMENTAL] try to shrink unused space"
message together with the kernel message as well.

I'm not sure what's sb_dblocks recorded in on-disk super block
compared with new disk sizes.

I guess the problem may be that the one new disk is larger than
sb_dblocks and the other is smaller than sb_dblocks. But if some
old xfsprogs is used, I'm still confused why old version xfsprogs
didn't block it at the userspace in advance.

Thanks,
Gao Xiang

> Mar  6 19:59:21 tdm root: meta-data=/dev/md1               isize=512
>  agcount=32, agsize=137330687 blks
> Mar  6 19:59:21 tdm root:          =                       sectsz=512
>  attr=2, projid32bit=1
> Mar  6 19:59:21 tdm root:          =                       crc=1
>  finobt=1, sparse=1, rmapbt=0
> Mar  6 19:59:21 tdm root:          =                       reflink=1
>  bigtime=0 inobtcount=0
> Mar  6 19:59:21 tdm root: data     =                       bsize=4096
>  blocks=4394581984, imaxpct=5
> Mar  6 19:59:21 tdm root:          =                       sunit=1
>  swidth=32 blks
> Mar  6 19:59:21 tdm root: naming   =version 2              bsize=4096
>  ascii-ci=0, ftype=1
> Mar  6 19:59:21 tdm root: log      =internal log           bsize=4096
>  blocks=521728, version=2
> Mar  6 19:59:21 tdm root:          =                       sectsz=512
>  sunit=1 blks, lazy-count=1
> Mar  6 19:59:21 tdm root: realtime =none                   extsz=4096
>  blocks=0, rtextents=0
> Mar  6 19:59:21 tdm emhttpd: shcmd (83): exit status: 1
> Mar  6 19:59:21 tdm emhttpd: shcmd (84): mkdir -p /mnt/disk2
> Mar  6 19:59:21 tdm kernel: XFS (md1): EXPERIMENTAL online shrink
> feature in use. Use at your own risk!
> Mar  6 19:59:21 tdm emhttpd: shcmd (85): mount -t xfs -o noatime
> /dev/md2 /mnt/disk2
> Mar  6 19:59:21 tdm kernel: XFS (md2): Mounting V5 Filesystem
> Mar  6 19:59:22 tdm kernel: XFS (md2): Ending clean mount
> Mar  6 19:59:22 tdm kernel: xfs filesystem being mounted at /mnt/disk2
> supports timestamps until 2038 (0x7fffffff)
> Mar  6 19:59:22 tdm emhttpd: shcmd (86): xfs_growfs /mnt/disk2
> Mar  6 19:59:22 tdm root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl
> failed: No space left on device


> Mar  6 19:59:22 tdm root: meta-data=/dev/md2               isize=512
>  agcount=32, agsize=137330687 blks
> Mar  6 19:59:22 tdm root:          =                       sectsz=512
>  attr=2, projid32bit=1
> Mar  6 19:59:22 tdm root:          =                       crc=1
>  finobt=1, sparse=1, rmapbt=0
> Mar  6 19:59:22 tdm root:          =                       reflink=1
>  bigtime=0 inobtcount=0
> Mar  6 19:59:22 tdm root: data     =                       bsize=4096
>  blocks=4394581984, imaxpct=5
> Mar  6 19:59:22 tdm root:          =                       sunit=1
>  swidth=32 blks
> Mar  6 19:59:22 tdm root: naming   =version 2              bsize=4096
>  ascii-ci=0, ftype=1
> Mar  6 19:59:22 tdm root: log      =internal log           bsize=4096
>  blocks=521728, version=2
> Mar  6 19:59:22 tdm root:          =                       sectsz=512
>  sunit=1 blks, lazy-count=1
> Mar  6 19:59:22 tdm root: realtime =none                   extsz=4096
>  blocks=0, rtextents=0
> Mar  6 19:59:22 tdm emhttpd: shcmd (86): exit status: 1

Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

[David Dal Ben]

xfs_repair version 5.13.0

Some background.  File system was 24Tb,  Expanded out to 52Tb then
back down 40Tb where it is now after migration data to the new disks.
Both 18Tb disks were added to the array at the same time.

Not sure how much more info I can give you as I'm relaying info
between Unraid techs and you.  My main concern is whether I do have
any real risk at the moment.

On Mon, 7 Mar 2022 at 21:27, Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
> Hi,
>
> On Mon, Mar 07, 2022 at 08:19:11PM +0800, David Dal Ben wrote:
> > The "XFS (md1): EXPERIMENTAL online shrink feature in use. Use at your
> > own risk!" alert is appearing in my syslog/on my console.  It started
> > after I upgraded a couple of drives to Toshiba MG09ACA18TE 18Tb
> > drives.
> >
> > Strangely the alert appears for one drive and not the other.  There
> > was no configuring or setting anything up wrt the disks, just
> > installed them straight out of the box.
> >
> > Is there a real risk?  If so, is there a way to disable the feature?
> >
> > Kernel used: Linux version 5.14.15-Unraid
> >
> > Syslog snippet:
> >
> > Mar  6 19:59:21 tdm emhttpd: shcmd (81): mkdir -p /mnt/disk1
> > Mar  6 19:59:21 tdm emhttpd: shcmd (82): mount -t xfs -o noatime
> > /dev/md1 /mnt/disk1
> > Mar  6 19:59:21 tdm kernel: SGI XFS with ACLs, security attributes, no
> > debug enabled
> > Mar  6 19:59:21 tdm kernel: XFS (md1): Mounting V5 Filesystem
> > Mar  6 19:59:21 tdm kernel: XFS (md1): Ending clean mount
> > Mar  6 19:59:21 tdm emhttpd: shcmd (83): xfs_growfs /mnt/disk1
> > Mar  6 19:59:21 tdm kernel: xfs filesystem being mounted at /mnt/disk1
> > supports timestamps until 2038 (0x7fffffff)
> > Mar  6 19:59:21 tdm root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl
> > failed: No space left on device
>
> ...
>
> May I ask what is xfsprogs version used now?
>
> At the first glance, it seems that some old xfsprogs is used here,
> otherwise, it will show "[EXPERIMENTAL] try to shrink unused space"
> message together with the kernel message as well.
>
> I'm not sure what's sb_dblocks recorded in on-disk super block
> compared with new disk sizes.
>
> I guess the problem may be that the one new disk is larger than
> sb_dblocks and the other is smaller than sb_dblocks. But if some
> old xfsprogs is used, I'm still confused why old version xfsprogs
> didn't block it at the userspace in advance.
>
> Thanks,
> Gao Xiang
>
> > Mar  6 19:59:21 tdm root: meta-data=/dev/md1               isize=512
> >  agcount=32, agsize=137330687 blks
> > Mar  6 19:59:21 tdm root:          =                       sectsz=512
> >  attr=2, projid32bit=1
> > Mar  6 19:59:21 tdm root:          =                       crc=1
> >  finobt=1, sparse=1, rmapbt=0
> > Mar  6 19:59:21 tdm root:          =                       reflink=1
> >  bigtime=0 inobtcount=0
> > Mar  6 19:59:21 tdm root: data     =                       bsize=4096
> >  blocks=4394581984, imaxpct=5
> > Mar  6 19:59:21 tdm root:          =                       sunit=1
> >  swidth=32 blks
> > Mar  6 19:59:21 tdm root: naming   =version 2              bsize=4096
> >  ascii-ci=0, ftype=1
> > Mar  6 19:59:21 tdm root: log      =internal log           bsize=4096
> >  blocks=521728, version=2
> > Mar  6 19:59:21 tdm root:          =                       sectsz=512
> >  sunit=1 blks, lazy-count=1
> > Mar  6 19:59:21 tdm root: realtime =none                   extsz=4096
> >  blocks=0, rtextents=0
> > Mar  6 19:59:21 tdm emhttpd: shcmd (83): exit status: 1
> > Mar  6 19:59:21 tdm emhttpd: shcmd (84): mkdir -p /mnt/disk2
> > Mar  6 19:59:21 tdm kernel: XFS (md1): EXPERIMENTAL online shrink
> > feature in use. Use at your own risk!
> > Mar  6 19:59:21 tdm emhttpd: shcmd (85): mount -t xfs -o noatime
> > /dev/md2 /mnt/disk2
> > Mar  6 19:59:21 tdm kernel: XFS (md2): Mounting V5 Filesystem
> > Mar  6 19:59:22 tdm kernel: XFS (md2): Ending clean mount
> > Mar  6 19:59:22 tdm kernel: xfs filesystem being mounted at /mnt/disk2
> > supports timestamps until 2038 (0x7fffffff)
> > Mar  6 19:59:22 tdm emhttpd: shcmd (86): xfs_growfs /mnt/disk2
> > Mar  6 19:59:22 tdm root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl
> > failed: No space left on device
>
>
> > Mar  6 19:59:22 tdm root: meta-data=/dev/md2               isize=512
> >  agcount=32, agsize=137330687 blks
> > Mar  6 19:59:22 tdm root:          =                       sectsz=512
> >  attr=2, projid32bit=1
> > Mar  6 19:59:22 tdm root:          =                       crc=1
> >  finobt=1, sparse=1, rmapbt=0
> > Mar  6 19:59:22 tdm root:          =                       reflink=1
> >  bigtime=0 inobtcount=0
> > Mar  6 19:59:22 tdm root: data     =                       bsize=4096
> >  blocks=4394581984, imaxpct=5
> > Mar  6 19:59:22 tdm root:          =                       sunit=1
> >  swidth=32 blks
> > Mar  6 19:59:22 tdm root: naming   =version 2              bsize=4096
> >  ascii-ci=0, ftype=1
> > Mar  6 19:59:22 tdm root: log      =internal log           bsize=4096
> >  blocks=521728, version=2
> > Mar  6 19:59:22 tdm root:          =                       sectsz=512
> >  sunit=1 blks, lazy-count=1
> > Mar  6 19:59:22 tdm root: realtime =none                   extsz=4096
> >  blocks=0, rtextents=0
> > Mar  6 19:59:22 tdm emhttpd: shcmd (86): exit status: 1

Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

[Eric Sandeen]

On 3/7/22 9:16 AM, David Dal Ben wrote:
> xfs_repair version 5.13.0
> 
> Some background.  File system was 24Tb,  Expanded out to 52Tb then
> back down 40Tb where it is now after migration data to the new disks.
> Both 18Tb disks were added to the array at the same time.

So, xfs_growfs has historically been unable to shrink the filesystem at
all. Thanks to Gao's work, it can be shrunk but only in very unique cases,
i.e. the case where there is no data or metadata located in the space
that would be removed at the end of the filesystem.  More complete
functionality remains unimplemented.

So to be clear, did you did you actually shrink the underlying device size?

And/or did you issue an "xfs_growfs" command with a size smaller than the
current size?

If you shrunk the block device without successfully shrinking the filesystem
first, then you have a corrupted filesystem and lost data, I'm afraid.  

But AFAIK xfs_growfs should have failed gracefully, and your filesystem
should be the same size as before, and should still be consistent, as long
as the actual storage was not reduced.

The concern is re: whether you shrunk the storage.

What was the actual sequence of commands you issued?

-Eric


> Not sure how much more info I can give you as I'm relaying info
> between Unraid techs and you.  My main concern is whether I do have
> any real risk at the moment.




> On Mon, 7 Mar 2022 at 21:27, Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>> Hi,
>>
>> On Mon, Mar 07, 2022 at 08:19:11PM +0800, David Dal Ben wrote:
>>> The "XFS (md1): EXPERIMENTAL online shrink feature in use. Use at your
>>> own risk!" alert is appearing in my syslog/on my console.  It started
>>> after I upgraded a couple of drives to Toshiba MG09ACA18TE 18Tb
>>> drives.
>>>
>>> Strangely the alert appears for one drive and not the other.  There
>>> was no configuring or setting anything up wrt the disks, just
>>> installed them straight out of the box.
>>>
>>> Is there a real risk?  If so, is there a way to disable the feature?
>>>
>>> Kernel used: Linux version 5.14.15-Unraid
>>>
>>> Syslog snippet:
>>>
>>> Mar  6 19:59:21 tdm emhttpd: shcmd (81): mkdir -p /mnt/disk1
>>> Mar  6 19:59:21 tdm emhttpd: shcmd (82): mount -t xfs -o noatime
>>> /dev/md1 /mnt/disk1
>>> Mar  6 19:59:21 tdm kernel: SGI XFS with ACLs, security attributes, no
>>> debug enabled
>>> Mar  6 19:59:21 tdm kernel: XFS (md1): Mounting V5 Filesystem
>>> Mar  6 19:59:21 tdm kernel: XFS (md1): Ending clean mount
>>> Mar  6 19:59:21 tdm emhttpd: shcmd (83): xfs_growfs /mnt/disk1
>>> Mar  6 19:59:21 tdm kernel: xfs filesystem being mounted at /mnt/disk1
>>> supports timestamps until 2038 (0x7fffffff)
>>> Mar  6 19:59:21 tdm root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl
>>> failed: No space left on device
>>
>> ...
>>
>> May I ask what is xfsprogs version used now?
>>
>> At the first glance, it seems that some old xfsprogs is used here,
>> otherwise, it will show "[EXPERIMENTAL] try to shrink unused space"
>> message together with the kernel message as well.
>>
>> I'm not sure what's sb_dblocks recorded in on-disk super block
>> compared with new disk sizes.
>>
>> I guess the problem may be that the one new disk is larger than
>> sb_dblocks and the other is smaller than sb_dblocks. But if some
>> old xfsprogs is used, I'm still confused why old version xfsprogs
>> didn't block it at the userspace in advance.
>>
>> Thanks,
>> Gao Xiang
>>
>>> Mar  6 19:59:21 tdm root: meta-data=/dev/md1               isize=512
>>>  agcount=32, agsize=137330687 blks
>>> Mar  6 19:59:21 tdm root:          =                       sectsz=512
>>>  attr=2, projid32bit=1
>>> Mar  6 19:59:21 tdm root:          =                       crc=1
>>>  finobt=1, sparse=1, rmapbt=0
>>> Mar  6 19:59:21 tdm root:          =                       reflink=1
>>>  bigtime=0 inobtcount=0
>>> Mar  6 19:59:21 tdm root: data     =                       bsize=4096
>>>  blocks=4394581984, imaxpct=5
>>> Mar  6 19:59:21 tdm root:          =                       sunit=1
>>>  swidth=32 blks
>>> Mar  6 19:59:21 tdm root: naming   =version 2              bsize=4096
>>>  ascii-ci=0, ftype=1
>>> Mar  6 19:59:21 tdm root: log      =internal log           bsize=4096
>>>  blocks=521728, version=2
>>> Mar  6 19:59:21 tdm root:          =                       sectsz=512
>>>  sunit=1 blks, lazy-count=1
>>> Mar  6 19:59:21 tdm root: realtime =none                   extsz=4096
>>>  blocks=0, rtextents=0
>>> Mar  6 19:59:21 tdm emhttpd: shcmd (83): exit status: 1
>>> Mar  6 19:59:21 tdm emhttpd: shcmd (84): mkdir -p /mnt/disk2
>>> Mar  6 19:59:21 tdm kernel: XFS (md1): EXPERIMENTAL online shrink
>>> feature in use. Use at your own risk!
>>> Mar  6 19:59:21 tdm emhttpd: shcmd (85): mount -t xfs -o noatime
>>> /dev/md2 /mnt/disk2
>>> Mar  6 19:59:21 tdm kernel: XFS (md2): Mounting V5 Filesystem
>>> Mar  6 19:59:22 tdm kernel: XFS (md2): Ending clean mount
>>> Mar  6 19:59:22 tdm kernel: xfs filesystem being mounted at /mnt/disk2
>>> supports timestamps until 2038 (0x7fffffff)
>>> Mar  6 19:59:22 tdm emhttpd: shcmd (86): xfs_growfs /mnt/disk2
>>> Mar  6 19:59:22 tdm root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl
>>> failed: No space left on device
>>
>>
>>> Mar  6 19:59:22 tdm root: meta-data=/dev/md2               isize=512
>>>  agcount=32, agsize=137330687 blks
>>> Mar  6 19:59:22 tdm root:          =                       sectsz=512
>>>  attr=2, projid32bit=1
>>> Mar  6 19:59:22 tdm root:          =                       crc=1
>>>  finobt=1, sparse=1, rmapbt=0
>>> Mar  6 19:59:22 tdm root:          =                       reflink=1
>>>  bigtime=0 inobtcount=0
>>> Mar  6 19:59:22 tdm root: data     =                       bsize=4096
>>>  blocks=4394581984, imaxpct=5
>>> Mar  6 19:59:22 tdm root:          =                       sunit=1
>>>  swidth=32 blks
>>> Mar  6 19:59:22 tdm root: naming   =version 2              bsize=4096
>>>  ascii-ci=0, ftype=1
>>> Mar  6 19:59:22 tdm root: log      =internal log           bsize=4096
>>>  blocks=521728, version=2
>>> Mar  6 19:59:22 tdm root:          =                       sectsz=512
>>>  sunit=1 blks, lazy-count=1
>>> Mar  6 19:59:22 tdm root: realtime =none                   extsz=4096
>>>  blocks=0, rtextents=0
>>> Mar  6 19:59:22 tdm emhttpd: shcmd (86): exit status: 1
> 
> 

Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

[David Dal Ben]

This is where I get out of my depth. I added the drives to unraid, it
asked if I wanted to format them, I said yes, when that was completed
I started migrating data.

I didn't enter any XFS or disk commands from the CLI.

What I can tell you is that there are a couple of others who have
reported this alert on the Unraid forums, all seem to have larger
disks, over 14tb.


On Mon, 7 Mar 2022 at 23:29, Eric Sandeen <esandeen@redhat.com> wrote:
>
> On 3/7/22 9:16 AM, David Dal Ben wrote:
> > xfs_repair version 5.13.0
> >
> > Some background.  File system was 24Tb,  Expanded out to 52Tb then
> > back down 40Tb where it is now after migration data to the new disks.
> > Both 18Tb disks were added to the array at the same time.
>
> So, xfs_growfs has historically been unable to shrink the filesystem at
> all. Thanks to Gao's work, it can be shrunk but only in very unique cases,
> i.e. the case where there is no data or metadata located in the space
> that would be removed at the end of the filesystem.  More complete
> functionality remains unimplemented.
>
> So to be clear, did you did you actually shrink the underlying device size?
>
> And/or did you issue an "xfs_growfs" command with a size smaller than the
> current size?
>
> If you shrunk the block device without successfully shrinking the filesystem
> first, then you have a corrupted filesystem and lost data, I'm afraid.
>
> But AFAIK xfs_growfs should have failed gracefully, and your filesystem
> should be the same size as before, and should still be consistent, as long
> as the actual storage was not reduced.
>
> The concern is re: whether you shrunk the storage.
>
> What was the actual sequence of commands you issued?
>
> -Eric
>
>
> > Not sure how much more info I can give you as I'm relaying info
> > between Unraid techs and you.  My main concern is whether I do have
> > any real risk at the moment.
>
>
>
>
> > On Mon, 7 Mar 2022 at 21:27, Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >>
> >> Hi,
> >>
> >> On Mon, Mar 07, 2022 at 08:19:11PM +0800, David Dal Ben wrote:
> >>> The "XFS (md1): EXPERIMENTAL online shrink feature in use. Use at your
> >>> own risk!" alert is appearing in my syslog/on my console.  It started
> >>> after I upgraded a couple of drives to Toshiba MG09ACA18TE 18Tb
> >>> drives.
> >>>
> >>> Strangely the alert appears for one drive and not the other.  There
> >>> was no configuring or setting anything up wrt the disks, just
> >>> installed them straight out of the box.
> >>>
> >>> Is there a real risk?  If so, is there a way to disable the feature?
> >>>
> >>> Kernel used: Linux version 5.14.15-Unraid
> >>>
> >>> Syslog snippet:
> >>>
> >>> Mar  6 19:59:21 tdm emhttpd: shcmd (81): mkdir -p /mnt/disk1
> >>> Mar  6 19:59:21 tdm emhttpd: shcmd (82): mount -t xfs -o noatime
> >>> /dev/md1 /mnt/disk1
> >>> Mar  6 19:59:21 tdm kernel: SGI XFS with ACLs, security attributes, no
> >>> debug enabled
> >>> Mar  6 19:59:21 tdm kernel: XFS (md1): Mounting V5 Filesystem
> >>> Mar  6 19:59:21 tdm kernel: XFS (md1): Ending clean mount
> >>> Mar  6 19:59:21 tdm emhttpd: shcmd (83): xfs_growfs /mnt/disk1
> >>> Mar  6 19:59:21 tdm kernel: xfs filesystem being mounted at /mnt/disk1
> >>> supports timestamps until 2038 (0x7fffffff)
> >>> Mar  6 19:59:21 tdm root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl
> >>> failed: No space left on device
> >>
> >> ...
> >>
> >> May I ask what is xfsprogs version used now?
> >>
> >> At the first glance, it seems that some old xfsprogs is used here,
> >> otherwise, it will show "[EXPERIMENTAL] try to shrink unused space"
> >> message together with the kernel message as well.
> >>
> >> I'm not sure what's sb_dblocks recorded in on-disk super block
> >> compared with new disk sizes.
> >>
> >> I guess the problem may be that the one new disk is larger than
> >> sb_dblocks and the other is smaller than sb_dblocks. But if some
> >> old xfsprogs is used, I'm still confused why old version xfsprogs
> >> didn't block it at the userspace in advance.
> >>
> >> Thanks,
> >> Gao Xiang
> >>
> >>> Mar  6 19:59:21 tdm root: meta-data=/dev/md1               isize=512
> >>>  agcount=32, agsize=137330687 blks
> >>> Mar  6 19:59:21 tdm root:          =                       sectsz=512
> >>>  attr=2, projid32bit=1
> >>> Mar  6 19:59:21 tdm root:          =                       crc=1
> >>>  finobt=1, sparse=1, rmapbt=0
> >>> Mar  6 19:59:21 tdm root:          =                       reflink=1
> >>>  bigtime=0 inobtcount=0
> >>> Mar  6 19:59:21 tdm root: data     =                       bsize=4096
> >>>  blocks=4394581984, imaxpct=5
> >>> Mar  6 19:59:21 tdm root:          =                       sunit=1
> >>>  swidth=32 blks
> >>> Mar  6 19:59:21 tdm root: naming   =version 2              bsize=4096
> >>>  ascii-ci=0, ftype=1
> >>> Mar  6 19:59:21 tdm root: log      =internal log           bsize=4096
> >>>  blocks=521728, version=2
> >>> Mar  6 19:59:21 tdm root:          =                       sectsz=512
> >>>  sunit=1 blks, lazy-count=1
> >>> Mar  6 19:59:21 tdm root: realtime =none                   extsz=4096
> >>>  blocks=0, rtextents=0
> >>> Mar  6 19:59:21 tdm emhttpd: shcmd (83): exit status: 1
> >>> Mar  6 19:59:21 tdm emhttpd: shcmd (84): mkdir -p /mnt/disk2
> >>> Mar  6 19:59:21 tdm kernel: XFS (md1): EXPERIMENTAL online shrink
> >>> feature in use. Use at your own risk!
> >>> Mar  6 19:59:21 tdm emhttpd: shcmd (85): mount -t xfs -o noatime
> >>> /dev/md2 /mnt/disk2
> >>> Mar  6 19:59:21 tdm kernel: XFS (md2): Mounting V5 Filesystem
> >>> Mar  6 19:59:22 tdm kernel: XFS (md2): Ending clean mount
> >>> Mar  6 19:59:22 tdm kernel: xfs filesystem being mounted at /mnt/disk2
> >>> supports timestamps until 2038 (0x7fffffff)
> >>> Mar  6 19:59:22 tdm emhttpd: shcmd (86): xfs_growfs /mnt/disk2
> >>> Mar  6 19:59:22 tdm root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl
> >>> failed: No space left on device
> >>
> >>
> >>> Mar  6 19:59:22 tdm root: meta-data=/dev/md2               isize=512
> >>>  agcount=32, agsize=137330687 blks
> >>> Mar  6 19:59:22 tdm root:          =                       sectsz=512
> >>>  attr=2, projid32bit=1
> >>> Mar  6 19:59:22 tdm root:          =                       crc=1
> >>>  finobt=1, sparse=1, rmapbt=0
> >>> Mar  6 19:59:22 tdm root:          =                       reflink=1
> >>>  bigtime=0 inobtcount=0
> >>> Mar  6 19:59:22 tdm root: data     =                       bsize=4096
> >>>  blocks=4394581984, imaxpct=5
> >>> Mar  6 19:59:22 tdm root:          =                       sunit=1
> >>>  swidth=32 blks
> >>> Mar  6 19:59:22 tdm root: naming   =version 2              bsize=4096
> >>>  ascii-ci=0, ftype=1
> >>> Mar  6 19:59:22 tdm root: log      =internal log           bsize=4096
> >>>  blocks=521728, version=2
> >>> Mar  6 19:59:22 tdm root:          =                       sectsz=512
> >>>  sunit=1 blks, lazy-count=1
> >>> Mar  6 19:59:22 tdm root: realtime =none                   extsz=4096
> >>>  blocks=0, rtextents=0
> >>> Mar  6 19:59:22 tdm emhttpd: shcmd (86): exit status: 1
> >
> >
>

Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

[Dave Chinner]

On Tue, Mar 08, 2022 at 06:46:58AM +0800, David Dal Ben wrote:
> This is where I get out of my depth. I added the drives to unraid, it
> asked if I wanted to format them, I said yes, when that was completed
> I started migrating data.
> 
> I didn't enter any XFS or disk commands from the CLI.

Is there any sort of verbose logging you can turn on from the
applicance web interface?

> 
> What I can tell you is that there are a couple of others who have
> reported this alert on the Unraid forums, all seem to have larger
> disks, over 14tb.

I'd suggest that you ask Unraid to turn off XFS shrinking support in
the 6.10 release. It's not ready for production release, and
enabling it is just going to lead to user problems like this.

Indeed, this somewhat implies that Unraid haven't actually tested
shrink functionality at all, because otherwise the would have
noticed just how limited the current XFS shrink support is and
understood that it simply cannot be used in a production environment
yet.

IOWs, if Unraid want to support shrink in their commercial products
right now, their support engineers need to be testing, triaging and
reporting shrink problems to upstream and telling us exactly what is
triggering those issues. Whilst the operations and commands they are
issuing remains hidden from Unraid users, there's not a huge amount
we can do upstream to triage the issue...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

[Gao Xiang]

On Tue, Mar 08, 2022 at 10:31:32AM +1100, Dave Chinner wrote:
> On Tue, Mar 08, 2022 at 06:46:58AM +0800, David Dal Ben wrote:
> > This is where I get out of my depth. I added the drives to unraid, it
> > asked if I wanted to format them, I said yes, when that was completed
> > I started migrating data.
> > 
> > I didn't enter any XFS or disk commands from the CLI.
> 
> Is there any sort of verbose logging you can turn on from the
> applicance web interface?
> 
> > 
> > What I can tell you is that there are a couple of others who have
> > reported this alert on the Unraid forums, all seem to have larger
> > disks, over 14tb.
> 
> I'd suggest that you ask Unraid to turn off XFS shrinking support in
> the 6.10 release. It's not ready for production release, and
> enabling it is just going to lead to user problems like this.
> 
> Indeed, this somewhat implies that Unraid haven't actually tested
> shrink functionality at all, because otherwise the would have
> noticed just how limited the current XFS shrink support is and
> understood that it simply cannot be used in a production environment
> yet.
> 
> IOWs, if Unraid want to support shrink in their commercial products
> right now, their support engineers need to be testing, triaging and
> reporting shrink problems to upstream and telling us exactly what is
> triggering those issues. Whilst the operations and commands they are
> issuing remains hidden from Unraid users, there's not a huge amount
> we can do upstream to triage the issue...

I'm not sure if it can reproduce on other distribution or it's just a
specific behavior with unraid distribution, and it seems that this
distribution needs to be paid with $ to get more functionality, so I
assume it has a professional support team which can investigate more,
at least on the userspace side.

In the beginning, we've discussed informally if we needed to add
another "-S" option to xfs_growfs to indicate the new shrink behavior
for users. And the conclusion was unnecessary. And I think for the case
mentioned in the original thread, it didn't actually do anything.

Thanks,
Gao Xiang

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com

Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

[David Dal Ben]

OK, thanks.  I'll take this up with the Unraid tech team directly.
Thanks for the advice and pointers.

On Tue, 8 Mar 2022 at 07:51, Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
> On Tue, Mar 08, 2022 at 10:31:32AM +1100, Dave Chinner wrote:
> > On Tue, Mar 08, 2022 at 06:46:58AM +0800, David Dal Ben wrote:
> > > This is where I get out of my depth. I added the drives to unraid, it
> > > asked if I wanted to format them, I said yes, when that was completed
> > > I started migrating data.
> > >
> > > I didn't enter any XFS or disk commands from the CLI.
> >
> > Is there any sort of verbose logging you can turn on from the
> > applicance web interface?
> >
> > >
> > > What I can tell you is that there are a couple of others who have
> > > reported this alert on the Unraid forums, all seem to have larger
> > > disks, over 14tb.
> >
> > I'd suggest that you ask Unraid to turn off XFS shrinking support in
> > the 6.10 release. It's not ready for production release, and
> > enabling it is just going to lead to user problems like this.
> >
> > Indeed, this somewhat implies that Unraid haven't actually tested
> > shrink functionality at all, because otherwise the would have
> > noticed just how limited the current XFS shrink support is and
> > understood that it simply cannot be used in a production environment
> > yet.
> >
> > IOWs, if Unraid want to support shrink in their commercial products
> > right now, their support engineers need to be testing, triaging and
> > reporting shrink problems to upstream and telling us exactly what is
> > triggering those issues. Whilst the operations and commands they are
> > issuing remains hidden from Unraid users, there's not a huge amount
> > we can do upstream to triage the issue...
>
> I'm not sure if it can reproduce on other distribution or it's just a
> specific behavior with unraid distribution, and it seems that this
> distribution needs to be paid with $ to get more functionality, so I
> assume it has a professional support team which can investigate more,
> at least on the userspace side.
>
> In the beginning, we've discussed informally if we needed to add
> another "-S" option to xfs_growfs to indicate the new shrink behavior
> for users. And the conclusion was unnecessary. And I think for the case
> mentioned in the original thread, it didn't actually do anything.
>
> Thanks,
> Gao Xiang
>
> > Cheers,
> >
> > Dave.
> > --
> > Dave Chinner
> > david@fromorbit.com

Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

[Eric Sandeen]

So a weird thing here is that I think your logs show the xfs_growfs command
happening immediately after mount, and it doesn't have any size specified, 
so I can't tell if the intent was to shrink - but I don't think so:

Mar  6 19:59:21 tdm emhttpd: shcmd (81): mkdir -p /mnt/disk1
Mar  6 19:59:21 tdm emhttpd: shcmd (82): mount -t xfs -o noatime /dev/md1 /mnt/disk1
Mar  6 19:59:21 tdm kernel: SGI XFS with ACLs, security attributes, no debug enabled
Mar  6 19:59:21 tdm kernel: XFS (md1): Mounting V5 Filesystem
Mar  6 19:59:21 tdm kernel: XFS (md1): Ending clean mount
Mar  6 19:59:21 tdm emhttpd: shcmd (83): xfs_growfs /mnt/disk1
Mar  6 19:59:21 tdm kernel: xfs filesystem being mounted at /mnt/disk1 supports timestamps until 2038 (0x7fffffff)
Mar  6 19:59:21 tdm root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: No space left on device
Mar  6 19:59:21 tdm root: meta-data=/dev/md1               isize=512  agcount=32, agsize=137330687 blks
Mar  6 19:59:21 tdm root:          =                       sectsz=512  attr=2, projid32bit=1
Mar  6 19:59:21 tdm root:          =                       crc=1  finobt=1, sparse=1, rmapbt=0
Mar  6 19:59:21 tdm root:          =                       reflink=1  bigtime=0 inobtcount=0
Mar  6 19:59:21 tdm root: data     =                       bsize=4096  blocks=4394581984, imaxpct=5
Mar  6 19:59:21 tdm root:          =                       sunit=1  swidth=32 blks
Mar  6 19:59:21 tdm root: naming   =version 2              bsize=4096  ascii-ci=0, ftype=1
Mar  6 19:59:21 tdm root: log      =internal log           bsize=4096  blocks=521728, version=2
Mar  6 19:59:21 tdm root:          =                       sectsz=512  sunit=1 blks, lazy-count=1
Mar  6 19:59:21 tdm root: realtime =none                   extsz=4096  blocks=0, rtextents=0
Mar  6 19:59:21 tdm emhttpd: shcmd (83): exit status: 1
Mar  6 19:59:21 tdm kernel: XFS (md1): EXPERIMENTAL online shrink feature in use. Use at your own risk!


We issue the EXPERIMENTAL message if the block delta is <= 0 (I'm not sure why
it's done if delta == 0 and I wonder if it should instead be < 0).

But maybe unraid isn't really trying to shrink, it's just doing an unconditional
growfs post-mount to ensure it's using the whole device (unnecessary, but should
be safe.)

I'm wondering if we have some path through xfs_growfs_data_private() that calculates
a delta < 0 unintentionally, or if we get there with delta == 0 and generate the
warning message.

However, if I recreate a filesystem with exactly your geometry:
# mkfs.xfs -b size=4096 -dfile,name=fsfile,agcount=32,size=4394581984b,su=4k,sw=32  -m inobtcount=0,bigtime=0
meta-data=fsfile                 isize=512    agcount=32, agsize=137330687 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=0 inobtcount=0
data     =                       bsize=4096   blocks=4394581984, imaxpct=5
         =                       sunit=1      swidth=32 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=521728, version=2
         =                       sectsz=512   sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

and then mount it and point xfs_growfs at it with no args, I get no errors.
So I am still stumped...

-Eric

On 3/7/22 6:04 PM, David Dal Ben wrote:
> OK, thanks.  I'll take this up with the Unraid tech team directly.
> Thanks for the advice and pointers.
> 
> On Tue, 8 Mar 2022 at 07:51, Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>> On Tue, Mar 08, 2022 at 10:31:32AM +1100, Dave Chinner wrote:
>>> On Tue, Mar 08, 2022 at 06:46:58AM +0800, David Dal Ben wrote:
>>>> This is where I get out of my depth. I added the drives to unraid, it
>>>> asked if I wanted to format them, I said yes, when that was completed
>>>> I started migrating data.
>>>>
>>>> I didn't enter any XFS or disk commands from the CLI.
>>>
>>> Is there any sort of verbose logging you can turn on from the
>>> applicance web interface?
>>>
>>>>
>>>> What I can tell you is that there are a couple of others who have
>>>> reported this alert on the Unraid forums, all seem to have larger
>>>> disks, over 14tb.
>>>
>>> I'd suggest that you ask Unraid to turn off XFS shrinking support in
>>> the 6.10 release. It's not ready for production release, and
>>> enabling it is just going to lead to user problems like this.
>>>
>>> Indeed, this somewhat implies that Unraid haven't actually tested
>>> shrink functionality at all, because otherwise the would have
>>> noticed just how limited the current XFS shrink support is and
>>> understood that it simply cannot be used in a production environment
>>> yet.
>>>
>>> IOWs, if Unraid want to support shrink in their commercial products
>>> right now, their support engineers need to be testing, triaging and
>>> reporting shrink problems to upstream and telling us exactly what is
>>> triggering those issues. Whilst the operations and commands they are
>>> issuing remains hidden from Unraid users, there's not a huge amount
>>> we can do upstream to triage the issue...
>>
>> I'm not sure if it can reproduce on other distribution or it's just a
>> specific behavior with unraid distribution, and it seems that this
>> distribution needs to be paid with $ to get more functionality, so I
>> assume it has a professional support team which can investigate more,
>> at least on the userspace side.
>>
>> In the beginning, we've discussed informally if we needed to add
>> another "-S" option to xfs_growfs to indicate the new shrink behavior
>> for users. And the conclusion was unnecessary. And I think for the case
>> mentioned in the original thread, it didn't actually do anything.
>>
>> Thanks,
>> Gao Xiang
>>
>>> Cheers,
>>>
>>> Dave.
>>> --
>>> Dave Chinner
>>> david@fromorbit.com
> 

Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

[Dave Chinner]

On Wed, Mar 09, 2022 at 12:22:00PM -0600, Eric Sandeen wrote:
> So a weird thing here is that I think your logs show the xfs_growfs command
> happening immediately after mount, and it doesn't have any size specified, 
> so I can't tell if the intent was to shrink - but I don't think so:
> 
> Mar  6 19:59:21 tdm emhttpd: shcmd (81): mkdir -p /mnt/disk1
> Mar  6 19:59:21 tdm emhttpd: shcmd (82): mount -t xfs -o noatime /dev/md1 /mnt/disk1
> Mar  6 19:59:21 tdm kernel: SGI XFS with ACLs, security attributes, no debug enabled
> Mar  6 19:59:21 tdm kernel: XFS (md1): Mounting V5 Filesystem
> Mar  6 19:59:21 tdm kernel: XFS (md1): Ending clean mount
> Mar  6 19:59:21 tdm emhttpd: shcmd (83): xfs_growfs /mnt/disk1
> Mar  6 19:59:21 tdm kernel: xfs filesystem being mounted at /mnt/disk1 supports timestamps until 2038 (0x7fffffff)
> Mar  6 19:59:21 tdm root: xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: No space left on device
> Mar  6 19:59:21 tdm root: meta-data=/dev/md1               isize=512  agcount=32, agsize=137330687 blks
> Mar  6 19:59:21 tdm root:          =                       sectsz=512  attr=2, projid32bit=1
> Mar  6 19:59:21 tdm root:          =                       crc=1  finobt=1, sparse=1, rmapbt=0
> Mar  6 19:59:21 tdm root:          =                       reflink=1  bigtime=0 inobtcount=0
> Mar  6 19:59:21 tdm root: data     =                       bsize=4096  blocks=4394581984, imaxpct=5
> Mar  6 19:59:21 tdm root:          =                       sunit=1  swidth=32 blks
> Mar  6 19:59:21 tdm root: naming   =version 2              bsize=4096  ascii-ci=0, ftype=1
> Mar  6 19:59:21 tdm root: log      =internal log           bsize=4096  blocks=521728, version=2
> Mar  6 19:59:21 tdm root:          =                       sectsz=512  sunit=1 blks, lazy-count=1
> Mar  6 19:59:21 tdm root: realtime =none                   extsz=4096  blocks=0, rtextents=0
> Mar  6 19:59:21 tdm emhttpd: shcmd (83): exit status: 1
> Mar  6 19:59:21 tdm kernel: XFS (md1): EXPERIMENTAL online shrink feature in use. Use at your own risk!
> 
> 
> We issue the EXPERIMENTAL message if the block delta is <= 0 (I'm not sure why
> it's done if delta == 0 and I wonder if it should instead be < 0).

Because if the growfs size is unchanged (i.e delta will be zero), we
don't even call xfs_growfs_data_private(), so the warning will not
be emitted:

        if (in->newblocks != mp->m_sb.sb_dblocks) {
		error = xfs_growfs_data_private(mp, in);
		if (error)
			goto out_error;
	}

If it is getting ENOSPC as an error then either the filesystem is
either:

- 100% full and xfs_trans_alloc() fails (unlikely)
- it is a single AG shrink, the remaining space is not contiguous
  and so fails allocation that removes it from the free space tree:

xfs_ag_shrink_space()
...
        /* internal log shouldn't also show up in the free space btrees */
        error = xfs_alloc_vextent(&args);
        if (!error && args.agbno == NULLAGBLOCK)
                error = -ENOSPC;

- after shrink of the AG, the call to xfs_ag_resv_init() fails
  because there isn't enough free space for metadata reservations
  in that AG anymore. i.e. it will only allow freeing from the last
  AG until reservation space has been regained.

So, yeah, a single AG shrink can give ENOSPC for several reasons,
which leads me to think that the unraid device underlying the
filesystem has changed size (for whatever reason) and growfs is just
saying "you haven't emptied the space at the end of the filesystem
before you tried to shrink the fs"...

> I'm wondering if we have some path through xfs_growfs_data_private() that calculates
> a delta < 0 unintentionally, or if we get there with delta == 0 and generate the
> warning message.

Nope, we're not even getting there for the delta == 0 case...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

[Eric Sandeen]

On 3/9/22 3:19 PM, Dave Chinner wrote:
> On Wed, Mar 09, 2022 at 12:22:00PM -0600, Eric Sandeen wrote:

...

>> I'm wondering if we have some path through xfs_growfs_data_private() that calculates
>> a delta < 0 unintentionally, or if we get there with delta == 0 and generate the
>> warning message.
> 
> Nope, we're not even getting there for the delta == 0 case...

Ok, thanks - I should have checked that.

Soooo how is a no-argument xfs_growfs, with size calculated by the tool based on the
disk size, failing immediately after a mount? Makes no sense to me.

-Eric

Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert

[Dave Chinner]

On Wed, Mar 09, 2022 at 04:18:54PM -0600, Eric Sandeen wrote:
> On 3/9/22 3:19 PM, Dave Chinner wrote:
> > On Wed, Mar 09, 2022 at 12:22:00PM -0600, Eric Sandeen wrote:
> 
> ...
> 
> >> I'm wondering if we have some path through xfs_growfs_data_private() that calculates
> >> a delta < 0 unintentionally, or if we get there with delta == 0 and generate the
> >> warning message.
> > 
> > Nope, we're not even getting there for the delta == 0 case...
> 
> Ok, thanks - I should have checked that.
> 
> Soooo how is a no-argument xfs_growfs, with size calculated by the tool based on the
> disk size, failing immediately after a mount? Makes no sense to me.

Remember, unraid is an out of tree MD block device driver, so
there's every chance that XFS is just the messenger telling us that
the device driver has bugs in it's size handling or
discovery/recovery/assembly behaviour. Until we get an actual
command line reproducer for this problem on an in-tree block device,
I would not spend any more time worrying about it.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com