Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757894AbbDWCzu (ORCPT ); Wed, 22 Apr 2015 22:55:50 -0400 Received: from mail1.bemta8.messagelabs.com ([216.82.243.198]:49994 "EHLO mail1.bemta8.messagelabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757711AbbDWCzs convert rfc822-to-8bit (ORCPT ); Wed, 22 Apr 2015 22:55:48 -0400 X-Greylist: delayed 393 seconds by postgrey-1.27 at vger.kernel.org; Wed, 22 Apr 2015 22:55:48 EDT X-Env-Sender: Iwo.Mergler@netcommwireless.com X-Msg-Ref: server-8.tower-86.messagelabs.com!1429757337!57758212!1 X-Originating-IP: [220.233.131.78] X-StarScan-Received: X-StarScan-Version: 6.13.6; banners=-,-,- X-VirusChecked: Checked From: Iwo Mergler To: Ben Shelton , "dwmw2@infradead.org" , "computersforpeace@gmail.com" , "dedekind1@gmail.com" , "adrian.hunter@intel.com" , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" CC: "punnaiah.choudary.kalluri@xilinx.com" , "xander.huff@ni.com" , "joshc@ni.com" Date: Thu, 23 Apr 2015 12:48:53 +1000 Subject: RE: Adding subpage support to NAND driver -- backwards compatibility concerns Thread-Topic: Adding subpage support to NAND driver -- backwards compatibility concerns Thread-Index: AdB9IlGQg6sCJ7l1TwKhKocRBbfecAATK6tG Message-ID: References: <20150422172944.GA4134@bshelton-desktop> In-Reply-To: <20150422172944.GA4134@bshelton-desktop> Accept-Language: en-US, en-AU Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2217 Lines: 57 On Thu, 23 Apr 2015 03:29:44 +1000 Ben Shelton 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/