Re: nvdXpY dissapears while ZFS pool on it is imported
> On 6 Oct 2019, at 01:06, Bernd Walter wrote: > > On Sat, Oct 05, 2019 at 02:50:21PM +0900, Tomoaki AOKI wrote: >> Hi. >> >> By sets of commits starting from r351355 though r351747, nvd driver >> creates partitioned GEOM provider like /dev/nvd0p1. >> >> Unfortunately, these partitioned GEOM providers dissapears when >> importing ZFS pool on it leaving /dev/nvd0, and re-appears when >> exporting the pool. >> >> Mounting filesystems other than ZFS (at least msdosfs) doesn't >> affect. > > It is not ZFS itself, it is the use of /dev/diskid/*, which ZFS prefers > to open. > Either explicitly import the volume with /dev/nvd* or use the other > partitions with /dev/diskid/* > What really sucks is that volume labels also disappear - e.g. /dev/msdosfs. It Would Be Nice (tm) if all of the aliases were symlinks pointing to the canonical device which didn't disappear when it was opened. No idea how feasible that is though :) -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nvdXpY dissapears while ZFS pool on it is imported
On Sat, Oct 05, 2019 at 02:50:21PM +0900, Tomoaki AOKI wrote: > Hi. > > By sets of commits starting from r351355 though r351747, nvd driver > creates partitioned GEOM provider like /dev/nvd0p1. > > Unfortunately, these partitioned GEOM providers dissapears when > importing ZFS pool on it leaving /dev/nvd0, and re-appears when > exporting the pool. > > Mounting filesystems other than ZFS (at least msdosfs) doesn't > affect. It is not ZFS itself, it is the use of /dev/diskid/*, which ZFS prefers to open. Either explicitly import the volume with /dev/nvd* or use the other partitions with /dev/diskid/* What really sucks is that volume labels also disappear - e.g. /dev/msdosfs. > > > Details: > > I recently got ThinkPad P52 having one NVMe SSD and one 2.5 inch > SATA SSD. > NVMe SSD has stable/12 and SATA SSD has head on it. > Both are partitioned and installed on old ThinkPad T420, using > UltraBay slim adapter for SATA, and USB converter for NVMe, > without using installer and placed into P52, removing Windoze HDD. > Both are ROOT-on-ZFS. > Swap on NVMe SSD is specified using diskid in fstab. > > At first, I didn't noticed the problem as head with before-mentioned > commits gracefully creates nvd0p*. > But I noticed stable/12 having before-mentioned commits MFC'ed > (r351903 through r351914) creates only nvd0 just as before. > > Importing pool on SATA SSD from stable/12 on NVMe does NOT affect. > > I tried importing on NVMe SSD from head on SATA, and noticed > nvd0p* disappears leaving nvd0, and re-appears on export. > > Any solutions? > > Regards. > > -- > Tomoaki AOKI > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
nvdXpY dissapears while ZFS pool on it is imported
Hi. By sets of commits starting from r351355 though r351747, nvd driver creates partitioned GEOM provider like /dev/nvd0p1. Unfortunately, these partitioned GEOM providers dissapears when importing ZFS pool on it leaving /dev/nvd0, and re-appears when exporting the pool. Mounting filesystems other than ZFS (at least msdosfs) doesn't affect. Details: I recently got ThinkPad P52 having one NVMe SSD and one 2.5 inch SATA SSD. NVMe SSD has stable/12 and SATA SSD has head on it. Both are partitioned and installed on old ThinkPad T420, using UltraBay slim adapter for SATA, and USB converter for NVMe, without using installer and placed into P52, removing Windoze HDD. Both are ROOT-on-ZFS. Swap on NVMe SSD is specified using diskid in fstab. At first, I didn't noticed the problem as head with before-mentioned commits gracefully creates nvd0p*. But I noticed stable/12 having before-mentioned commits MFC'ed (r351903 through r351914) creates only nvd0 just as before. Importing pool on SATA SSD from stable/12 on NVMe does NOT affect. I tried importing on NVMe SSD from head on SATA, and noticed nvd0p* disappears leaving nvd0, and re-appears on export. Any solutions? Regards. -- Tomoaki AOKI ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
