Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752959AbbFHPbq (ORCPT ); Mon, 8 Jun 2015 11:31:46 -0400 Received: from mail-pd0-f176.google.com ([209.85.192.176]:35932 "EHLO mail-pd0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752545AbbFHPbg (ORCPT ); Mon, 8 Jun 2015 11:31:36 -0400 Date: Tue, 09 Jun 2015 00:31:27 +0900 (JST) Message-Id: <20150609.003127.1516615115859573912.konishi.ryusuke@lab.ntt.co.jp> To: Heinz Diehl Cc: Karel Zak , linux-kernel@vger.kernel.org, linux-nilfs@vger.kernel.org Subject: Re: NILFS2: double uuid From: Ryusuke Konishi In-Reply-To: <55756F17.7080603@lab.ntt.co.jp> References: <20150608094559.GB15702@fritha.org> <20150608100835.GA16569@fritha.org> <55756F17.7080603@lab.ntt.co.jp> X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5450 Lines: 159 (CCed to Karel Zak) Hi, I succeeded to reproduce this issue on Fedora 20, 21, 22 and Debian jessie. Also, I could narrow down the issue. This turned out to be an issue of libblkid in util-linux and introduced by the commit 5f77ce6f3269 ("libblkid: (nilfs2) check also backup superblock"): * commit 1a38ad5c3271a59c7e51580242a2fbd3b0f16495 --> OK $ sudo LD_LIBRARY_PATH=/usr/local/lib lsblk --version lsblk from util-linux 2.24.153-1a38 $ sudo LD_LIBRARY_PATH=/usr/local/lib lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT [...] sdb `-sdb1 nilfs2 c6cd2c9c-0291-4f9f-be9b-10ff8e2acbe6 /test * commit 5f77ce6f32692b473ffcec4c6f63dbd38cd5eeda --> NG $ sudo LD_LIBRARY_PATH=/usr/local/lib lsblk --version lsblk from util-linux 2.24.154-5f77c $ sudo LD_LIBRARY_PATH=/usr/local/lib lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT [...] sdb nilfs2 c6cd2c9c-0291-4f9f-be9b-10ff8e2acbe6 `-sdb1 nilfs2 c6cd2c9c-0291-4f9f-be9b-10ff8e2acbe6 /test Here, the backup super block of /dev/sdb1 got detected also for /dev/sdb by the commit 5f77ce6f3269. This change has been applied between v2.24 and v2.24.1 of util-linux, and not yet fixed in the mainline. It causes the duplicate uuid and leads the UUID mount written in the fstab file to mount the device itself (i.e. /dev/sdb in this example). Thus the mount failure happens. It looks like the backup super block should be dropped from candidates if its device size (sbp->s_dev_size) doesn't match the partition size. Regards, Ryusuke Konishi On Mon, 08 Jun 2015 19:31:51 +0900, Ryusuke Konishi wrote: > Hi, > > On 2015/06/08 19:08, Heinz Diehl wrote: >> On 08.06.2015, Heinz Diehl wrote: >> >> To be more precise, here's what works and what don't, in detail >> (and after a fresh install of Arch): >> >> The USB memory is xfs formatted and works fine: >> >> [root@alarmpi /]# lsblk -f >> NAME FSTYPE LABEL UUID MOUNTPOINT >> sda >> `-sda1 xfs ff17dda9-fcae-42e7-a438-9087de58902e >> mmcblk0 >> |-mmcblk0p1 vfat EA5B-4477 /boot >> `-mmcblk0p2 ext4 c4ddc925-15ab-4465-ac78-967a845e98d5 / >> >> >> Now, it's nilfs2 formatted: >> >> [root@alarmpi /]# mkfs.nilfs2 /dev/sda1 >> WARNING: Device /dev/sda1 appears to contain an existing xfs >> superblock. >> WARNING: All data will be lost after format! >> >> DO YOU REALLY WANT TO FORMAT DEVICE /dev/sda1? >> >> Continue? [y/N] y >> mkfs.nilfs2 (nilfs-utils 2.2.3) >> Start writing file system initial data to the device >> Blocksize:4096 Device:/dev/sda1 Device Size:32026656768 >> File system initialization succeeded !! >> >> After that, all seems to be ok. lsblk shown no double uuid: >> >> [root@alarmpi /]# lsblk -f >> NAME FSTYPE LABEL UUID MOUNTPOINT >> sda >> `-sda1 nilfs2 98da384c-392e-4551-98c0-d076524f5d8b >> mmcblk0 >> |-mmcblk0p1 vfat EA5B-4477 /boot >> `-mmcblk0p2 ext4 c4ddc925-15ab-4465-ac78-967a845e98d5 / >> [root@alarmpi /]# >> >> >> Now the USB drive gets manually mounted, all is ok: >> >> [root@alarmpi /]# mount /dev/sda1 /USBDRIVE >> [root@alarmpi /]# lsblk -f >> NAME FSTYPE LABEL UUID MOUNTPOINT >> sda >> `-sda1 nilfs2 98da384c-392e-4551-98c0-d076524f5d8b /USBDRIVE >> mmcblk0 >> |-mmcblk0p1 vfat EA5B-4477 /boot >> `-mmcblk0p2 ext4 c4ddc925-15ab-4465-ac78-967a845e98d5 / >> >> >> Now, the newly formatted drive is registered in fstab to be >> automatically mounted on boot: >> >> UUID=ff17dda9-fcae-42e7-a438-9087de58902e /USBDRIVE nilfs2 defaults 0 >> 0 >> >> After rebooting the machine, nothing is mounted, and lsblk shows the >> double uuid: >> >> [root@alarmpi /]# lsblk -f >> NAME FSTYPE LABEL UUID MOUNTPOINT >> sda 98da384c-392e-4551-98c0-d076524f5d8b >> `-sda1 nilfs2 98da384c-392e-4551-98c0-d076524f5d8b >> mmcblk0 >> |-mmcblk0p1 vfat EA5B-4477 /boot >> `-mmcblk0p2 ext4 c4ddc925-15ab-4465-ac78-967a845e98d5 / >> >> The logs say: >> >> Jun 08 11:23:47 alarmpi mount: mount.nilfs2: Error while mounting >> /dev/sda on /USBDRIVE: Device or resource busy >> Jun 08 11:23:47 alarmpi systemd: Failed to mount /USBDRIVE. >> >> Here it becomes clear what happens: the system wants to mount /dev/sda >> rather than /dev/sda1, and thus fails. >> >> Out of curiosity, I tried both xfs, ext4 and btrfs, and all of them >> just work. > > I've tested the same steps as you wrote above (first created an > xfs partition, overrode it with a nilfs2 partition, wrote a similar > entry to fstab, and reboot), but didn't reproduce the issue. > > On my CentOS 7 environment, lsblk and default mount are perfectly > working. > > So, it may be a version dependent issue of util-linux. > I will try to reproduce and nallow down the issue with newer > util-linux > packages. > > Thanks, > Ryusuke Konishi > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nilfs" > in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/