Re: AHCI driver and static device names
CyberLeo Kitsana cyber...@cyberleo.net wrote: On 12/14/2011 03:18 PM, Rob wrote: Case in point. I have a system with 15 drives in it. I decided I wanted to install on the 2nd device instead of the 1st, but I partitioned all the other 14 drives. I completed installation and when to boot the system and it failed. Stupid me, the GPT boot loader found disk1 with a partitioning scheme but no fs. So, I popped out disk 1 and when to boot again. Hey, now it starts to boot only to fail to find the root fs because it's looking on ada1 and the fs is on ada0. That is a mess. Sounds like a bug in the BIOS or boot loader. The boot loader should be able to ask the BIOS for the device from which it read the boot code, and use that instead of just naively using the first available device in the system ... The BIOS does pass the BIOS disk number (0x80, 0x81, ...) to the bootloader. That's fine as long as the bootloader is using BIOS calls to read the disk, but how does the BIOS disk number get mapped, reliably, to an OS device identification? The BIOS can't do it, because it knows nothing about the OS, so the OS would have to do it = the OS must know a lot of detail about every BIOS on which it will ever run. This does not seem very practical, and that's at least part of the reason why labels were invented. I suppose if someone wanted to track down the official way of solving this problem, they could look into how Windows handles it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: AHCI driver and static device names
On 12/15/2011 10:02 AM, per...@pluto.rain.com wrote: I suppose if someone wanted to track down the official way of solving this problem, they could look into how Windows handles it. To my knowledge, Windows (XP, at least; probably others) labels the boot filesystem on install, and just probes all disks every boot for a filesystem with the given label. This is why you can move a Windows disk around with relative impunity (as long as the controller drivers are installed); but simply copying all those files to another filesystem (a-la dump/restore on BSD) never results in a bootable OS, even if you put them back in the same place. This is also why booting with two attached clones of the same Windows system disk is so fun. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: AHCI driver and static device names
On 12/3/11 11:04 AM, CyberLeo Kitsana wrote: To answer your question, though: You cannot combine GPT with glabel (or any other geom class that writes data to the first or last 34 sectors of a disk, like gmirror) due to layout conflicts. MBR and BSD schemes can be used, since they occupy only the first sectors of the device, and their monikers will be appended to the label. Thus, labeling a single-slice MBR disk (/dev/ada0) with 'test' would produce /dev/ada0, /dev/ada0s1, /dev/label/test, and /dev/label/tests1; nesting a BSD table within s1 would add /dev/ada0s1a and /dev/label/tests1a as well. Do gpt labels work the same as glabel, ie provide a static device name that can be acted upon with /etc/fstab, zfs, gmirror, etc? The other option seems to be to use tunefs or a partitioning tool to label each partition, which is even more ugly imo. Ugly how? Labels appear a lot more semantically elegant than the opaque 'ada4s1a' moniker. Ugly in that the driver has created a situation where we need workarounds to perform the tasks we need. *nix systems have always relied upon static device nodes, and using dynamic names without updating the relating tools/methods is ugly. The workarounds also could fail if someone forgets to perform them (specifically labels), since it's not necessary on just about any other *nix system. It's perfectly within reason to assume people will forget to apply a label when replacing a disk. Case in point. I have a system with 15 drives in it. I decided I wanted to install on the 2nd device instead of the 1st, but I partitioned all the other 14 drives. I completed installation and when to boot the system and it failed. Stupid me, the GPT boot loader found disk1 with a partitioning scheme but no fs. So, I popped out disk 1 and when to boot again. Hey, now it starts to boot only to fail to find the root fs because it's looking on ada1 and the fs is on ada0. That is a mess. This is not necessarily common, but also not uncommon. More likely is the case where you add a drive to the system and the above scenario plays out because the device names get re-ordered. I'm not sure the problem the dynamic device nodes intends to solve, but it's certainly caused all sorts of pain and the need for the 2 (that I know of) workarounds. I dislike the idea of having to use labels to get static functionality (increases the likelihood of something going wrong for a disk replace operation if I forget to label), but I'll give gpt labels a try. Rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: AHCI driver and static device names
Can glabels, gpt, and zfs all work together? I have a system where I have disks with 4 gpt partitions. Partitions 2 and 3 are part of gmirror arrays, and partition 4 is part of a zfs pool. glabel says it writes to the end of the partition, which I believe zfs also writes to doesn't it? Rob On 12/4/11 4:28 AM, per...@pluto.rain.com wrote: CyberLeo Kitsanacyber...@cyberleo.net wrote: You cannot combine GPT with glabel (or any other geom class that writes data to the first or last 34 sectors of a disk, like gmirror) due to layout conflicts. This is overstated. Since a GPT ordinarily is intended to be booted from, and so must be recognized by the BIOS, it must be written directly on the actual drive -- the rank 1 provider in GEOM terms -- because that is the only way for the GPT metadata to be located where the BIOS expects to find it (at both the beginning and the end of the drive). It is, however, possible to combine GPT with gmirror, gjournal, etc. by using GPT partitions, rather than drives, as providers for the other geoms. For example, create a mirror from ad0p1 and ad2p1 rather than from ad0 and ad2. Similarly, it should be possible to glabel a GPT partition -- although this seems unlikely to be useful in practice since GPT provides its own labelling scheme. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: AHCI driver and static device names
On 12/14/2011 03:20 PM, Rob wrote: Can glabels, gpt, and zfs all work together? I have a system where I have disks with 4 gpt partitions. Partitions 2 and 3 are part of gmirror arrays, and partition 4 is part of a zfs pool. glabel says it writes to the end of the partition, which I believe zfs also writes to doesn't it? Yup. However, all nestable geoms protect their metadata (when it exists) by providing a device that is smaller, so any nested consumer never even sees the provider's metadata. The end of the glabel device to which zfs writes its metadata in your implied example is actually several sectors prior to the end of the device or partition to which glabel writes its metadata. Explicit glabels are not strictly necessary with the GPT partitioning scheme, since the glabel module can peek into the GPT data structure, extract label names from there, and automatically create appropriate /dev/gpt/ entries for those labels. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: AHCI driver and static device names
On 12/14/2011 03:18 PM, Rob wrote: On 12/3/11 11:04 AM, CyberLeo Kitsana wrote: To answer your question, though: You cannot combine GPT with glabel (or any other geom class that writes data to the first or last 34 sectors of a disk, like gmirror) due to layout conflicts. MBR and BSD schemes can be used, since they occupy only the first sectors of the device, and their monikers will be appended to the label. Thus, labeling a single-slice MBR disk (/dev/ada0) with 'test' would produce /dev/ada0, /dev/ada0s1, /dev/label/test, and /dev/label/tests1; nesting a BSD table within s1 would add /dev/ada0s1a and /dev/label/tests1a as well. Do gpt labels work the same as glabel, ie provide a static device name that can be acted upon with /etc/fstab, zfs, gmirror, etc? Yes. It's actually handled by the same geom class. The other option seems to be to use tunefs or a partitioning tool to label each partition, which is even more ugly imo. Ugly how? Labels appear a lot more semantically elegant than the opaque 'ada4s1a' moniker. Ugly in that the driver has created a situation where we need workarounds to perform the tasks we need. *nix systems have always relied upon static device nodes, and using dynamic names without updating the relating tools/methods is ugly. The workarounds also could fail if someone forgets to perform them (specifically labels), since it's not necessary on just about any other *nix system. It's perfectly within reason to assume people will forget to apply a label when replacing a disk. Anything fails if you forget to do it. Administrative failure should not be confused with technical failure. Static device nodes are appropriate when the topology is fixed and can be reasonably anticipated. With variable topologies, such as USB, iSCSI, multipath, and PCI hotswap, the disk controllers may not even exist at boot, or may be reordered based on probe order, or the order in which the remote units respond; and that's before the kernel even gets around to setting up the devices attached to those controllers. You cannot reasonably expect the system to statically allocate device nodes for every possible configuration that may exist for all technologies that might be added to a machine, so why offer the expectation when the system cannot possibly hope to fulfill it for even a fraction of the common cases? Case in point. I have a system with 15 drives in it. I decided I wanted to install on the 2nd device instead of the 1st, but I partitioned all the other 14 drives. I completed installation and when to boot the system and it failed. Stupid me, the GPT boot loader found disk1 with a partitioning scheme but no fs. So, I popped out disk 1 and when to boot again. Hey, now it starts to boot only to fail to find the root fs because it's looking on ada1 and the fs is on ada0. That is a mess. Sounds like a bug in the BIOS or boot loader. The boot loader should be able to ask the BIOS for the device from which it read the boot code, and use that instead of just naively using the the first available device in the system; the only instances where I've seen this fail have been on machines that should've been put down years ago. Which isn't to say it doesn't still happen. This is not necessarily common, but also not uncommon. More likely is the case where you add a drive to the system and the above scenario plays out because the device names get re-ordered. I'm not sure the problem the dynamic device nodes intends to solve, but it's certainly caused all sorts of pain and the need for the 2 (that I know of) workarounds. How about when you add a PATA drive to a machine, but the cable is blocking the last available bay; so you have to move an existing drive to a different position on the cable to make room for the one you're installing? Static device numbering won't save you now. Or how about those silly BIOSes that assume that you must really want to boot to the new disk you just attached to the machine, so helpfully rearrange your boot order for you so now you're booting to a strange disk with who knows what on it? Honestly, there's so much that can go wrong. That's what sysadmins are for. I dislike the idea of having to use labels to get static functionality (increases the likelihood of something going wrong for a disk replace operation if I forget to label), but I'll give gpt labels a try. I find that labels solve more problems than they introduce, when applied properly. The semantic meaning given to the devices often mean I can discover what's on a particular disk in my pile'o'drives just by plugging it in and looking at the kernel log; no mounting necessary. Likewise, when juggling disks or controllers around, I don't have to worry about remembering to update the fstab, since the labels follow the data. This is a lot better than my Linux machine, where I have to do some rather interesting hacks in the initrd just to make sure the root mirror is
Re: AHCI driver and static device names
On 12/14/11 8:05 PM, CyberLeo Kitsana wrote: The other option seems to be to use tunefs or a partitioning tool to label each partition, which is even more ugly imo. Ugly how? Labels appear a lot more semantically elegant than the opaque 'ada4s1a' moniker. Ugly in that the driver has created a situation where we need workarounds to perform the tasks we need. *nix systems have always relied upon static device nodes, and using dynamic names without updating the relating tools/methods is ugly. The workarounds also could fail if someone forgets to perform them (specifically labels), since it's not necessary on just about any other *nix system. It's perfectly within reason to assume people will forget to apply a label when replacing a disk. Anything fails if you forget to do it. Administrative failure should not be confused with technical failure. When you're changing a paradigm that is known to administrators for decades, it's unreasonable not to expect a decent degree of failure. Especially when the reason for the technical change isn't clear and the new method isn't at all like the old (ie no disk is guaranteed to get the same id). Static device nodes are appropriate when the topology is fixed and can be reasonably anticipated. With variable topologies, such as USB, iSCSI, multipath, and PCI hotswap, the disk controllers may not even exist at boot, or may be reordered based on probe order, or the order in which the remote units respond; and that's before the kernel even gets around to setting up the devices attached to those controllers. You cannot reasonably expect the system to statically allocate device nodes for every possible configuration that may exist for all technologies that might be added to a machine, so why offer the expectation when the system cannot possibly hope to fulfill it for even a fraction of the common cases? I grant you variable topologies makes things incredibly hairy, but there's no need to take that mess and inject it into how the fixed topology (the physical hw in the box) is handled. Trying to handle all topology types in a single space can be messy. This problem wouldn't exist if a fixed topology used the old naming (adXX) and the variable topologies used the new naming (adaXX). Even this is less than ideal because your variable topologies provide no guarantee of anything being the same, thus your system could boot 1 day and fail the next because someone added a new piece of hardware to the network. That's probably more the name of the game in variable topologies (adminA changes the configuration on $ImportantBootDevice and stuff breaks), but I certainly don't want that uncertainty with the hardware in a machine. I stated that updating the device naming w/o updating the methodologies that rely upon that device naming is asking for trouble. I can't say I know a solution nor that I'm an expert, but this seems like it will cause many more problems than it will solve. Case in point. I have a system with 15 drives in it. I decided I wanted to install on the 2nd device instead of the 1st, but I partitioned all the other 14 drives. I completed installation and when to boot the system and it failed. Stupid me, the GPT boot loader found disk1 with a partitioning scheme but no fs. So, I popped out disk 1 and when to boot again. Hey, now it starts to boot only to fail to find the root fs because it's looking on ada1 and the fs is on ada0. That is a mess. Sounds like a bug in the BIOS or boot loader. The boot loader should be able to ask the BIOS for the device from which it read the boot code, and use that instead of just naively using the the first available device in the system; the only instances where I've seen this fail have been on machines that should've been put down years ago. Which isn't to say it doesn't still happen. No bug in the BIOS at all. It's simply a case of device boot order, and being that I installed on disk 2 but put a bootloader on disk 1 with no OS the result was expected. This is not necessarily common, but also not uncommon. More likely is the case where you add a drive to the system and the above scenario plays out because the device names get re-ordered. I'm not sure the problem the dynamic device nodes intends to solve, but it's certainly caused all sorts of pain and the need for the 2 (that I know of) workarounds. How about when you add a PATA drive to a machine, but the cable is blocking the last available bay; so you have to move an existing drive to a different position on the cable to make room for the one you're installing? Static device numbering won't save you now. This is not the same thing at all. If I move a physical cable, or a drive on a cable, then yes I should expect things to change. I have made a physical change to the disk's connections, and I should expect something to come out of it. In my case, I have not moved the cabling of a disk at all and thus expect the
Re: AHCI driver and static device names
On 2011/12/03 at 10:51, Rob li...@midsummerdream.org wrote: I was getting ready to install the latest FreeBSD 9-RCs image, and I found that 9 now defaults to using the ahci driver for sata disks. This would be great if it weren't for the fact that the ahci driver seems to do dynamic device name assignment as opposed to the static ones used with the older drivers. I've looked around on google and while this is mentioned (in old threads), the solution is to use labels or elaborate mapping via hints which really aren't solutions imo. If I have 15 disks in an array, I want to be able to label them and know which bay is which device name. If I have to replace a drive, I have no idea what dynamic device name it will have when it comes time to partition (and label, if I were using that). I could probably figure it out by looking at what disks are used on the system, but that's more work that it really should be. It seems AHCI driver uses static naming policies if you have 'options ATA_STATIC_ID' in your kernel configuration. Anyway, I just have one SATA disk, which the system recognizes as 'ada4'. I don't know whether this will apply in your case. Is there a way to use the ahci driver and get static device names? Rob -- The first page the author turns to upon receiving an advance copy will be the page containing the worst error. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: AHCI driver and static device names
glabel looks to place a label on the whole disk, but the manpage is unclear (to me) how the partitions are handled. If I use glabel to label a disk test and this disk has 4 partitions on it, then how is each partition accessed? testp1...testp4 for gpt? The other option seems to be to use tunefs or a partitioning tool to label each partition, which is even more ugly imo. Rob On 12/2/11 9:27 PM, Derrick Ryalls wrote: Look for disk labels, I think glabel is the command. Then you use /dev/label/mylabel etc for the disks. Let me know if this isn't enough to find the right man page or spot in the handbook. I use it in my raid array but am running short on time right now. On Fri, Dec 2, 2011 at 6:51 PM, Rob li...@midsummerdream.org mailto:li...@midsummerdream.org wrote: I was getting ready to install the latest FreeBSD 9-RCs image, and I found that 9 now defaults to using the ahci driver for sata disks. This would be great if it weren't for the fact that the ahci driver seems to do dynamic device name assignment as opposed to the static ones used with the older drivers. I've looked around on google and while this is mentioned (in old threads), the solution is to use labels or elaborate mapping via hints which really aren't solutions imo. If I have 15 disks in an array, I want to be able to label them and know which bay is which device name. If I have to replace a drive, I have no idea what dynamic device name it will have when it comes time to partition (and label, if I were using that). I could probably figure it out by looking at what disks are used on the system, but that's more work that it really should be. Is there a way to use the ahci driver and get static device names? Rob _ freebsd-questions@freebsd.org mailto:freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/__mailman/listinfo/freebsd-__questions http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-__unsubscr...@freebsd.org mailto:freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: AHCI driver and static device names
Is there a loader.conf entry to enable the static ids, or will the ahci driver always use static ids if options ATA_STATIC_ID is in the kernel config? I desire to use stock kernels and the 9-rc2 boot iso seems to not have ATA_STATID_ID set (unless there's a loader.conf value to enable the functionality) Rob On 12/3/11 3:44 AM, Denise H. G. wrote: On 2011/12/03 at 10:51, Robli...@midsummerdream.org wrote: I was getting ready to install the latest FreeBSD 9-RCs image, and I found that 9 now defaults to using the ahci driver for sata disks. This would be great if it weren't for the fact that the ahci driver seems to do dynamic device name assignment as opposed to the static ones used with the older drivers. I've looked around on google and while this is mentioned (in old threads), the solution is to use labels or elaborate mapping via hints which really aren't solutions imo. If I have 15 disks in an array, I want to be able to label them and know which bay is which device name. If I have to replace a drive, I have no idea what dynamic device name it will have when it comes time to partition (and label, if I were using that). I could probably figure it out by looking at what disks are used on the system, but that's more work that it really should be. It seems AHCI driver uses static naming policies if you have 'options ATA_STATIC_ID' in your kernel configuration. Anyway, I just have one SATA disk, which the system recognizes as 'ada4'. I don't know whether this will apply in your case. Is there a way to use the ahci driver and get static device names? Rob ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: AHCI driver and static device names
On 12/03/2011 10:04 AM, Rob wrote: glabel looks to place a label on the whole disk, but the manpage is unclear (to me) how the partitions are handled. If I use glabel to label a disk test and this disk has 4 partitions on it, then how is each partition accessed? testp1...testp4 for gpt? Ideally, you would label the partitions according to their usage. glabel will automatically create labels for GPT partitions based on the GPT 'label' field; likewise for UFS, MSDOS, and ISO9660 filesystems. For example, one of my (few remaining non-ZFS) machines looks like this: 8 /dev/iso9660/root on / (cd9660, local, read-only) /dev/ufs/boot on /boot (ufs, local, read-only) /dev/ufs/conf on /conf (ufs, local, read-only, soft-updates) 8 The root filesystem on this machine is actually mounted off a uzip-compressed iso image on a BSD partition burned to some flash; but the unimportant details are hidden behind the label, which just presents a plain filesystem. It doesn't really matter where these filesystems are: they can be moved to completely different disks with wildly different partition schemes, or even to iscsi- or ggate-imported disks, and the system will find them perfectly by their labels. This works for ZFS as well: since there's no guarantee where these disks will show up, and the ZFS code will not be able to find them across reboots if their names change, labels are useful for assigning static names to the partitions or slices that make up a pool: 8 pool: amani state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM amani ONLINE 0 0 0 mirror ONLINE 0 0 0 gpt/amani/r0 ONLINE 0 0 0 gpt/amani/r1 ONLINE 0 0 0 8 To answer your question, though: You cannot combine GPT with glabel (or any other geom class that writes data to the first or last 34 sectors of a disk, like gmirror) due to layout conflicts. MBR and BSD schemes can be used, since they occupy only the first sectors of the device, and their monikers will be appended to the label. Thus, labeling a single-slice MBR disk (/dev/ada0) with 'test' would produce /dev/ada0, /dev/ada0s1, /dev/label/test, and /dev/label/tests1; nesting a BSD table within s1 would add /dev/ada0s1a and /dev/label/tests1a as well. The other option seems to be to use tunefs or a partitioning tool to label each partition, which is even more ugly imo. Ugly how? Labels appear a lot more semantically elegant than the opaque 'ada4s1a' moniker. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: AHCI driver and static device names
I was getting ready to install the latest FreeBSD 9-RCs image, and I found that 9 now defaults to using the ahci driver for sata disks. This would be great if it weren't for the fact that the ahci driver seems to do dynamic device name assignment as opposed to the static ones used with the older drivers. I've looked around on google and while this is mentioned (in old threads), the solution is to use labels or elaborate mapping via hints which really aren't solutions imo. If I have 15 disks in an array, I want to be able to label them and know which bay is which device name. If I have to replace a drive, I have no idea what dynamic device name it will have when it comes time to partition (and label, if I were using that). I could probably figure it out by looking at what disks are used on the system, but that's more work that it really should be. Is there a way to use the ahci driver and get static device names? cam(4) gives examples of how you can do this by using device hints in loader.conf(5) or device.hints(5). Another example: http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html You may need the workaround from: http://svn.freebsd.org/changeset/base/227635 for some problematic BIOS. I'm not sure if this is what you meant by hints which aren't really solutions, but they seem to be a practical method for fixing device names with ahci(4). b. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: AHCI driver and static device names
CyberLeo Kitsana cyber...@cyberleo.net wrote: You cannot combine GPT with glabel (or any other geom class that writes data to the first or last 34 sectors of a disk, like gmirror) due to layout conflicts. This is overstated. Since a GPT ordinarily is intended to be booted from, and so must be recognized by the BIOS, it must be written directly on the actual drive -- the rank 1 provider in GEOM terms -- because that is the only way for the GPT metadata to be located where the BIOS expects to find it (at both the beginning and the end of the drive). It is, however, possible to combine GPT with gmirror, gjournal, etc. by using GPT partitions, rather than drives, as providers for the other geoms. For example, create a mirror from ad0p1 and ad2p1 rather than from ad0 and ad2. Similarly, it should be possible to glabel a GPT partition -- although this seems unlikely to be useful in practice since GPT provides its own labelling scheme. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: AHCI driver and static device names
On 12/04/2011 04:28 AM, per...@pluto.rain.com wrote: CyberLeo Kitsana cyber...@cyberleo.net wrote: You cannot combine GPT with glabel (or any other geom class that writes data to the first or last 34 sectors of a disk, like gmirror) due to layout conflicts. This is overstated. Thanks for the clarification. It occurs to me now that I was less than precise. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://.fur.com/peace/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
