On 3 August 2017 at 14:26, Karel Zak <kzak@xxxxxxxxxx> wrote: > On Wed, Aug 02, 2017 at 02:14:18PM +0200, Rafał Miłecki wrote: >> From: Rafał Miłecki <rafal@xxxxxxxxxx> >> >> UBI is a volume management system that can be used on a raw flash >> partition for providing multiple logical volumes. Detecting UBI >> superblock may be useful for tools wanting to simplify or automate >> attaching UBI. >> >> Please note it's not directly related to the ubifs support which is just >> a filesystem working on top of UBI volume. >> >> In other words: UBI can be used on MTD partition (e.g. /dev/mtdblock0) >> while ubifs can be used on UBI volume (e.g. /dev/ubi0_0). >> >> This patch adds simple code reading UBI version and unique number and >> setting it in the blkid_probe. >> >> Signed-off-by: Rafał Miłecki <rafal@xxxxxxxxxx> >> --- >> V2: Update commit message (more UBI vs. ubifs details) >> Pass &hdr->image_seq to the blkid_probe_sprintf_uuid >> Add test > > Applied, thanks. > >> +ID_FS_TYPE=ubi >> +ID_FS_USAGE=filesystem > > This is probably not ideal. We use "RAID" flag for logic volume > managers. The advantage is that probing is faster as it does not try > to check for another signature when "RAID" is detected. > > The question is how small could be the UBI device? We don't probe for > "RAID" on very small devices (<=1MiB). UBI is responsible for bad blocks handling, so it needs enough erase blocks (PEBs) reserved in order to work. If one's MTD partition is as small as 1 MiB, it won't have enough of erase blocks (PEBs) [0]. There is some formula for amount of reserved blocks, like: n_reserved = n_max_bad_blocks + n_internal_volumes_blocks + 1 but basically 1 MiB is said to be too small. Does it mean we should & we're save to switch from OTHER to the RAID? [0] http://lists.infradead.org/pipermail/linux-mtd/2014-November/056658.html [1] http://www.dubeiko.com/development/FileSystems/UBI/ubidesign.pdf -- Rafał -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html