On Tue, 9 Jun 2015 16:07:42 +0200, Karel Zak wrote:
> On Tue, Jun 09, 2015 at 10:04:15PM +0900, Ryusuke Konishi wrote:
>> $ 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 trunc
On Tue, Jun 09, 2015 at 10:04:15PM +0900, Ryusuke Konishi wrote:
> $ 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.
> progr
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/util
On 09.06.2015, Karel Zak wrote:
> Yeah, fixed:
[]
Thanks a lot to both of you! Tried both solutions and can confirm that
they work both.
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
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=0081
On 08.06.2015, Heinz Diehl wrote:
> > This change has been applied between v2.24 and v2.24.1 of util-linux,
> > and not yet fixed in the mainline.
> Ok, I'll try to identify and revert this commit in the meantime.
The patch doesn't revert cleanly. Is there a workaround I could use
until the pr
On 08.06.2015, Ryusuke Konishi wrote:
> I succeeded to reproduce this issue on Fedora 20, 21, 22 and Debian
> jessie. Also, I could narrow down the issue.
Thanks a lot for your effort!
> Here, the backup super block of /dev/sdb1 got detected also for
> /dev/sdb by the commit 5f77ce6f3269.
Jus
(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"):
* com
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
NAMEFSTYPE LABEL UUID
On 08.06.2015, Heinz Diehl wrote:
> Now, the newly formatted drive is registered in fstab to be
> automatically mounted on boot:
>
> UUID=ff17dda9-fcae-42e7-a438-9087de58902e /USBDRIVE nilfs2
> defaults0 0
Sorry for the noise, but it's quite difficult to sum up all the
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
NAMEFSTYPE LABEL UUID MOUNTPOINT
sda
On 08.06.2015, Ryusuke Konishi wrote:
> Could you tell us the version information of distro,
> lsblk, libblkid, nilfs-utils, and kernel you are using ?
It happens on two different systems:
The first one is bog-standard Fedora 21:
[htd@chiara ~]$ rpm -qa | egrep 'lsblk|libblkid|nilfs'
libblkid-
(CCed to linux-nilfs@vger.kernel.org)
Hi Heinz,
On 2015/06/08 15:43, Heinz Diehl wrote:
Hi,
a nilfs2 formatted disk fails to mount via fstab due to double uuid's.
See lsblk output below. The logs indicate that the system attempts to
mount /dev/sdb rather than /dev/sdb1, which of course fails. I
13 matches
Mail list logo
