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
next prev 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.