I have upgraded a file system from EXT4 to XFS. When I log onto the server the EXT4 file system utilization information is displayed however the XFS file system information is not.
How do I correct this so that the XFS file system information is also displayed.
Ubuntu 20.04
Does Ubuntu Server 18.04 support XFS for the root filesystem? The Ubuntu wiki says
GRUB-Support is in an early stage, therefore using xfs as boot-filesystem can be a bad idea
I plan to use a separate 1GB ext4 partition for /boot. Since all other filesystems are mounted on the root filesystem, will an XFS root affect grub?
While trying to recover my ec2 instance, I noticed I could not mount the root volume of that instance on other machine without generating a new UUID using
xfs_admin -U generate /dev/xdfg.
(This is due to a the system saying it couldn't mount the drive due to having a duplicate UUID, I still don't know why it said that)
This allowed me to access the volume. However, when attempting to mount it back and boot on the original ec2 instance the boot fails and produced a
unknown filesystem error and prompted to use grub rescue.
To resolve this, I mounted the drive back on the secondary machine and changed its UUID back to it's original, luckily I had it in my console history.
xfs_admin -U xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx /dev/xdfg
This allowed me to boot back into the machine.
Question
So for the sake of curiosity what about the UUID prevents the system to boot? When mounted on a separate machine with both UUID, the system knew that the filesystem was xfs.
We are facing a problem with a ceph osd node which uses an XFS file system.
The mount has become non-writeable. It gives the following error:
root@fab-prod-ceph-h3:/var/lib/ceph/osd/ceph-6# touch hrushi
touch: cannot touch `hrushi': No space left on device
Both, df -i and df -h, indicate a consumption of about ~40%.
Here is the output:
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda2 178921472 60895 178860577 1% /
udev 8240393 597 8239796 1% /dev
tmpfs 8242709 582 8242127 1% /run
none 8242709 3 8242706 1% /run/lock
none 8242709 1 8242708 1% /run/shm
/dev/sdd1 73111872 25981652 47130220 36% /var/lib/ceph/osd/ceph-8
/dev/sdc1 73111872 30445183 42666689 42% /var/lib/ceph/osd/ceph-7
/dev/sde1 97530624 1913758 95616866 2% /var/lib/ceph/osd/ceph-15
/dev/sdf1 97530624 2680246 94850378 3% /var/lib/ceph/osd/ceph-16
/dev/sdg1 195206272 2206318 192999954 2% /var/lib/ceph/osd/ceph-17
/dev/sdb1 146223870 33812416 112411454 24% /var/lib/ceph/osd/ceph-6
10.100.112.53:/srv/data/Alcatraz 98304000 15954028 82349972 17% /exporter
root@fab-prod-ceph-h3:/var/lib/ceph/osd/ceph-6# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 2.7T 313G 2.2T 13% /
udev 32G 12K 32G 1% /dev
tmpfs 13G 364K 13G 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 32G 0 32G 0% /run/shm
/dev/sdd1 2.8T 1.8T 1010G 64% /var/lib/ceph/osd/ceph-8
/dev/sdc1 2.8T 1.7T 1.2T 60% /var/lib/ceph/osd/ceph-7
/dev/sde1 3.7T 158G 3.5T 5% /var/lib/ceph/osd/ceph-15
/dev/sdf1 3.7T 185G 3.5T 5% /var/lib/ceph/osd/ceph-16
/dev/sdg1 7.3T 155G 7.2T 3% /var/lib/ceph/osd/ceph-17
/dev/sdb1 2.8T 1.9T 937G 67% /var/lib/ceph/osd/ceph-6
10.100.112.53:/srv/data/Alcatraz 1.5T 901G 502G 65% /exporter
A few community forum postings suggested increasing the space allocated to save inodes.
Initial:
root@fab-prod-ceph-h3:/var/lib/ceph/osd/ceph-6# xfs_info /dev/sdb1
meta-data=/dev/sdb1 isize=2048 agcount=32, agsize=22847480 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=731119355, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=356991, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Extended
root@fab-prod-ceph-h3:/var/lib/ceph/osd/ceph-6# xfs_growfs -m 10 /var/lib/ceph/osd/ceph-6
meta-data=/dev/sdb1 isize=2048 agcount=32, agsize=22847480 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=731119355, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=356991, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
inode max percent changed from 5 to 10
root@fab-prod-ceph-h3:/var/lib/ceph/osd/ceph-6# xfs_db -f -c "sb 0" -c "p" /dev/sdb1 | grep imax_pct
imax_pct = 5
Note:
This value did not change.
How do I resolve this problem?
I have tried upgrading the kernel version from 3.5 to 3.15 as well, but without success.
I use ubuntu 16.04 (64). An additional, non-system drive is formatted in XFS. After a power failure, I decided to check it. Gparted report:
GParted 0.25.0 --enable-libparted-dmraid --enable-online-resize
Libparted 3.2
Check and repair file system (xfs) on /dev/sdd1 00:00:19 ( ERROR )
calibrate /dev/sdd1 00:00:00 ( SUCCESS )
path: /dev/sdd1 (partition)
start: 2048
end: 3907028991
size: 3907026944 (1.82 TiB)
check file system on /dev/sdd1 for errors and (if possible) fix them 00:00:19 ( SUCCESS )
xfs_repair -v /dev/sdd1 00:00:19 ( SUCCESS )
Phase 1 - find and verify superblock...
- block cache size set to 1397872 entries
Phase 2 - using internal log
- zero log...
zero_log: head block 837056 tail block 837056
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
Phase 5 - rebuild AG headers and trees...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
XFS_REPAIR Summary Mon May 21 07:32:22 2018
Phase Start End Duration
Phase 1: 05/21 07:32:03 05/21 07:32:03
Phase 2: 05/21 07:32:03 05/21 07:32:03
Phase 3: 05/21 07:32:03 05/21 07:32:13 10 seconds
Phase 4: 05/21 07:32:13 05/21 07:32:13
Phase 5: 05/21 07:32:13 05/21 07:32:13
Phase 6: 05/21 07:32:13 05/21 07:32:21 8 seconds
Phase 7: 05/21 07:32:21 05/21 07:32:21
Total run time: 18 seconds
done
grow file system to fill the partition 00:00:00 ( ERROR )
mkdir -v /tmp/gparted-zL4DeF 00:00:00 ( SUCCESS )
Created directory /tmp/gparted-zL4DeF
mount -v -t xfs /dev/sdd1 /tmp/gparted-zL4DeF 00:00:00 ( SUCCESS )
mount: /dev/sdd1 mounted on /tmp/gparted-zL4DeF.
xfs_growfs /tmp/gparted-zL4DeF 00:00:00 ( SUCCESS )
meta-data=/dev/sdd1 isize=512 agcount=4, agsize=122094592 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=1 finobt=1 spinodes=0
data = bsize=4096 blocks=488378368, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=238466, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
umount -v /tmp/gparted-zL4DeF 00:00:00 ( ERROR )
umount: /tmp/gparted-zL4DeF: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)
rmdir -v /tmp/gparted-zL4DeF 00:00:00 ( N/A )
rmdir(/tmp/gparted-zL4DeF): Device or resource busy
Why this error occurs and how to correct it?
P.S. I'm not very experienced in repairing file systems and do not fully understand the report. Please tell me if the files are damaged?