All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryusuke Konishi <konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
To: Karel Zak <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Heinz Diehl <htd+ml-iEI8Y0CNJBYdnm+yROfE0A@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: NILFS2: double uuid
Date: Tue, 09 Jun 2015 22:04:15 +0900	[thread overview]
Message-ID: <5576E44F.5030201@lab.ntt.co.jp> (raw)
In-Reply-To: <20150609085329.GF1992-xkT7n84Rsxv/9pzu0YdTqQ@public.gmane.org>

Hi,

On 2015/06/09 17:53, Karel Zak wrote:
> 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
>

Thanks for your quick work!

I tested the patch.  It almost worked fine.
One issue I found is a transient state after fs-resizing.

After shrinking the file system, both superblocks dropped and
lsblk failed to detect the filesystem:

$ sudo LD_LIBRARY_PATH=/usr/local/lib lsblk -f
NAME   FSTYPE  LABEL           UUID 
MOUNTPOINT
[...]
sdb
`-sdb1 nilfs2                  2d7cd130-82a0-4a3c-b8a8-4ac5a26f5703 /test

$ sudo nilfs-resize -y /dev/sdb1 1G
Partition size = 2146435072 bytes.
Shrink the filesystem size from 2146435072 bytes to 1073741824 bytes.
128 segments will be truncated from segnum 127.
Moving 103 in-use segments.
progress |***********************************************|
Done.

$ sudo umount /test
$ sudo mount /dev/sdb1 /test
$ sudo LD_LIBRARY_PATH=/usr/local/lib lsblk -f
NAME   FSTYPE  LABEL           UUID 
MOUNTPOINT
[...]
sdb
`-sdb1                                                              /test

This blank state continued until I shrank the partition or
re-extended the filesystem to the partition size.

Could you consider confining the s_dev_size test only to the
backup superblock ?

It seems that we don't have to drop the primary super block
even if s_dev_size doesn't fit to the partition size.


Regards,
Ryusuke Konishi

--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
To: Karel Zak <kzak@redhat.com>
Cc: Heinz Diehl <htd+ml@fritha.org>,
	linux-kernel@vger.kernel.org, linux-nilfs@vger.kernel.org
Subject: Re: NILFS2: double uuid
Date: Tue, 09 Jun 2015 22:04:15 +0900	[thread overview]
Message-ID: <5576E44F.5030201@lab.ntt.co.jp> (raw)
In-Reply-To: <20150609085329.GF1992@ws.net.home>

Hi,

On 2015/06/09 17:53, Karel Zak wrote:
> 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
>

Thanks for your quick work!

I tested the patch.  It almost worked fine.
One issue I found is a transient state after fs-resizing.

After shrinking the file system, both superblocks dropped and
lsblk failed to detect the filesystem:

$ sudo LD_LIBRARY_PATH=/usr/local/lib lsblk -f
NAME   FSTYPE  LABEL           UUID 
MOUNTPOINT
[...]
sdb
`-sdb1 nilfs2                  2d7cd130-82a0-4a3c-b8a8-4ac5a26f5703 /test

$ sudo nilfs-resize -y /dev/sdb1 1G
Partition size = 2146435072 bytes.
Shrink the filesystem size from 2146435072 bytes to 1073741824 bytes.
128 segments will be truncated from segnum 127.
Moving 103 in-use segments.
progress |***********************************************|
Done.

$ sudo umount /test
$ sudo mount /dev/sdb1 /test
$ sudo LD_LIBRARY_PATH=/usr/local/lib lsblk -f
NAME   FSTYPE  LABEL           UUID 
MOUNTPOINT
[...]
sdb
`-sdb1                                                              /test

This blank state continued until I shrank the partition or
re-extended the filesystem to the partition size.

Could you consider confining the s_dev_size test only to the
backup superblock ?

It seems that we don't have to drop the primary super block
even if s_dev_size doesn't fit to the partition size.


Regards,
Ryusuke Konishi


  parent reply	other threads:[~2015-06-09 13:04 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08  6:43 NILFS2: double uuid Heinz Diehl
2015-06-08  6:47 ` Heinz Diehl
2015-06-08  8:18 ` Ryusuke Konishi
     [not found]   ` <55754FDA.10406-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2015-06-08  9:45     ` Heinz Diehl
2015-06-08  9:45       ` Heinz Diehl
     [not found]       ` <20150608094559.GB15702-iEI8Y0CNJBYdnm+yROfE0A@public.gmane.org>
2015-06-08 10:08         ` Heinz Diehl
2015-06-08 10:08           ` Heinz Diehl
     [not found]           ` <20150608100835.GA16569-iEI8Y0CNJBYdnm+yROfE0A@public.gmane.org>
2015-06-08 10:12             ` Heinz Diehl
2015-06-08 10:12               ` Heinz Diehl
2015-06-08 10:31             ` Ryusuke Konishi
2015-06-08 10:31               ` Ryusuke Konishi
     [not found]               ` <55756F17.7080603-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2015-06-08 15:31                 ` Ryusuke Konishi
2015-06-08 15:31                   ` Ryusuke Konishi
     [not found]                   ` <20150609.003127.1516615115859573912.konishi.ryusuke-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2015-06-08 17:23                     ` Heinz Diehl
2015-06-08 17:23                       ` Heinz Diehl
     [not found]                       ` <20150608172324.GA7760-iEI8Y0CNJBYdnm+yROfE0A@public.gmane.org>
2015-06-09  5:45                         ` Heinz Diehl
2015-06-09  5:45                           ` Heinz Diehl
2015-06-09  8:53                     ` Karel Zak
2015-06-09  8:53                       ` Karel Zak
2015-06-09  9:46                       ` Heinz Diehl
     [not found]                       ` <20150609085329.GF1992-xkT7n84Rsxv/9pzu0YdTqQ@public.gmane.org>
2015-06-09 13:04                         ` Ryusuke Konishi [this message]
2015-06-09 13:04                           ` Ryusuke Konishi
     [not found]                           ` <5576E44F.5030201-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org>
2015-06-09 14:07                             ` Karel Zak
2015-06-09 14:07                               ` Karel Zak
     [not found]                               ` <20150609140742.GH1992-xkT7n84Rsxv/9pzu0YdTqQ@public.gmane.org>
2015-06-09 16:00                                 ` Ryusuke Konishi
2015-06-09 16:00                                   ` Ryusuke Konishi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5576E44F.5030201@lab.ntt.co.jp \
    --to=konishi.ryusuke-zyj7fxus5i5l9jvzuh4aog@public.gmane.org \
    --cc=htd+ml-iEI8Y0CNJBYdnm+yROfE0A@public.gmane.org \
    --cc=kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.