Adding subpage support to NAND driver -- backwards compatibility concerns

[Josh Cartwright]

+Richard, who, when not being trolled on IRC, has been working on
UBI(FS) stuff.

On Thu, Apr 23, 2015 at 12:48:53PM +1000, Iwo Mergler wrote:
> On Thu, 23 Apr 2015 03:29:44 +1000
> Ben Shelton <ben.shelton at ni.com> 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?
[..]
> from what I understand, the only part of the UBI/UBIFS stack that
> uses / cares about subpages are the UBI EC and VID headers.

Are the locations of both headers changed when subpage accesses are
supported?  I was under the impression that EC was always at the
beginning of the page, with the VID headers at the next min IO boundary.
(So, only the location of the VID header would be changed).

> 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.

Okay, well; I would expect that for some systems that are using UBIFS as
root, tweaking the commandline to add 'ubi.mtd=0,<size>' would require a
bootloader change.

Anyway, I think we're talking only about theoretical breakage here, so
it's reasonable to ask whether or not we should even care about this at
all.

> 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.

Is there no metadata in the UBI data structures in flash that indicate
the min IO boundary?  Assuming no, is another option to, at the time of
attach, try both the min IO access size, and, if that doesn't work, try
the page size?

  Josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20150423/0847781f/attachment-0001.sig>