RE: Adding subpage support to NAND driver -- backwards compatibility concerns

[Iwo Mergler]

On Thu, 23 Apr 2015 03:29:44 +1000
Ben Shelton <ben.shelton@xxxxxx> wrote:

> We'd like to upstream our patch, but my concern is that UBIFS behaves
> differently when it knows that the flash device supports subpages.  I
> have a couple of questions related to that:
> 
> - I know from experience that bad things happen when you use a kernel
>   without subpage support with an UBIFS filesystem that was formatted
>   with subpage support.  Is it safe to do the opposite (kernel with
>   subpage support / UBIFS filesystem formatted without subpage
> support)?
> 
> - Assuming that it isn't safe, what's the best way to add subpage
>   support to this driver in an upstreamable way / without breaking
>   people?  Would it be sufficient to add subpage support as a Kconfig
>   option that's disabled by default with a strongly-worded message
>   describing the consequences of enabling it?

Hi Ben,


from what I understand, the only part of the UBI/UBIFS stack that
uses / cares about subpages are the UBI EC and VID headers. If you
have subpage access, the two headers will share a page, if not, they
live in separate pages. With subpages, you half your UBI overhead.

This affects the LEB size for UBIFS as well as the UBI header and data
locations within the PEB, so the filesystems are incompatible.

If you add subpage support to a system that previously had none, and
presumably want to use the old file systems, you need to force the
ubiattach command to use the page size as the VID header offset.

Something like

	PAGESIZE=`cat /sys/class/mtd/mtd0/writesize`
	ubiattach /dev/ubi_ctrl -O $PAGESIZE ...

Same applies to any ubiformat commands.

This stops UBI from using the subpage capability. You also don't
get the benefit of the lower overhead, of course.

Traditionally, if someone changes the kernel config, breaking things
is definitely expected consequences. So, making subpage support
a default-off option for the driver has my vote.


Best regards,

Iwo
--
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/