So I was going to resize the fileystem something I done several times
but this time something went wrong. I hit the 16GB limit and had to use
the -b flag to resize. This is the commands I used
-----
# e2fsck -C 0 -f /dev/mapper/bfd_uc
e2fsck 1.45.2 (27-May-2019)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/bfd_uc: 78660/1021870080 files (16.1% non-contiguous),
3928630907/4087464448 blocks
-----
so long everything worked.
-----
# resize2fs /dev/mapper/bfd_uc
resize2fs 1.45.2 (27-May-2019)
resize2fs: New size too large to be expressed in 32 bits
-----
ok letsa try that.
---------------
# resize2fs -b -p /dev/mapper/bfd_uc
resize2fs 1.45.2 (27-May-2019)
Converting the filesystem to 64-bit.
Begin pass 2 (max = 22287)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 124740)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 5 (max = 2)
Moving inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/mapper/bfd_uc is now 4087464448 (4k) blocks long.
resize2fs /dev/mapper/bfd_uc
resize2fs 1.45.2 (27-May-2019)
Resizing the filesystem on /dev/mapper/bfd_uc to 4355899904 (4k) blocks.
The filesystem on /dev/mapper/bfd_uc is now 4355899904 (4k) blocks long.
-----
Still no problems but when I tried to mount it the kernel refused. so I
run fsck again and now there is a lot of issues.
-----
e2fsck -C 0 -f /dev/mapper/bfd_uc
e2fsck 1.45.2 (27-May-2019)
Pass 1: Checking inodes, blocks, and sizes
Inode 29360452 extent tree (at level 1) could be narrower. Optimize<y>? yes
Inode 29360454 extent tree (at level 1) could be narrower. Optimize<y>? yes
Inode 29360456 extent tree (at level 1) could be narrower. Optimize<y>? yes
Inode 29360457 extent tree (at level 1) could be narrower. Optimize<y>? yes
Inode 29360458 extent tree (at level 1) could be narrower. Optimize<y>? yes
Inode 29360459 extent tree (at level 1) could be narrower. Optimize<y>? yes
yInode 29361103 extent tree (at level 1) could be narrower. Optimize<y>? yes
Inode 313786521 extent tree (at level 1) could be narrower. Optimize<y>?
yes
Inode 313786522 extent tree (at level 1) could be narrower. Optimize<y>? yes
Inode 400425891 extent tree (at level 1) could be narrower. Optimize
('a' enables 'yes' to all) <y>? yes to all
Inode 400427369 extent tree (at level 2) could be narrower. Optimize? yes
Inode 401735804 extent tree (at level 1) could be narrower. Optimize? yes
and so on. not sure where they came from but the real issue is that I
cant get e2fsck to complete. I eventually get lots and lots of things
like this
Inode 1021871069 block 336 conflicts with critical metadata, skipping
block checks.
the same inode is used on hundreds of lines. looks like the inode is
random data more or less. I used debugfs and clri to delete it but I
just end up in the same error on another inode and I cant solve it this
way as it is manual work.
here is parts of "debugfs stat" on another of this inodes. debugfs
enters the same loop as fsck I think as it hangs here.
-----------
Inode: 1021870344 Type: regular Mode: 04565 Flags: 0x9f6845b
Generation: 3754451681 Version: 0x0cec5d88:0cee9f57
User: 1240871040 Group: -228176346 Size: 7783179247692111229
File ACL: 87875029679583
Links: 57617 Blockcount: 203042659658940
Fragment: Address: -1951344957 Number: 0 Size: 0
ctime: 0x162ec9d3:d145c3fc -- Sat Oct 17 12:11:15 1981
atime: 0x4471cfa3:1a4a9fbf -- Thu Sep 11 12:14:59 2414
mtime: 0x2997b943:178e01cf -- Fri Jun 2 09:18:27 2400
crtime: 0x42faeff4:02752ab4 -- Thu Aug 11 08:28:04 2005
Size of extra inode fields: 28
BLOCKS:
(0):3868683678, (1):2003982397, (2):620007688, (3):4267941890,
(4):3725597703, (5):3651320496, (6):738218534, (7):2119776579,
(8):160072405, (9):4132595055, (10):1419200473, (11):772345008,
(IND):137269137, (12):4163901537, (13):344587808, (14):1106180479,
(15):3742206454, (16):1735251710, (17):709071450, (18):1481240729,79_
---------
so I need to tell fsck to just ignore any inode that has like a filesize
larger than say 50G or some reasonable value so it does not scan the
whole blody disk or whatever its doing. right now It will never finish
this disk once it hit this type of inode data and I have no idea how
much of this exists. could be alot as I added 1T to the partition and
its from lvm so it could be any data that is now added to the
partition/disk
so far I have had problems on this inode numbers
1021871069
1021871209
1021870852
1021870344
so it looks like there could be a lot of them.