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@xxxxxxxxxxxxxxxxx> 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 > >
