Commit Graph

4 Commits

Author SHA1 Message Date
Theodore Ts'o
77255cf369 resize2fs: clarify the size of blocks in resize2fs's messages
Addresses-Debian-Bug: #758029

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2014-08-24 23:23:41 -04:00
Theodore Ts'o
9f90b2e632 tests: fix stray newline printed when running r_min_itable
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2013-12-26 00:37:09 -05:00
Theodore Ts'o
128c943ef2 tests: remove version number dependency in r_min_itable
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2013-10-12 22:25:29 -04:00
Theodore Ts'o
7447da02f0 tests: add test for resize2fs -M with inode table in middle of block group
Eric Sandeen reported that Fedora's mke2fs when compiled for ppc was
creating a file system which caused problems with resize2fs -M.
Closer examination showed that the problem was file system which
looked like this:

Filesystem features:      ext_attr dir_index filetype sparse_super
Inode count:              512
Block count:              1247
   ...

Group 0: (Blocks 1-1024)
  Primary superblock at 1, Group descriptors at 2-2
  Block bitmap at 66 (+65), Inode bitmap at 67 (+66)
  Inode table at 68-99 (+67)

Group 1: (Blocks 1025-1246)
  Backup superblock at 1025, Group descriptors at 1026-1026
  Block bitmap at 1090 (+65), Inode bitmap at 1091 (+66)
  Inode table at 1092-1123 (+67)

It's not obvious to me why Fedora's ppc mke2fs is creating file
systems like this (I can't reproduce this on debian ppc systems), but
resize2fs -M should be able to deal with such file systems, which is
what this test is designed to check.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2013-09-30 23:07:27 -04:00