[parted-devel] [PATCH] Use disk geometry as basis for ext2 sector sizes.

[Steven Lang]

It's a bit of a long story, but the short answer was that I was testing some aspects of 4k sector size with different combinations of commits. When I had included 80678b but not fa815a, ext2 detection failed because the geometry of the ext2 filesystem would always exceed the geometry of the device.

I don't think the current code shows any effects of the bug, though conceivably if the filesystem detection were to detect two different filesystems on a device with 4k sector size, it would rarely pick ext2/3/4 as the "correct" one even if it was, due to the size being so grossly off. But barring that rather contrived and probably carefully crafted situation, I can't see anywhere it would be an issue in the current code base since the geometry returned by the filesystem is only used to find the best fit.

________________________________________
From: Phillip Susi <phillsusi at gmail.com> on behalf of Phillip Susi <psusi at ubuntu.com>
Sent: Friday, January 09, 2015 7:50 AM
To: Steven Lang; parted-devel at lists.alioth.debian.org
Subject: Re: [parted-devel] [PATCH] Use disk geometry as basis for ext2 sector sizes.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/8/2015 8:22 PM, Steven Lang wrote:
> When creating the geom for probed ext2 based filesystems, the size
> was being reported in 512 byte sectors, regardless of what the
> actual sector size of the device is.

Makes sense to me, but how did you discover it?  Just by code
inspection, or does it actually make a difference somewhere?  i.e. how
can I test to verify that this fixes a problem.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUr/ivAAoJENRVrw2cjl5RwTIH/2WdCzhvLxqjyI2s4NHT+lqA
nWgSq7sJokS0YWYdo0/orl+M9gZ3zVujmC+1CcMpuAPinX+Zs6DLjA48J6NJWWB3
VcG4ge3+6ALf2Hr6VLTZUO97/7kPmiDiO5T+usgyKdmMGWOovVmNQF0i8s3rtw8o
kvKseNnttUTxLnweQLJIteBDZ91LrurB9oxz/N4WgL1fP0PPx03orTglP8ePoHTs
F6rqbSiEpI8ZCqqZF2mp8sYLYRLvpUfFeWBHYrvSgLTJCNMc5Ob2p9Pq/OsI2shn
HWh0x7VptUIW4FRvPYWNqdQgNAw0UuMRyLTM/+dRX0p29F28fsyWnqIey1foZCM=
=c0e1
-----END PGP SIGNATURE-----