* Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert [not found] <CALwRca2+UsEZMPwiCtecM87HVVMs27SdawdWXns+PU7+S-DFaQ@mail.gmail.com> @ 2022-03-07 12:19 ` David Dal Ben 2022-03-07 13:27 ` Gao Xiang 0 siblings, 1 reply; 12+ messages in thread From: David Dal Ben @ 2022-03-07 12:19 UTC (permalink / raw) To: linux-xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert 2022-03-07 12:19 ` Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert David Dal Ben @ 2022-03-07 13:27 ` Gao Xiang 2022-03-07 15:16 ` David Dal Ben 0 siblings, 1 reply; 12+ messages in thread From: Gao Xiang @ 2022-03-07 13:27 UTC (permalink / raw) To: David Dal Ben; +Cc: linux-xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert 2022-03-07 13:27 ` Gao Xiang @ 2022-03-07 15:16 ` David Dal Ben 2022-03-07 15:29 ` Eric Sandeen 0 siblings, 1 reply; 12+ messages in thread From: David Dal Ben @ 2022-03-07 15:16 UTC (permalink / raw) To: David Dal Ben, linux-xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert 2022-03-07 15:16 ` David Dal Ben @ 2022-03-07 15:29 ` Eric Sandeen 2022-03-07 22:46 ` David Dal Ben 0 siblings, 1 reply; 12+ messages in thread From: Eric Sandeen @ 2022-03-07 15:29 UTC (permalink / raw) To: David Dal Ben, linux-xfs 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 > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert 2022-03-07 15:29 ` Eric Sandeen @ 2022-03-07 22:46 ` David Dal Ben 2022-03-07 23:31 ` Dave Chinner 0 siblings, 1 reply; 12+ messages in thread From: David Dal Ben @ 2022-03-07 22:46 UTC (permalink / raw) To: Eric Sandeen; +Cc: linux-xfs 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 > > > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert 2022-03-07 22:46 ` David Dal Ben @ 2022-03-07 23:31 ` Dave Chinner 2022-03-07 23:51 ` Gao Xiang 0 siblings, 1 reply; 12+ messages in thread From: Dave Chinner @ 2022-03-07 23:31 UTC (permalink / raw) To: David Dal Ben; +Cc: Eric Sandeen, linux-xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert 2022-03-07 23:31 ` Dave Chinner @ 2022-03-07 23:51 ` Gao Xiang 2022-03-08 0:04 ` David Dal Ben 0 siblings, 1 reply; 12+ messages in thread From: Gao Xiang @ 2022-03-07 23:51 UTC (permalink / raw) To: Dave Chinner; +Cc: David Dal Ben, Eric Sandeen, linux-xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert 2022-03-07 23:51 ` Gao Xiang @ 2022-03-08 0:04 ` David Dal Ben 2022-03-09 18:22 ` Eric Sandeen 0 siblings, 1 reply; 12+ messages in thread From: David Dal Ben @ 2022-03-08 0:04 UTC (permalink / raw) To: Dave Chinner, David Dal Ben, Eric Sandeen, linux-xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert 2022-03-08 0:04 ` David Dal Ben @ 2022-03-09 18:22 ` Eric Sandeen 2022-03-09 21:19 ` Dave Chinner 0 siblings, 1 reply; 12+ messages in thread From: Eric Sandeen @ 2022-03-09 18:22 UTC (permalink / raw) To: David Dal Ben, Dave Chinner, Eric Sandeen, linux-xfs 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert 2022-03-09 18:22 ` Eric Sandeen @ 2022-03-09 21:19 ` Dave Chinner 2022-03-09 22:18 ` Eric Sandeen 0 siblings, 1 reply; 12+ messages in thread From: Dave Chinner @ 2022-03-09 21:19 UTC (permalink / raw) To: Eric Sandeen; +Cc: David Dal Ben, Eric Sandeen, linux-xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert 2022-03-09 21:19 ` Dave Chinner @ 2022-03-09 22:18 ` Eric Sandeen 2022-03-09 22:37 ` Dave Chinner 0 siblings, 1 reply; 12+ messages in thread From: Eric Sandeen @ 2022-03-09 22:18 UTC (permalink / raw) To: Dave Chinner; +Cc: David Dal Ben, Eric Sandeen, linux-xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert 2022-03-09 22:18 ` Eric Sandeen @ 2022-03-09 22:37 ` Dave Chinner 0 siblings, 0 replies; 12+ messages in thread From: Dave Chinner @ 2022-03-09 22:37 UTC (permalink / raw) To: Eric Sandeen; +Cc: David Dal Ben, Eric Sandeen, linux-xfs 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-03-09 22:37 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CALwRca2+UsEZMPwiCtecM87HVVMs27SdawdWXns+PU7+S-DFaQ@mail.gmail.com>
2022-03-07 12:19 ` Inconsistent "EXPERIMENTAL online shrink feature in use. Use at your own risk" alert David Dal Ben
2022-03-07 13:27 ` Gao Xiang
2022-03-07 15:16 ` David Dal Ben
2022-03-07 15:29 ` Eric Sandeen
2022-03-07 22:46 ` David Dal Ben
2022-03-07 23:31 ` Dave Chinner
2022-03-07 23:51 ` Gao Xiang
2022-03-08 0:04 ` David Dal Ben
2022-03-09 18:22 ` Eric Sandeen
2022-03-09 21:19 ` Dave Chinner
2022-03-09 22:18 ` Eric Sandeen
2022-03-09 22:37 ` Dave Chinner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).