lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <55F73DAD.6020807@harvyl.se> Date: Mon, 14 Sep 2015 23:35:41 +0200 From: Johan Harvyl <johan@...vyl.se> To: Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org Subject: Re: resize2fs: Should never happen: resize inode corrupt! - lost key inodes In an attempt to further isolate what versions of e2fsprogs, at a commit level, that are needed to reproduce the bad behavior I tried my own step-by-step, initially with a much higher -i 16777216 to mkfs.ext4 in the hope that fewer inodes would make all the operations run faster. When I was unable to reproduce with -i 16777216 instead, I switched back to exactly what I reproduced with the first time, and I *still* did not get the "Should never happen: resize inode corrupt!". The only reasonable explanation I can come up with to this is that something is not being initialized properly that resize2fs expects to be initialized. I have no indications of any issues with any hardware or the underlying md block. What I did however notice is that I can have the same kind of filesystem corruption *without* seeing the "Should never happen: resize inode corrupt!" message using the following sequence, and this *is* reproducible one time after another: # MKE2FS_CONFIG=/root/e10/out/etc/mke2fs.conf /root/e10/out/sbin/mkfs.ext4 /dev/md0 -i 262144 -m 0 -O 64bit 15627548672k # e2fsck -fy /dev/md0 (using 1.42.13) # resize2fs -p /dev/md0 19534435840k (using 1.42.13) # resize2fs -p /dev/md0 (using 1.42.13) # e2fsck -fn /dev/md0 e2fsck 1.42.13 (17-May-2015) ext2fs_check_desc: Corrupt group descriptor: bad block for inode table e2fsck: Group descriptors look bad... trying backup blocks... Superblock has an invalid journal (inode 8). Clear? no e2fsck: Illegal inode number while checking ext3 journal for /dev/md0 At this point the root inode is also bad and this fails: # mount /dev/md0 /mnt/loop -o ro,noload mount: mount /dev/md0 on /mnt/loop failed: Stale file handle [3766493.732188] EXT4-fs (md0): get root inode failed [3766493.732190] EXT4-fs (md0): mount failed Note that only versions 1.42.10 and 1.42.13 are involved now, 1.42.12 is not needed. Kernel is the debian: ii linux-image-4.0.0-2-amd64 4.0.8-2 amd64 Linux 4.0 for 64-bit PCs For the record I also tried a more recent e2fsprogs for the resize (instead of 1.42.13), locally built from: 956b0f1 Merge branch 'maint' into next and I could still reproduce it on the first attempt. More verbose logs follows. Does anyone else have some kind of testbed to test the same sequence of commands? === # MKE2FS_CONFIG=/root/e10/out/etc/mke2fs.conf /root/e10/out/sbin/mkfs.ext4 /dev/md0 -i 262144 -m 0 -O 64bit 15627548672k mke2fs 1.42.10 (18-May-2014) /dev/md0 contains a ext4 file system last mounted on Sun Sep 13 22:19:28 2015 Proceed anyway? (y,n) y Creating filesystem with 3906887168 4k blocks and 61045248 inodes Filesystem UUID: e263356e-4fe4-4e9b-bd0c-8edc2c411735 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848, 512000000, 550731776, 644972544, 1934917632, 2560000000, 3855122432 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done # e2fsck -fy /dev/md0 e2fsck 1.42.13 (17-May-2015) 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 Free blocks count wrong (512088558484167, counted=3902749383). Fix? yes /dev/md0: ***** FILE SYSTEM WAS MODIFIED ***** /dev/md0: 11/61045248 files (0.0% non-contiguous), 4137785/3906887168 blocks # resize2fs -p /dev/md0 19534435840k resize2fs 1.42.13 (17-May-2015) Resizing the filesystem on /dev/md0 to 4883608960 (4k) blocks. Begin pass 2 (max = 6) Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 3 (max = 119229) Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 5 (max = 8) Moving inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX The filesystem on /dev/md0 is now 4883608960 (4k) blocks long. # resize2fs -p /dev/md0 resize2fs 1.42.13 (17-May-2015) Resizing the filesystem on /dev/md0 to 5860330752 (4k) blocks. Begin pass 2 (max = 6) Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 3 (max = 149036) Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Begin pass 5 (max = 14) Moving inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX The filesystem on /dev/md0 is now 5860330752 (4k) blocks long. # e2fsck -fn /dev/md0 e2fsck 1.42.13 (17-May-2015) ext2fs_check_desc: Corrupt group descriptor: bad block for inode table e2fsck: Group descriptors look bad... trying backup blocks... Superblock has an invalid journal (inode 8). Clear? no e2fsck: Illegal inode number while checking ext3 journal for /dev/md0 On 2015-09-12 12:27, Johan Harvyl wrote: > Hi, > > I have now evacuated the data on the filesystem and I *did* manage to > recreate the > "Should never happen: resize inode corrupt!" using the versions of > e2fsprogs I believe I was using at the time. > > The vast majority of the data that I was able to checksum was ok. > > For me I guess the way forward should be to recreate the fs with > 1.42.13 and stick to online resize > from now on, correct? > > Are there any feature flags that I should not use when expanding file > systems or any that I must use? > > -johan > > > Here is a step by step of what I did to reproduce > > I have built the following two versions of e2fsprogs (configure, make, > make install, nothing else): > 421d693 (HEAD) libext2fs: fix potential buffer overflow in closefs() > 6a3741a (tag: v1.42.12) Update release notes, etc. for final 1.42.12 > release > > 9779e29 (HEAD, tag: v1.42.10) Update release notes, etc. for final > 1.42.10 release > > === > > First build the fs with 1.42.10 with the exact number of blocks I > originally had. > > # MKE2FS_CONFIG=/root/e10/out/etc/mke2fs.conf > /root/e10/out/sbin/mkfs.ext4 /dev/md0 -i 262144 -m 0 -O 64bit > 15627548672k > mke2fs 1.42.10 (18-May-2014) > /dev/md0 contains a ext4 file system > created on Sat Sep 12 11:23:02 2015 > Proceed anyway? (y,n) y > Creating filesystem with 3906887168 4k blocks and 61045248 inodes > Filesystem UUID: d00e9e59-3756-4e59-9539-bc00fe2446b5 > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, > 2654208, > 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, > 78675968, > 102400000, 214990848, 512000000, 550731776, 644972544, > 1934917632, > 2560000000, 3855122432 > > Allocating group tables: done > Writing inode tables: done > Creating journal (32768 blocks): done > Writing superblocks and filesystem accounting information: done > > From dumpe2fs I observe: > 1) the fs features match what I had on my broken fs > 2) the number of free blocks is 512088558484167 which is clearly wrong. > > # e2fsck -fnv /dev/md0 > e2fsck 1.42.13 (17-May-2015) > 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 > Free blocks count wrong (512088558484167, counted=3902749383). > Fix? no > > So the initial fs created by 1.42.10 appear to be bad. > > Filesystem volume name: <none> > Last mounted on: <not available> > Filesystem UUID: d00e9e59-3756-4e59-9539-bc00fe2446b5 > Filesystem magic number: 0xEF53 > Filesystem revision #: 1 (dynamic) > Filesystem features: has_journal ext_attr resize_inode dir_index > filetype extent 64bit flex_bg sparse_super large_file huge_file > uninit_bg dir_nlink extra_isize > Filesystem flags: signed_directory_hash > Default mount options: user_xattr acl > Filesystem state: clean > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 61045248 > Block count: 3906887168 > Reserved block count: 0 > Free blocks: 512088558484167 > Free inodes: 61045237 > First block: 0 > Block size: 4096 > Fragment size: 4096 > Group descriptor size: 64 > Reserved GDT blocks: 185 > Blocks per group: 32768 > Fragments per group: 32768 > Inodes per group: 512 > Inode blocks per group: 32 > Flex block group size: 16 > Filesystem created: Sat Sep 12 11:27:55 2015 > Last mount time: n/a > Last write time: Sat Sep 12 11:27:55 2015 > Mount count: 0 > Maximum mount count: -1 > Last checked: Sat Sep 12 11:27:55 2015 > Check interval: 0 (<none>) > Lifetime writes: 158 MB > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 256 > Required extra isize: 28 > Desired extra isize: 28 > Journal inode: 8 > Default directory hash: half_md4 > Directory Hash Seed: f252a723-7016-43d1-97f8-579062a215e1 > Journal backup: inode blocks > Journal features: (none) > Journal size: 128M > Journal length: 32768 > Journal sequence: 0x00000001 > Journal start: 0 > > > > The next step is resizing + 4 TB with 1.42.12. > # MKE2FS_CONFIG=/root/e12/out/etc/mke2fs.conf > /root/e12/out/sbin/resize2fs -p /dev/md0 19534435840k > resize2fs 1.42.12 (29-Aug-2014) > <and nothing more> > It did *not* print the "Resizing the filesystem on /dev/md0 to > 4883608960 (4k) blocks." that it should have. > > I let it run for 90+ minutes sampling CPU and IO usage with iotop from > time to time. It was using more or less 100% CPU and no visible io. > > So, I let e2fsck fix the free block count and re-did the resize: > # e2fsck -f /dev/md0 > e2fsck 1.42.13 (17-May-2015) > 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 > Free blocks count wrong (512088558484167, counted=3902749383). > Fix<y>? yes > > /dev/md0: ***** FILE SYSTEM WAS MODIFIED ***** > /dev/md0: 11/61045248 files (0.0% non-contiguous), 4137785/3906887168 > blocks > > # MKE2FS_CONFIG=/root/e12/out/etc/mke2fs.conf > /root/e12/out/sbin/resize2fs -p /dev/md0 19534435840k > resize2fs 1.42.12 (29-Aug-2014) > Resizing the filesystem on /dev/md0 to 4883608960 (4k) blocks. > Begin pass 2 (max = 6) > Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > Begin pass 3 (max = 119229) > Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > Begin pass 5 (max = 8) > Moving inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > The filesystem on /dev/md0 is now 4883608960 (4k) blocks long. > > dumpe2fs 1.42.13 (17-May-2015) > Filesystem volume name: <none> > Last mounted on: <not available> > Filesystem UUID: 159d3929-1842-4f8d-907f-7509c16f06df > Filesystem magic number: 0xEF53 > Filesystem revision #: 1 (dynamic) > Filesystem features: has_journal ext_attr resize_inode dir_index > filetype extent 64bit flex_bg sparse_super large_file huge_file > uninit_bg dir_nlink extra_isize > Filesystem flags: signed_directory_hash > Default mount options: user_xattr acl > Filesystem state: clean > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 76306432 > Block count: 4883608960 > Reserved block count: 0 > Free blocks: 4878450712 > Free inodes: 76306421 > First block: 0 > Block size: 4096 > Fragment size: 4096 > Group descriptor size: 64 > Blocks per group: 32768 > Fragments per group: 32768 > Inodes per group: 512 > Inode blocks per group: 32 > RAID stride: 32752 > Flex block group size: 16 > Filesystem created: Sat Sep 12 11:41:10 2015 > Last mount time: n/a > Last write time: Sat Sep 12 11:56:20 2015 > Mount count: 0 > Maximum mount count: -1 > Last checked: Sat Sep 12 11:49:28 2015 > Check interval: 0 (<none>) > Lifetime writes: 279 MB > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 256 > Required extra isize: 28 > Desired extra isize: 28 > Journal inode: 8 > Default directory hash: half_md4 > Directory Hash Seed: feeea566-bb38-44c6-a4d5-f97aa78001d4 > Journal backup: inode blocks > Journal features: (none) > Journal size: 128M > Journal length: 32768 > Journal sequence: 0x00000001 > Journal start: 0 > > Looking good so far, and now for the final resize to 24 TB using 1.42.13: > # resize2fs -p /dev/md0 > resize2fs 1.42.13 (17-May-2015) > Resizing the filesystem on /dev/md0 to 5860330752 (4k) blocks. > Begin pass 2 (max = 6) > Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > Begin pass 3 (max = 149036) > Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > Begin pass 5 (max = 14) > Moving inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > Should never happen: resize inode corrupt! > > # dumpe2fs -h /dev/md0 > dumpe2fs 1.42.13 (17-May-2015) > Filesystem volume name: <none> > Last mounted on: <not available> > Filesystem UUID: 159d3929-1842-4f8d-907f-7509c16f06df > Filesystem magic number: 0xEF53 > Filesystem revision #: 1 (dynamic) > Filesystem features: has_journal ext_attr resize_inode dir_index > filetype extent 64bit flex_bg sparse_super large_file huge_file > uninit_bg dir_nlink extra_isize > Filesystem flags: signed_directory_hash > Default mount options: user_xattr acl > Filesystem state: clean with errors > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 91568128 > Block count: 5860330752 > Reserved block count: 0 > Free blocks: 5853069550 > Free inodes: 91568117 > First block: 0 > Block size: 4096 > Fragment size: 4096 > Group descriptor size: 64 > Blocks per group: 32768 > Fragments per group: 32768 > Inodes per group: 512 > Inode blocks per group: 32 > RAID stride: 32752 > Flex block group size: 16 > Filesystem created: Sat Sep 12 11:41:10 2015 > Last mount time: n/a > Last write time: Sat Sep 12 12:03:55 2015 > Mount count: 0 > Maximum mount count: -1 > Last checked: Sat Sep 12 11:49:28 2015 > Check interval: 0 (<none>) > Lifetime writes: 279 MB > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 256 > Required extra isize: 28 > Desired extra isize: 28 > Journal inode: 8 > Default directory hash: half_md4 > Directory Hash Seed: feeea566-bb38-44c6-a4d5-f97aa78001d4 > Journal backup: inode blocks > Journal superblock magic number invalid! > > > On 2015-09-04 00:16, Johan Harvyl wrote: >> Hello again, >> >> I finally got around to dig some more into this and made what I >> consider some good progress as I am now able to mount the filesystem >> read-only so I thought I would update this thread a bit. >> >> Short one sentence recap since it's been a while since the original >> post: I am trying to recover a filesystem that was quite badly >> damaged by an offline resize2fs of a fairly modern ext4fs from 20 TB >> to 24 TB. >> >> I spent a lot of time trying to get something meaningful out of >> e2fsck/debugfs and learned quite a bit in the process and I would >> like to briefly share some observations. >> >> 1) The first hurdle running e2fsck -fnv is that the "Superblock has >> an invalid journal (inode 8)" is considered fatal and cannot be >> fixed, at least not in r/o mode so e2fsck just stops, this check >> needed to go away. >> >> 2) e2fsck gets utterly confused by the "bad block inode" that >> incorrectly gets identified as having something worth looking at and >> spends days iterating through blocks (before I cancelled it). >> Removing handling if ino == EXT2_BAD_INO in pass1 and pass1b made >> things a bit better. >> >> 3) e2fsck using a backup superblock >> ext2fs_check_desc: Corrupt group descriptor: bad block for inode table >> e2fsck: Group descriptors look bad... trying backup blocks... >> This is bad, as it means using a superblock that has not been updated >> with the +4TB. Consequently it gets the location of the first block >> group wrong, or at the very least the first inode table that houses >> the root inode. >> Forcing it to use the master superblock again makes things a bit better. >> >> I have some logs from various e2fsck runs with various amounts of >> hacks applied if they are of any interest to developers? I will also >> likely have the filesystem in this state for a week or two more if >> any other information I can extract is of interest to figure out what >> made resize2fs screw things up. >> >> >> >> In the end, the only actual change I have made to the filesystem to >> make it mountable is that I borrowed a root inode from a different >> filesystem and updated the i_block pointer to point to the extent >> tree corresponding to the root inode of my broken filesystem which >> was quite easy to find by just looking for the string "lost+found". >> >> # mount -o ro,noload /dev/md0 /mnt/loop >> [2815465.034803] EXT4-fs (md0): mounted filesystem without journal. >> Opts: noload >> >> # df -h /dev/md0 >> Filesystem Size Used Avail Use% Mounted on >> /dev/md0 22T -382T 404T - /mnt/loop >> >> Uh oh, does not look to good.. But hey, doing some checks on the data >> contents and so far results are very promising. An "ls /" looks good >> and so does a lot of the data that I can verify checksums on, checks >> are still running... >> >> I really do not know how to move on with trying to repair the >> filesystem with e2fsck. I do not feel brave enough to let it run r/w >> on the given how many hacks that I consider very dirty were required >> to even get it this far. At this point letting it make changes to the >> filesystem may actually make it worse so I see no other way forward >> than extracting all the contents and recreating the filesystem from >> scratch. >> >> Question is though, what is the recommended way to create the >> filesystem? 64bit is clearly necessary, but what about the other >> feature flags like flex_bg/meta_bg/resize_inode...? I do not care >> much about slight gains in performance, robustness is more important, >> and that it can be resized in the future. >> >> Only online resize from now on, never offlline, I learned that lesson... >> >> Will it be possible to expand from 24 TB to 28 TB online? >> >> thanks, >> -johan >> >> >> On 2015-08-13 20:12, Johan Harvyl wrote: >>> On 2015-08-13 15:27, Theodore Ts'o wrote: >>>> On Thu, Aug 13, 2015 at 12:00:50AM +0200, Johan Harvyl wrote: >>>> >>>>>> I'm not aware of any offline resize with 1.42.13, but it sounds like >>>>>> you were originally using mke2fs and resize2fs 1.42.10, which did >>>>>> have >>>>>> some bugs, and so the question is what sort of might it might have >>>>>> left things. >>>>> What kind of bugs are we talking about, mke2fs? resize2fs? e2fsck? >>>>> Any >>>>> specific commits of interest? >>>> I suspect it was caused by a bug in resize2fs 1.42.10. The problem is >>>> that off-line resize2fs is much more powerful; it can handle moving >>>> file system metadata blocks around, so it can grow file systems in >>>> cases which aren't supported by online resize --- and it can shrink >>>> file systems when online resize doesn't support any kind of file >>>> system shrink. As such, the code is a lot more complicated, whereas >>>> the online resize code is much simpler, and ultimately, much more >>>> robust. >>> Understood, so would it have been possible to move from my 20 TB -> >>> 24 TB fs with >>> online resize? I am confused by the threads I see on the net with >>> regards to this. >>>>> Can you think of why it would zero out the first thousands of >>>>> inodes, like the root inode, lost+found and so on? I am thinking >>>>> that would help me assess the potential damage to the files. Could I >>>>> perhaps expect the same kind of zeroed out blocks at regular >>>>> intervals all over the device? >>>> I didn't realize that the first thousands of inodes had been zeroed; >>>> either you didn't mention this earier or I had missed that from your >>>> e-mail. I suspect the resize inode before the resize was pretty >>>> terribly corrupted, but in a way that e2fsck didn't complain. >>> >>> Hi, >>> >>> I may not have been clear on that it was not just the first handful >>> of inodes. >>> >>> When I manually sampled some inodes with debugfs and a disk editor, >>> the first group >>> I found valid inodes in was: >>> Group 48: block bitmap at 1572864, inode bitmap at 1572880, inode >>> table at 1572896 >>> >>> With 512 inodes per group that would mean at least some 24k inodes >>> are blanked out, >>> but I did not check them all, I just sampled groups manually so >>> there could be some >>> valid in some of the groups below group 48 or a lot more invalid >>> afterwards. >>> >>>> I'll have to try to reproduce the problem based how you originally >>>> created and grew the file system and see if I can somehow reproduce >>>> the problem. Obviously e2fsck and resize2fs should be changed to make >>>> this operation much more robust. If you can tell me the exact >>>> original size (just under 16TB is probably good enough, but if you >>>> know the exact starting size, that might be helpful), and then steps >>>> by which the file system was grown, and which version of e2fsprogs was >>>> installed at the time, that would be quite helpful. >>>> >>>> Thanks, >>>> >>>> - Ted >>> >>> Cool, I will try to go through its history in some detail below. >>> >>> If you have ideas on what I could look for, like ideas on if there >>> is a particular periodicity >>> to the corruption I can write some python to explore such theories. >>> >>> >>> The filesystem was originally created with e2fsprogs 1.42.10-1 and >>> most likely linux-image >>> 3.14 from Debian. >>> >>> # mkfs.ext4 /dev/md0 -i 262144 -m 0 -O 64bit >>> mke2fs 1.42.10 (18-May-2014) >>> Creating filesystem with 3906887168 4k blocks and 61045248 inodes >>> Filesystem UUID: 13c2eb37-e951-4ad1-b194-21f0880556db >>> Superblock backups stored on blocks: >>> 32768, 98304, 163840, 229376, 294912, 819200, 884736, >>> 1605632, 2654208, >>> 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, >>> 78675968, >>> 102400000, 214990848, 512000000, 550731776, 644972544, >>> 1934917632, >>> 2560000000, 3855122432 >>> >>> Allocating group tables: done >>> Writing inode tables: done >>> Creating journal (32768 blocks): done >>> Writing superblocks and filesystem accounting information: done >>> # >>> >>> It was expanded with 4 TB (another 976721792 4k blocks). Best I can >>> tell from my logs this >>> was done with either e2fsprogs:amd64 1.42.12-1 or 1.42.12-1.1 >>> (debian packages) and >>> Linux 3.16. Everything was running fine after this. >>> NOTE #1: It does *not* look like this filesystem was ever touched by >>> resize2fs 1.42.10. >>> NOTE #2: The diff between debian packages 1.42.12-1 and 1.42.12-1.1 >>> appear to be this: >>> 49d0fe2 libext2fs: fix potential buffer overflow in closefs() >>> >>> Then for the final 4 TB for a total of 5860330752 4k blocks which >>> was done with >>> e2fsprogs:amd64 1.42.13-1 and Linux 4.0. This is where the: >>> "Should never happen: resize inode corrupt" >>> was seen. >>> >>> In both cases the same offline resize was done, with no exotic options: >>> # umount /dev/md0 >>> # fsck.ext4 -f /dev/md0 >>> # resize2fs /dev/md0 >>> >>> thanks, >>> -johan >> > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists