Re: diskid documentation
On Mon, Jun 02, 2014 at 03:27:06PM -0700, John-Mark Gurney wrote: Pawel Jakub Dawidek wrote this message on Mon, Jun 02, 2014 at 22:26 +0200: The problem is that GPT labels (or GPT IDs for that matter) should not be implemented within GLABEL. This is wrong. It should be implemented as part of GPART, so that GPART would create ada0p1, gpt/label and gptid/whatever. Opening one of those should not make the others disappear then. Only opening ada0 for writting would make them disappear. even gpart would be wrong IMO... What happens if there is another provider like GPART, but different, do they need to implement diskid creation too to prevent the same issue? Shouldn't geom be updated to say, this ident is an alias, everything you do w/ this, it's exactly the same as the other one? This would also have the advantage of possibly removing one layer in the call chain when dealing w/ IO. (or does GEOM has a pass-through flag that says, I don't do anything, just skip me?) As for disk IDs it definitely shouldn't be implemented in GPART or GLABEL. IMHO the right place is the DISK class - both ada0 and diskid-of-ada0 should exist on the same rights (two providers of one geom). This also would address your concern about additional layer. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com pgpUBPO31HwbW.pgp Description: PGP signature
Re: diskid documentation
On 02.06.2014 01:32, Adam McDougall wrote: Also, I believe it is only in 10.0-RELEASE and higher. Even if your kernel supports it, /dev/diskid will not exist if no hardware is found with supported strings (tested in a VM just now). Probably, they just disappeared like all other labels, when you got access to disk not through the label. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
On 2014-06-01 09:41, Michael W. Lucas wrote: Hi, I'm trying to track down the documentation for the /dev/diskid/blah device nodes. Is there a man page? It appears that this is a current-only thing, so I'm asking here? (At least, none of my 9.x or 10.x machines have /dev/diskid.) Thanks, ==ml diskid (also called disk_ident in sysctl, which is confusing) It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) I usually disable it, especially to make my 'zpool status' output prettier kern.geom.label.disk_ident.enable=0 kern.geom.label.gptid.enable=0 -- Allan Jude ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanj...@freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanj...@freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. Wait-- one type of one label can hide another? I thought a big point of labels was to remove ambiguity... ==ml -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
On Mon, 2 Jun 2014, Michael W. Lucas wrote: On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanj...@freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. Wait-- one type of one label can hide another? I thought a big point of labels was to remove ambiguity... Can't get more unambiguous than only having one label! The word to look for here is wither. When a device label name is opened exclusively (like mounting a device), other labels for that device are supposed to wither and disappear from view. (My understanding of this is incomplete. Garrett Wollman sent me a very nice explanation of how this works, which I have read but not enough times yet.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanjude at freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. I have seen this too, starting from a fresh install. The install process for stable/10 writes a /dev/gpt style label into /etc/fstab for the swap space, and that never gets used, because the /dev/diskid/ stuff appears to take precedence. I put the following into /boot/loader.conf to make the system more sane: kern.geom.label.disk_ident.enable=0 -Kurt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
On 06/02/14 08:50, Kurt Lidl wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanjude at freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. I have seen this too, starting from a fresh install. The install process for stable/10 writes a /dev/gpt style label into /etc/fstab for the swap space, and that never gets used, because the /dev/diskid/ stuff appears to take precedence. The installer doesn't actually do this. It would be kind of nice if it did, but the label code is fantastically unreliable (for the reason you mention as well as others). So, while it does set labels on the disk, it does not use them. -Nathan I put the following into /boot/loader.conf to make the system more sane: kern.geom.label.disk_ident.enable=0 -Kurt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanj...@freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. Wait-- one type of one label can hide another? I thought a big point of labels was to remove ambiguity... Surprisingly, yes... I didn't think about this, but it's true... A disk will get exported via two different devices, diskid and normal da/ada... The tasting will go through and create all the necessary sub devices, but the problem is that we now have two different paths, and if something opens the diskid path, then the da/ada paths all disappear... This sounds like we need to fix geom to bind the two together so that when one opens, the other doesn't disappear... The problem is that geom views them as two separate disks when in fact they are the same... someone who knows geom well should think about how to solve this problem, as diskid isn't the first time this has happened, just most prevalent w/ ZFS and diskid. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
On Mon, Jun 02, 2014 at 11:01:08AM -0700, John-Mark Gurney wrote: Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanj...@freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. Wait-- one type of one label can hide another? I thought a big point of labels was to remove ambiguity... Surprisingly, yes... I didn't think about this, but it's true... A disk will get exported via two different devices, diskid and normal da/ada... The tasting will go through and create all the necessary sub devices, but the problem is that we now have two different paths, and if something opens the diskid path, then the da/ada paths all disappear... This sounds like we need to fix geom to bind the two together so that when one opens, the other doesn't disappear... The problem is that geom views them as two separate disks when in fact they are the same... someone who knows geom well should think about how to solve this problem, as diskid isn't the first time this has happened, just most prevalent w/ ZFS and diskid. The problem is that GPT labels (or GPT IDs for that matter) should not be implemented within GLABEL. This is wrong. It should be implemented as part of GPART, so that GPART would create ada0p1, gpt/label and gptid/whatever. Opening one of those should not make the others disappear then. Only opening ada0 for writting would make them disappear. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com pgp8HNxiuiLpJ.pgp Description: PGP signature
Re: diskid documentation
On 06/02/14 13:26, Pawel Jakub Dawidek wrote: On Mon, Jun 02, 2014 at 11:01:08AM -0700, John-Mark Gurney wrote: Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanj...@freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. Wait-- one type of one label can hide another? I thought a big point of labels was to remove ambiguity... Surprisingly, yes... I didn't think about this, but it's true... A disk will get exported via two different devices, diskid and normal da/ada... The tasting will go through and create all the necessary sub devices, but the problem is that we now have two different paths, and if something opens the diskid path, then the da/ada paths all disappear... This sounds like we need to fix geom to bind the two together so that when one opens, the other doesn't disappear... The problem is that geom views them as two separate disks when in fact they are the same... someone who knows geom well should think about how to solve this problem, as diskid isn't the first time this has happened, just most prevalent w/ ZFS and diskid. The problem is that GPT labels (or GPT IDs for that matter) should not be implemented within GLABEL. This is wrong. It should be implemented as part of GPART, so that GPART would create ada0p1, gpt/label and gptid/whatever. Opening one of those should not make the others disappear then. Only opening ada0 for writting would make them disappear. Indeed. This would also fix some tasting races, allow programmatic retrieval of the label device from gpart, and expand label device support from GPT to all partition schemes supported by gpart (APM, for instance). -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
Pawel Jakub Dawidek wrote this message on Mon, Jun 02, 2014 at 22:26 +0200: On Mon, Jun 02, 2014 at 11:01:08AM -0700, John-Mark Gurney wrote: Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanj...@freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. Wait-- one type of one label can hide another? I thought a big point of labels was to remove ambiguity... Surprisingly, yes... I didn't think about this, but it's true... A disk will get exported via two different devices, diskid and normal da/ada... The tasting will go through and create all the necessary sub devices, but the problem is that we now have two different paths, and if something opens the diskid path, then the da/ada paths all disappear... This sounds like we need to fix geom to bind the two together so that when one opens, the other doesn't disappear... The problem is that geom views them as two separate disks when in fact they are the same... someone who knows geom well should think about how to solve this problem, as diskid isn't the first time this has happened, just most prevalent w/ ZFS and diskid. The problem is that GPT labels (or GPT IDs for that matter) should not be implemented within GLABEL. This is wrong. It should be implemented as part of GPART, so that GPART would create ada0p1, gpt/label and gptid/whatever. Opening one of those should not make the others disappear then. Only opening ada0 for writting would make them disappear. even gpart would be wrong IMO... What happens if there is another provider like GPART, but different, do they need to implement diskid creation too to prevent the same issue? Shouldn't geom be updated to say, this ident is an alias, everything you do w/ this, it's exactly the same as the other one? This would also have the advantage of possibly removing one layer in the call chain when dealing w/ IO. (or does GEOM has a pass-through flag that says, I don't do anything, just skip me?) -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
On 2014-06-02 10:45, Ryan Stone wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanj...@freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Exactly. It makes sense that ZFS sees the DiskID first or whatever, but why does the gpt label disappear entirely? -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: diskid documentation
On 2014-06-02 11:50, Kurt Lidl wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanjude at freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. I have seen this too, starting from a fresh install. The install process for stable/10 writes a /dev/gpt style label into /etc/fstab for the swap space, and that never gets used, because the /dev/diskid/ stuff appears to take precedence. I put the following into /boot/loader.conf to make the system more sane: kern.geom.label.disk_ident.enable=0 -Kurt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I have a patch for the installer that solves this issue by explicitly using /dev/adaXpY or adaXsYb etc I thought the label was a nice way to do it, but it backfired. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: diskid documentation
On 06/02/14 15:32, Allan Jude wrote: On 2014-06-02 11:50, Kurt Lidl wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanjude at freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. I have seen this too, starting from a fresh install. The install process for stable/10 writes a /dev/gpt style label into /etc/fstab for the swap space, and that never gets used, because the /dev/diskid/ stuff appears to take precedence. I put the following into /boot/loader.conf to make the system more sane: kern.geom.label.disk_ident.enable=0 -Kurt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I have a patch for the installer that solves this issue by explicitly using /dev/adaXpY or adaXsYb etc I thought the label was a nice way to do it, but it backfired. Oh, zfsboot uses labels? The UFS partition editor never has, mostly for this reason. Sorry for spreading misinformation -- I'm not really familiar with the ZFS code. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
On 2014-06-02 18:40, Nathan Whitehorn wrote: On 06/02/14 15:32, Allan Jude wrote: On 2014-06-02 11:50, Kurt Lidl wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanjude at freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. I have seen this too, starting from a fresh install. The install process for stable/10 writes a /dev/gpt style label into /etc/fstab for the swap space, and that never gets used, because the /dev/diskid/ stuff appears to take precedence. I put the following into /boot/loader.conf to make the system more sane: kern.geom.label.disk_ident.enable=0 -Kurt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I have a patch for the installer that solves this issue by explicitly using /dev/adaXpY or adaXsYb etc I thought the label was a nice way to do it, but it backfired. Oh, zfsboot uses labels? The UFS partition editor never has, mostly for this reason. Sorry for spreading misinformation -- I'm not really familiar with the ZFS code. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org It only used the labels for the fstab entry for swap. -- Allan Jude signature.asc Description: OpenPGP digital signature
diskid documentation
Hi, I'm trying to track down the documentation for the /dev/diskid/blah device nodes. Is there a man page? It appears that this is a current-only thing, so I'm asking here? (At least, none of my 9.x or 10.x machines have /dev/diskid.) Thanks, ==ml -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
On Sun, 2014-06-01 at 09:41 -0400, Michael W. Lucas wrote: Hi, I'm trying to track down the documentation for the /dev/diskid/blah device nodes. Is there a man page? It appears that this is a current-only thing, so I'm asking here? (At least, none of my 9.x or 10.x machines have /dev/diskid.) Thanks, ==ml I'm afraid not. In this case sys/geom/label/g_label_disk_ident.c *is* the documentation. sean bcc current@ cc geom@ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: diskid documentation
On 06/01/2014 10:17, Sean Bruno wrote: On Sun, 2014-06-01 at 09:41 -0400, Michael W. Lucas wrote: Hi, I'm trying to track down the documentation for the /dev/diskid/blah device nodes. Is there a man page? It appears that this is a current-only thing, so I'm asking here? (At least, none of my 9.x or 10.x machines have /dev/diskid.) Thanks, ==ml I'm afraid not. In this case sys/geom/label/g_label_disk_ident.c *is* the documentation. sean bcc current@ cc geom@ Also, I believe it is only in 10.0-RELEASE and higher. Even if your kernel supports it, /dev/diskid will not exist if no hardware is found with supported strings (tested in a VM just now). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
