summaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@redhat.com>2010-12-21 15:32:05 -0600
committerTheodore Ts'o <tytso@mit.edu>2010-12-22 13:54:30 -0500
commitd16db7d9ded85f4a7f8d91562246cc2f59bf204d (patch)
tree23b33934a8f1522b581e1db2fa649872fcd9ae09 /README
parenta4fdf09414e04e9ecb995aa0af2f525d335987ae (diff)
downloade2fsprogs-d16db7d9ded85f4a7f8d91562246cc2f59bf204d.tar.gz
resize2fs: do not clear resize inode for 0 resvd blocks
I ran into odd behavior where mkfs.ext4 of a 16T filesystem would create a resize inode with 0 reserved blocks, and mark the resize_inode feature. A subsequent slight downward resize of the filesystem would remove the resize inode, making any further offline resizing impossible. This is especially odd in light of the fact that a large downward resize (say, to 8T) will actually add blocks to the resize inode - so a small resize removes it, a large resize expands it ... commit 8ade268cf2fde8629b51bfd1c044a83db88234cd had added this: If the filesystem is grown to the point where the resize_inode is no longer needed, clean it up properly so e2fsck doesn't have to. but, it seems e2fsck does not care about this situation, either. So, simply leave the resize_inode intact in this case, and everything seems to be happy. Note, this is for the 1.41.xx branch. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions