| 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
| ||
|
Date: Sun, 21 Sep 2014 18:32:53 -0400 From: TR Reardon <thomas_reardon@...mail.com> To: Eric Sandeen <sandeen@...hat.com>, "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>, "darrick.wong@...cle.com" <darrick.wong@...cle.com> Subject: RE: resize2fs problem with stride calc > Date: Sun, 21 Sep 2014 11:13:06 -0500 > From: sandeen@...hat.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@....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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists