RE: [PATCH 2/2] fs/partition/msdos: Fix unusable extended partition for > 512B sector

[Daniel Taylor]

> -----Original Message-----
> From: OGAWA Hirofumi [mailto:hirofumi@xxxxxxxxxxxxxxxxxx] 
> Sent: Thursday, March 11, 2010 3:58 AM
> To: Daniel Taylor
> Cc: Andrew Morton; H. Peter Anvin; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 2/2] fs/partition/msdos: Fix unusable 
> extended partition for > 512B sector
> 
> "Daniel Taylor" <Daniel.Taylor@xxxxxxx> writes:
> 
> > In the near future, WD will be releasing products that need 
> this patch.
> >
> > Wouldn't it be a better Linux user experience to never have 
> the problem,
> > rather than wait for a bug-fix cycle on the kernel?
> 
> Of course, if we can fix, it's better.
> 
> However, probably, users of this patch would be only boot loader,
> because this is a first sector on extended-partition itself, not
> logical-partitions in extended-partition.

I have not yet tried booting from one of these disks.

They are in USB-attached enclosures, attached well after boot, so the
bootloader has never seen them.  They simply refuse to mount to a running
Linux system because, when the storage for partition size and start was
expanded to 64-bit, no one bothered to fix the intermediate storage in
msdos.c, so the kernel cannot locate the start nor figure the size of
the partitions.

Logically, this patch is not complicated.  The data types in msdos.c
are flat-out wrong, given that the real stored data is of type sector_t.
The intermediate variables should not be u32.

For users of small disks, that are not shared with Windows XP, the patch
is totally innocuous.  It does not diminish any existing working behavior,
for anyone, nor change any API, so I do not understand the resistance to
using it.

> 
> So, maybe this wouldn't be so major problem for normal users, and what
> is needed actually is not sure to me for now (I guess it might be
> depending to BIOS, if boot loader is using BIOS call.).
> 
> So, this patch provides one logical sector, but it's just guess.
> 
> > OTOH, it would be reasonable to wait until someone else had 
> a chance to
> > test the change.  We are awaiting NDAs from RedHat, Canonical, and
> > Novell/SUSE to send them the affected products for 
> library/application
> > development.
> 
> Thanks.
> -- 
> OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/