On Dec 9, 2016, at 9:35 PM, Eric Sandeen <sandeen@xxxxxxxxxx> wrote: > > On 12/9/16 2:29 PM, Andreas Dilger wrote: >> On Dec 8, 2016, at 10:40 PM, Simon Matthews <simon.d.matthews@xxxxxxxxx> wrote: >>> >>> I have an ext3 filesystem that will not mount under newer versions of >>> the kernel and I hope someone here can help. >>> >>> Obviously, one solution is "backup and re-create from scratch". I have >>> the backups, but I hope that there may be a quicker method to fix the >>> issues. >>> >>> The root issue is that the filesystem is very slightly smaller than >>> the allocated space. > > So the device is now smaller than the filesystem thinks, right? > >> The filesystem exists on a MDRAID device and I >>> think that when I converted the MDRAID to a newer metadata version, it >>> truncated the available size, slightly. However, how I got here isn't >>> really important, fixing it now is. >> >> Running "e2fsck -fy" should fix this. I'd recommend to use the latest >> version of e2fsck. > > Reaslly? e2fsck can change total blocks in the superblock to accomodate a > shrunken device? That's a new one for me... Strange, I thought this case was handled properly by e2fsck. You could probably fix this with: # debugfs -R "ssv blocks_count 693359326" /dev/md5 # e2fsck -f /dev/md5 to set the blocks count. It is unlikely anything is in the last 18 blocks of the filesystem, and if it is then it is probably already corrupted by the RAID superblock stored there. > > I don't think so: > > $ truncate --size=101m testfile > $ mkfs.ext3 testfile > $ truncate --size=100m testfile > $ e2fsck -f testfile > ... > The physical size of the device is 102400 blocks > Either the superblock or the partition table is likely to be corrupt! > Abort<y>? n > ... > $ e2fsck -f testfile > ... > The physical size of the device is 102400 blocks > Either the superblock or the partition table is likely to be corrupt! > Abort<y>? n > $ e2fsck -f testfile > ... > The physical size of the device is 102400 blocks > Either the superblock or the partition table is likely to be corrupt! > Abort<y>? n > > etc. > > > The proper solution is to fix your block device, not the filesystem; > it was the block device which was inappropriately shortened. This may be more easily said than done... > I don't know if just poking a smaller total blocks number into the > superblock via debugfs would be safe or not. It would probably be better to have e2fsck fix this problem itself, but it is uncommon enough that there is a danger someone will also shoot themselves in the foot for cases where this isn't working right. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
