On Mon, Dec 12, 2016 at 2:36 PM, Andreas Dilger <adilger@xxxxxxxxx> wrote: > 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 "probably"? How safe or dangerous is this? Does the filesystem have to be unmounted first? Simon -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
