Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1160389 > unrolled thread

Re: NILFS2: double uuid

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: NILFS2: double uuid Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> - 2015-06-08 12:40 +0200
    Re: NILFS2: double uuid Karel Zak <kzak@redhat.com> - 2015-06-09 11:00 +0200

#1160389 — Re: NILFS2: double uuid

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

[toc] | [next] | [standalone]

#1161142

On Tue, Jun 09, 2015 at 12:31:27AM +0900, Ryusuke Konishi wrote:
> 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.

Yeah, fixed:
http://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=00817742ce360119e079a33e12cf84118ff7c63e

Note that workaround is to not use nilfs2 on the last partition or
have a tiny gap (1 sector is enough) between last partition and the 
end of the whole-disk.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com
--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web