RE: resize2fs problem with stride calc

[TR Reardon <thomas_reardon@hotmail.com>]

> Date: Sun, 21 Sep 2014 11:13:06 -0500
> From: sandeen@redhat.com
>
> On 9/20/14 3:46 PM, TR Reardon wrote:
>> resize2fs seems to come up with some crazy default stride numbers.
>> This occurs with and without bigalloc.
>>
>>
>> I was testing enabling/disabling 64bit using latest patches from DJW,
>> and noticed that s_raid_stride was being written with nonsensical
>> values, in particular determine_fs_stride() is coming up with overly
>> large values. The code is old (2006) and lacks comment so I'm not
>> sure what the intended operation is. Does this just need to be
>> updated for flex_bg? Should s_raid_stride ever be auto-changed on
>> resize? If it should change, should stripe also change?
>
> That old commit says:
>
> + In addition, add code so that resize2fs can automatically
> + determine the RAID stride parameter that had been
> + previously used on the filesystem.
>
> but a year later, in 2007, this:
>
> commit 96c6a3acd377698cb99ffd9925bec9b20ca4f6f9
> Author: Theodore Ts'o <tytso@mit.edu>
> Date: Fri May 18 22:06:53 2007 -0400
>
> Store the RAID stride value in the superblock and take advantage of it
>
> stored it properly in the superblock (this hit e2fsprogs-1.40).
>
> So maybe the whole heuristic could just be removed now, but from a simple
> test, it's working here.

Have you tried to test with flex_bg?  I think that's what raises the problem.

>
> What was the geometry (dumpe2fs -h) of your filesystem before the resize?

Here is one example.  I am changing _only_ the bitness, geometry stays the same 
other than changes to reserved GDT.

Prior to resize2fs -b :

...
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file dir_nlink extra_isize bigalloc metadata_csum
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              715776
Block count:              732566384
Reserved block count:     0
Free blocks:              13977472
Free inodes:              714665
First block:              0
Block size:               4096
Cluster size:             65536
Reserved GDT blocks:      53
Blocks per group:         524288
Clusters per group:       32768
Inodes per group:         512
Inode blocks per group:   32
Flex block group size:    16
...
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
...


And following resize2fs -b:

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 dir_nlink extra_isize bigalloc metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              715776
Block count:              732566384
Reserved block count:     0
Free blocks:              13977472
Free inodes:              714665
First block:              0
Block size:               4096
Cluster size:             65536
Group descriptor size:    64
Reserved GDT blocks:      42
Blocks per group:         524288
Clusters per group:       32768
Inodes per group:         512
Inode blocks per group:   32
RAID stride:              65520
Flex block group size:    16
...
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
...


 		 	   		  --
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html