Re: Switch from legacy ata(4) to CAM-based ATA
On 6 May 2011 12:33, Alexander Motin m...@freebsd.org wrote: Sergey Kandaurov wrote: XENHVM uses it's own naming scheme and can name disks as daN or adN, depending on virtual block device id. atapci0/ata0/ata1 devices still present there (such as in Bruce Cran's dmesg), but no any disks attached from it: instead, all of them hung from device/vbd/N. [In a non-XENHVM mode they are attached from ataN channels, as usual.] /* * Translate Linux major/minor to an appropriate name and unit * number. For HVM guests, this allows us to use the same drive names * with blkfront as the emulated drives, easing transition slightly. */ xenbusb_front0: Xen Frontend Devices on xenstore0 xenbusb_back0: Xen Backend Devices on xenstore0 xctrl0: Xen Control Device on xenstore0 xbd0: 17000MB Virtual Block Device at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s). xbd1: 3812MB Virtual Block Device at device/vbd/2048 on xenbusb_front0 xbd1: attaching as da0 xbd2: 114439MB Virtual Block Device at device/vbd/2064 on xenbusb_front0 xbd2: attaching as da1 OK, interesting question. I have built amd64 XENHVM kernel and booted it under Xen 3.2. As result I've got double set of devices, via both atapci0/ata0 and via blkfront: ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: QEMU HARDDISK 0.9.0 ATA-7 device ada0: Serial Number QM1 ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: QEMU HARDDISK 0.9.0 ATA-7 device ada1: Serial Number QM2 ada1: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 xbd0: 476940MB Virtual Block Device at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 xbd1: 476940MB Virtual Block Device at device/vbd/832 on xenbusb_front0 xbd1: attaching as ad1 Both of them were exported to GEOM. Extra set of adX devices caused error messages. What am I doing wrong and why have I got those duplicates? Was I required to remove non-PV drivers from my kernel? Doh. This corresponds to errors omitted unintentionally in my previous mail. This is right after xbd2: attaching as da1: da0 at sym0 bus 0 scbus2 target 0 lun 0 da0: QEMU QEMU HARDDISK 0.10 Fixed Direct Access SCSI-3 device da0: 3.300MB/s transfers da0: Command Queueing enabled da0: 3812MB (7807527 512 byte sectors: 255H 63S/T 485C) can't re-use a leaf (led)! g_dev_taste: make_dev_p() failed (gp-name=da0, error=17) da1 at sym0 bus 0 scbus2 target 1 lun 0 da1: QEMU QEMU HARDDISK 0.10 Fixed Direct Access SCSI-3 device da1: 3.300MB/s transfers da1: Command Queueing enabled da1: 114439MB (23437 512 byte sectors: 255H 63S/T 14588C) can't re-use a leaf (led)! g_dev_taste: make_dev_p() failed (gp-name=da1, error=17) No ada devices detected though. -- wbr, pluknet ___ 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: Switch from legacy ata(4) to CAM-based ATA
Sergey Kandaurov wrote: On 6 May 2011 12:33, Alexander Motin m...@freebsd.org wrote: Sergey Kandaurov wrote: XENHVM uses it's own naming scheme and can name disks as daN or adN, depending on virtual block device id. atapci0/ata0/ata1 devices still present there (such as in Bruce Cran's dmesg), but no any disks attached from it: instead, all of them hung from device/vbd/N. [In a non-XENHVM mode they are attached from ataN channels, as usual.] /* * Translate Linux major/minor to an appropriate name and unit * number. For HVM guests, this allows us to use the same drive names * with blkfront as the emulated drives, easing transition slightly. */ xenbusb_front0: Xen Frontend Devices on xenstore0 xenbusb_back0: Xen Backend Devices on xenstore0 xctrl0: Xen Control Device on xenstore0 xbd0: 17000MB Virtual Block Device at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s). xbd1: 3812MB Virtual Block Device at device/vbd/2048 on xenbusb_front0 xbd1: attaching as da0 xbd2: 114439MB Virtual Block Device at device/vbd/2064 on xenbusb_front0 xbd2: attaching as da1 OK, interesting question. I have built amd64 XENHVM kernel and booted it under Xen 3.2. As result I've got double set of devices, via both atapci0/ata0 and via blkfront: ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: QEMU HARDDISK 0.9.0 ATA-7 device ada0: Serial Number QM1 ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: QEMU HARDDISK 0.9.0 ATA-7 device ada1: Serial Number QM2 ada1: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 xbd0: 476940MB Virtual Block Device at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 xbd1: 476940MB Virtual Block Device at device/vbd/832 on xenbusb_front0 xbd1: attaching as ad1 Both of them were exported to GEOM. Extra set of adX devices caused error messages. What am I doing wrong and why have I got those duplicates? Was I required to remove non-PV drivers from my kernel? Doh. This corresponds to errors omitted unintentionally in my previous mail. This is right after xbd2: attaching as da1: da0 at sym0 bus 0 scbus2 target 0 lun 0 da0: QEMU QEMU HARDDISK 0.10 Fixed Direct Access SCSI-3 device da0: 3.300MB/s transfers da0: Command Queueing enabled da0: 3812MB (7807527 512 byte sectors: 255H 63S/T 485C) can't re-use a leaf (led)! g_dev_taste: make_dev_p() failed (gp-name=da0, error=17) da1 at sym0 bus 0 scbus2 target 1 lun 0 da1: QEMU QEMU HARDDISK 0.10 Fixed Direct Access SCSI-3 device da1: 3.300MB/s transfers da1: Command Queueing enabled da1: 114439MB (23437 512 byte sectors: 255H 63S/T 14588C) can't re-use a leaf (led)! g_dev_taste: make_dev_p() failed (gp-name=da1, error=17) No ada devices detected though. But you have duplicate daX here. It is just the same, except that you have different Xen configuration -- disks configured as SCSI instead of ATA. So the question is the same: how this supposed to work? To me, that double detection problem seems much more significant then names change. -- Alexander Motin ___ 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: Switch from legacy ata(4) to CAM-based ATA
2011/4/20 Alexander Motin m...@freebsd.org: Hi. With 9.0 release approaching quickly, I believe it the best time now to manage migration from legacy ata(4) ATA to the new CAM-based one. New ATA code present in the tree for more then a year now, used by many people and proved it's superior functionality and reliability. The only major issue with it now is the migration process. Sooner or later we have to pass it, but due to major UI and API changes we can't do it after 9.0 release. So I propose to do it the next Sunday (April 24) to have as much time for troubleshooting as possible. I have prepared the following patch to do it: http://people.freebsd.org/~mav/ata_switch.patch I haven't added geom_raid to the kernel configurations because we have no other GEOM classes there. But tell me if you thing I should. If somebody has any problems with new ATA stack, please repeat your tests with latest HEAD code and contact me if problem is still there. Next three weeks before BSDCan I am going to dedicate to fixing possibly remaining issues. XENHVM uses it's own naming scheme and can name disks as daN or adN, depending on virtual block device id. atapci0/ata0/ata1 devices still present there (such as in Bruce Cran's dmesg), but no any disks attached from it: instead, all of them hung from device/vbd/N. [In a non-XENHVM mode they are attached from ataN channels, as usual.] /* * Translate Linux major/minor to an appropriate name and unit * number. For HVM guests, this allows us to use the same drive names * with blkfront as the emulated drives, easing transition slightly. */ xenbusb_front0: Xen Frontend Devices on xenstore0 xenbusb_back0: Xen Backend Devices on xenstore0 xctrl0: Xen Control Device on xenstore0 xbd0: 17000MB Virtual Block Device at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s). xbd1: 3812MB Virtual Block Device at device/vbd/2048 on xenbusb_front0 xbd1: attaching as da0 xbd2: 114439MB Virtual Block Device at device/vbd/2064 on xenbusb_front0 xbd2: attaching as da1 Probably, /sys/dev/xen/blkfront/blkfront.c needs updating by s/ad/ada/g; or such. I believe, xen generates sequential numbers starting from zero (or rather such numbers that can be converted to sequential numbers), similar to what ATA_CAM does. -- wbr, pluknet ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, 20 Apr 2011 12:57:47 +0300, Alexander Motin wrote: AM If somebody has any problems with new ATA stack, please repeat your AM tests with latest HEAD code and contact me if problem is still there. AM Next three weeks before BSDCan I am going to dedicate to fixing possibly AM remaining issues. On motherboard MSI MS-7210 no HDD detected with new GENERIC (r221012). In dmesg I see line like: device_attach: ahci0 attach returned 6 (I have no serial console cable and can't capture full dmesg). From pciconf -vlbc (when I boot with old ata) atapci1@pci0:0:31:2:class=0x01018f card=0x72101462 chip=0x27c08086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0xe880, size 8, enabled bar [14] = type I/O Port, range 32, base 0xe800, size 4, enabled bar [18] = type I/O Port, range 32, base 0xe480, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xe400, size 4, enabled bar [20] = type I/O Port, range 32, base 0xe080, size 16, enabled cap 01[70] = powerspec 2 supports D0 D3 current D0 -- WBR, Anton Yuzhaninov ___ 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: Switch from legacy ata(4) to CAM-based ATA
On 21.04.2011 13:26, Alexander Motin wrote: Marius Strobl wrote: On Wed, Apr 20, 2011 at 12:57:47PM +0300, Alexander Motin wrote: With 9.0 release approaching quickly, I believe it the best time now to manage migration from legacy ata(4) ATA to the new CAM-based one. New ATA code present in the tree for more then a year now, used by many people and proved it's superior functionality and reliability. The only major issue with it now is the migration process. Sooner or later we have to pass it, but due to major UI and API changes we can't do it after 9.0 release. So I propose to do it the next Sunday (April 24) to have as much time for troubleshooting as possible. I have prepared the following patch to do it: http://people.freebsd.org/~mav/ata_switch.patch Could you please add descriptions of the controllers supported by ahci(4), mvs(4) and siis(4) to the kernel configuration files and preserve alphabetical ordering, i.e. list ata(4) after ahci(4)? OK. Here is the new patch: http://people.freebsd.org/~mav/ata_switch2.patch Patch committed. Welcome to the new world! :) -- Alexander Motin ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Apr 23, 2011, at 10:36 AM, sth...@nethelp.no wrote: In other words, ada isn't the problem here, it's that we all still think in terms of the 1980's when systems didn't autoconfigure and device names were important hints to system functionality. That time has thankfully passed, and it's time for us to catch up. If this is important for disk type devices, why not also for network type devices? Why don't we all use ethX like Linux does? I'd really like to see that as well, but there were strong disagreements when I floated the idea 4 years ago. Personally I *like* knowing something about the underlying type of device and technology - but I can definitely see both sides of the argument here. Indeed, there's nothing wrong with preserving access to the system details for the use of administration, troubleshooting, and even mere geeky knowledge. This isn't about taking power away from the superusers, it's about making the system smart enough to handle common situations reliably. I'm sure that there some among us who pine for the good old days of manually configuring and linking a kernel, but it's hard to argue that an auto-configured kernel isn't pretty darn convenient most of the time. What I'm proposing is just the next step in that process. Scott___ 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: Switch from legacy ata(4) to CAM-based ATA
On Sun, Apr 24, 2011 at 1:54 PM, Scott Long sco...@samsco.org wrote: Indeed, there's nothing wrong with preserving access to the system details for the use of administration, troubleshooting, and even mere geeky knowledge. This isn't about taking power away from the superusers, it's about making the system smart enough to handle common situations reliably. I'm sure that there some among us who pine for the good old days of manually configuring and linking a kernel, but it's hard to argue that an auto-configured kernel isn't pretty darn convenient most of the time. What I'm proposing is just the next step in that process. For me, your proposal would make life more difficult as it is on Linux. I've had to do more deployment/autoconfig setups recently and FreeBSD's method of device naming makes it much easier for me to deal with. I like the fact I easily know what disk is attached to what controller and what NIC driver is in use. The NIC specific naming is more useful than disk controller, but both have their places for me. It makes tweaking/troubleshooting quicker in some situations. In fact, I would like even more of it it, eg /dev/usbda0. What a disk is called is already different(for me) than what is in fstab since some(maybe many?) people are already using some of the abstraction methods currently available. If a sys-admin makes an effort, a consistent fstab is pretty easily achieved but it's better done by pre-deployment planning rather than after. If one of the new installer proposals handled this automatically, even better. My point is that device names are still an important hint to functionality particularly for auto-deployment/configure settings where specific hardware isn't always known ahead of time. -- Adam Vande More ___ 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: Switch from legacy ata(4) to CAM-based ATA
Hi, On Sun, Apr 24, 2011 at 5:04 AM, Alexander Motin m...@freebsd.org wrote: Patch committed. Welcome to the new world! :) What transition plan do you provide ? Drop in single-user-mode and fix /etc/fstab ? Forbid anybody without ATA_CAM in their 8.x config to be able to switch between 8 and 9 ? Thanks, - Arnaud ___ 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: Switch from legacy ata(4) to CAM-based ATA
Hi, On Thu, Apr 21, 2011 at 3:51 AM, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: [...] I agree that we need to catch up with something but we should have done so a year ago. a) we MUST HAVE a transition scheme if we cam-base ATA by default. Something that converts things automatically to whatever? That's not been done in more than one year. It's not acceptable to update, reboot and not find the root file system no matter what. We all agreed on that back then. I do not really care how it's done. I have been testing cam based ata for a while now on the machines I can cope with as a developer and even then I screwed the transition partly two times in the last months. How's a normal user to do that flawlessly? For the record, it would seem that Alexander did not provide any follow-up to this message, but still decided to go forward. I would be interested to have his answer to your question. Thanks, - Arnaud b) FYI: labels and stacked geoms do not work well together as you can never detach providers cleanly then, which basically means you are at risk of data loss with every reboot. I was told multiple times that this is not fixable. If it is labels seem to be a great why to go. For now I have to compile them out/disable them unfortunately so they are not an option, and they'll be less so if the new installer also offers gmirror, geli, ... installs. Give me a solution that works out of the box and I'll happily agree that we switch. FWIW, so do I. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: Switch from legacy ata(4) to CAM-based ATA
In other words, ada isn't the problem here, it's that we all still think in terms of the 1980's when systems didn't autoconfigure and device names were important hints to system functionality. That time has thankfully passed, and it's time for us to catch up. If this is important for disk type devices, why not also for network type devices? Why don't we all use ethX like Linux does? Personally I *like* knowing something about the underlying type of device and technology - but I can definitely see both sides of the argument here. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Apr 20, 2011, at 10:18 PM, Scott Long wrote: On Apr 20, 2011, at 2:50 PM, Alexander Motin wrote: Ulrich Spörlein wrote: Can we then please get the ad device prefix back? I seem to remember that when they were introduced they were thought to be a temporary thing ... Unless both stacks can run in parallel, I don't see a problem with having them both show up as /dev/ad0, etc. People with problems must send in a complete dmesg anyway, so it should be clear what stack they are running. The POLA violation for people upgrading from 8.x to 9.0 however is pretty big ... and unnecessary. Stacks do can run in parallel, and it really happens when people loading ahci(4) driver for SATA disks without using `options ATA_CAM` of ata(4) for PATA. As result, SATA will use new stack and PATA - old one. What's about POLA violation, it is inevitable, because present kernel uses ata(4) with ATA_STATIC_ID option, that is not applicable in modern SATA world order. So at least device numbers will change. Also you should take into account, that many people and some software already adapted to adaX names and change back will break POLA for them. I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using either mount-by-label, or be working to introduce generic device names to GEOM. Right now, device names are an implementation detail that have no functional use other than to complicate the fstab. Disks exposed through the block layer are simply direct-access block-array devices, nothing more. There's no functional difference to the kernel or userland between ad, ar, da, aacd, mfid, amrd, etc when it comes to reading and writing sectors off of them. But yet we give them unique names and pretend that those names mean something. We could give them all the name of disk and the system would still function exactly that same. The name attributes are interesting when it comes to doing out-of-band management, but it's also trivial to create a human-readable map and a programatic API between the generic name and the attribute name. Same goes for volumes labels, and I'd almost argue that they're more powerful than generic device names. In other words, ada isn't the problem here, it's that we all still think in terms of the 1980's when systems didn't autoconfigure and device names were important hints to system functionality. That time has thankfully passed, and it's time for us to catch up. I agree that we need to catch up with something but we should have done so a year ago. a) we MUST HAVE a transition scheme if we cam-base ATA by default. Something that converts things automatically to whatever? That's not been done in more than one year. It's not acceptable to update, reboot and not find the root file system no matter what. We all agreed on that back then. I do not really care how it's done. I have been testing cam based ata for a while now on the machines I can cope with as a developer and even then I screwed the transition partly two times in the last months. How's a normal user to do that flawlessly? b) FYI: labels and stacked geoms do not work well together as you can never detach providers cleanly then, which basically means you are at risk of data loss with every reboot. I was told multiple times that this is not fixable. If it is labels seem to be a great why to go. For now I have to compile them out/disable them unfortunately so they are not an option, and they'll be less so if the new installer also offers gmirror, geli, ... installs. Give me a solution that works out of the box and I'll happily agree that we switch. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Thu, 21 Apr 2011 07:51:56 + Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: a) we MUST HAVE a transition scheme if we cam-base ATA by default. Something that converts things automatically to whatever? That's not been done in more than one year. It's not acceptable to update, reboot and not find the root file system no matter what. We all agreed on that back then. I do not really care how it's done. I have been testing cam based ata for a while now on the machines I can cope with as a developer and even then I screwed the transition partly two times in the last months. How's a normal user to do that flawlessly? In particular it's fairly common that the mapping isn't adX - adaX. I've come across cases where ata(4) created ad10, ad12, ad16, etc. which got mapped to ada0, ada1, ada2 etc. When combined with a USB keyboard that often doesn't work at the root mount prompt, recovery can be a bit tricky. -- Bruce Cran ___ 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: Switch from legacy ata(4) to CAM-based ATA
Marius Strobl wrote: On Wed, Apr 20, 2011 at 12:57:47PM +0300, Alexander Motin wrote: With 9.0 release approaching quickly, I believe it the best time now to manage migration from legacy ata(4) ATA to the new CAM-based one. New ATA code present in the tree for more then a year now, used by many people and proved it's superior functionality and reliability. The only major issue with it now is the migration process. Sooner or later we have to pass it, but due to major UI and API changes we can't do it after 9.0 release. So I propose to do it the next Sunday (April 24) to have as much time for troubleshooting as possible. I have prepared the following patch to do it: http://people.freebsd.org/~mav/ata_switch.patch Could you please add descriptions of the controllers supported by ahci(4), mvs(4) and siis(4) to the kernel configuration files and preserve alphabetical ordering, i.e. list ata(4) after ahci(4)? OK. Here is the new patch: http://people.freebsd.org/~mav/ata_switch2.patch -- Alexander Motin ___ 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: Switch from legacy ata(4) to CAM-based ATA
Daniel Braniss wrote: Bruce Cran wrote: On Wed, 20 Apr 2011 12:57:47 +0300 Alexander Motin m...@freebsd.org wrote: If somebody has any problems with new ATA stack, please repeat your tests with latest HEAD code and contact me if problem is still there. Next three weeks before BSDCan I am going to dedicate to fixing possibly remaining issues. I've not checked recently with -current, but at least on the latest 8-stable there's a problem with using ATA_CAM on Xen: during boot there's a pause for a minute after which run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config is displayed. Verbose dmesg from the fresh system would be appreciated. I have a similar problem, but it's under 8.2-stable: This should fix your problem: http://svn.freebsd.org/changeset/base/220920 -- Alexander Motin ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, Apr 20, 2011 at 04:35:58PM -0700, Matthew Jacob wrote: On Wed, 20 Apr 2011, Scott Long wrote: ... I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using either mount-by-label, or be working to introduce generic device names to GEOM. Right now, device names are an implementation detail that have no functional use other than to complicate the fstab. Disks exposed through the block layer are simply direct-access block-array devices, nothing more. There's no functional difference to the kernel or userland between ad, ar, da, aacd, mfid, amrd, etc when it comes to reading and writing sectors off of them. But yet we give them unique names and pretend that those names mean something. We could give them all the name of disk and the system would still function exactly that same. The name attributes are interesting when it comes to doing out-of-band management, but it's also trivial to create a human-readable map and a programatic API between the generic name and the attribute name. Same goes for volumes labels, and I'd almost argue that they're more powerful than generic device names. In other words, ada isn't the problem here, it's that we all still think in terms of the 1980's when systems didn't autoconfigure and device names were important hints to system functionality. That time has thankfully passed, and it's time for us to catch up. Still, keep in mind that conservative leanings have to be appeased. Back in SparcStation1 development (1989) we kept on calling the root device Fred as in Let's boot fred now. That said, you would not *believe* the flack I took for having the root filesystem on sd3 instead of sd0 in SS1, even though there was no reason it couldn't have just been called fred. It was YOU ?! Could you, please, share a story ? I am very interested. Thanks in advance. pgpOSrs26vpzE.pgp Description: PGP signature
Re: Switch from legacy ata(4) to CAM-based ATA
First patch seemed to work fine. Second however, === mwl (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/mwl/../../dev/mwl/mwlhal.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl_pci.c /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c: In function 'mwl_node_getmimoinfo': /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2530: error: 'struct ieee80211_mimo_info' has no member named 'rssi' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2530: error: 'struct ieee80211_mimo_info' has no member named 'rssi' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2530: error: 'struct ieee80211_mimo_info' has no member named 'rssi' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2530: error: 'struct ieee80211_mimo_info' has no member named 'rssi' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2531: error: 'struct ieee80211_mimo_info' has no member named 'rssi' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2531: error: 'struct ieee80211_mimo_info' has no member named 'rssi' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2531: error: 'struct ieee80211_mimo_info' has no member named 'rssi' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2531: error: 'struct ieee80211_mimo_info' has no member named 'rssi' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2532: error: 'struct ieee80211_mimo_info' has no member named 'rssi' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2532: error: 'struct ieee80211_mimo_info' has no member named 'rssi' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2532: error: 'struct ieee80211_mimo_info' has no member named 'rssi' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2532: error: 'struct ieee80211_mimo_info' has no member named 'rssi' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2534: error: 'struct ieee80211_mimo_info' has no member named 'noise' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2535: error: 'struct ieee80211_mimo_info' has no member named 'noise' /usr/src/sys/modules/mwl/../../dev/mwl/if_mwl.c:2536: error: 'struct ieee80211_mimo_info' has no member named 'noise' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error On Thu, Apr 21, 2011 at 2:48 PM, Alexander Motin m...@freebsd.org wrote: Daniel Braniss wrote: Bruce Cran wrote: On Wed, 20 Apr 2011 12:57:47 +0300 Alexander Motin m...@freebsd.org wrote: If somebody has any problems with new ATA stack, please repeat your tests with latest HEAD code and contact me if problem is still there. Next three weeks before BSDCan I am going to dedicate to fixing possibly remaining issues. I've not checked recently with -current, but at least on the latest 8-stable there's a problem with using ATA_CAM on Xen: during boot there's a pause for a minute after which run_interrupt_driven_hooks: still waiting after 60 seconds
Re: Switch from legacy ata(4) to CAM-based ATA
George Kontostanos wrote: First patch seemed to work fine. Second however, It was unrelated breakage related to WiFi MIMO support. Already fixed. -- Alexander Motin ___ 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: Switch from legacy ata(4) to CAM-based ATA
My mistake! Everything back to normal thanks and very nice work. On Thu, Apr 21, 2011 at 3:41 PM, Alexander Motin m...@freebsd.org wrote: George Kontostanos wrote: First patch seemed to work fine. Second however, It was unrelated breakage related to WiFi MIMO support. Already fixed. -- Alexander Motin -- George Kontostanos aisecure.net http://www.aisecure.net ___ 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: Switch from legacy ata(4) to CAM-based ATA
On 04/20/2011 05:57, Alexander Motin wrote: Hi. With 9.0 release approaching quickly, I believe it the best time now to manage migration from legacy ata(4) ATA to the new CAM-based one. New ATA code present in the tree for more then a year now, used by many people and proved it's superior functionality and reliability. The only major issue with it now is the migration process. Sooner or later we have to pass it, but due to major UI and API changes we can't do it after 9.0 release. So I propose to do it the next Sunday (April 24) to have as much time for troubleshooting as possible. I have prepared the following patch to do it: http://people.freebsd.org/~mav/ata_switch.patch I haven't added geom_raid to the kernel configurations because we have no other GEOM classes there. But tell me if you thing I should. If somebody has any problems with new ATA stack, please repeat your tests with latest HEAD code and contact me if problem is still there. Next three weeks before BSDCan I am going to dedicate to fixing possibly remaining issues. Will camcontrol replace atacontrol and somehow magically recognize the atacontrol command set (list, status, info, attach/detach,etc.)? I haven't tried CURRENT for a while but I seem to recall that when I tried switching over to using CAM-based ATA there were some tricks one had to do in order to pass atacontrol commands through CAM and it didn't always work. The subcommands for camcontrol seemed to be more SCSI-ish and passing raw commands was subject to numerous local PEBKAC issues. cheers, ___ 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: Switch from legacy ata(4) to CAM-based ATA
Daniel Braniss wrote: Bruce Cran wrote: On Wed, 20 Apr 2011 12:57:47 +0300 Alexander Motin m...@freebsd.org wrote: If somebody has any problems with new ATA stack, please repeat your tests with latest HEAD code and contact me if problem is still there. Next three weeks before BSDCan I am going to dedicate to fixing possibly remaining issues. I've not checked recently with -current, but at least on the latest 8-stable there's a problem with using ATA_CAM on Xen: during boot there's a pause for a minute after which run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config is displayed. Verbose dmesg from the fresh system would be appreciated. I have a similar problem, but it's under 8.2-stable: should have been: s/8.2-stable/real hardware/ This should fix your problem: http://svn.freebsd.org/changeset/base/220920 indeed, it worked! it would be interested to know what's at the other end of this chip. thanks, danny ___ 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: Switch from legacy ata(4) to CAM-based ATA
On 04/21/11 02:51, Bjoern A. Zeeb wrote: On Apr 20, 2011, at 10:18 PM, Scott Long wrote: On Apr 20, 2011, at 2:50 PM, Alexander Motin wrote: Ulrich Spörlein wrote: [...] b) FYI: labels and stacked geoms do not work well together as you can never detach providers cleanly then, which basically means you are at risk of data loss with every reboot. I was told multiple times that this is not fixable. If it is labels seem to be a great why to go. For now I have to compile them out/disable them unfortunately so they are not an option, and they'll be less so if the new installer also offers gmirror, geli, ... installs. Give me a solution that works out of the box and I'll happily agree that we switch. [slightly off-topic] This is related to why bsdinstall doesn't put labels in /etc/fstab, although it does support setting them in the partition table for GPT, APM, and PC98 partitions: the mechanism seems to be sort of ad-hoc and unreliable. Only some of these labels (GPT) result in entries in /dev, and even then only on some platforms (GPT labels on big-endian systems don't work). The entries for GPT are added by glabel instead of gpart, which has to retaste and parse the GPT itself. This means it is difficult to guess the name of the labeled partition, or even whether it exists, and this is for gpart labels, which are probably the cleanest possible case. It would very much help if (a) gpart handled populating /dev/part-scheme/label itself, (b) did it generically for all partition schemes supporting labels, and (c) could tell you the path to the label entry in the config XML, which is right now somewhat difficult to obtain. It's also not clear to me what happens if you insert two volumes with identical labels (e.g. root) in the same machine -- at least ad[a]X are guaranteed non-conflicting. This is a serious potential issue with using labels in the installer's auto-defaults partitioning option. -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: Switch from legacy ata(4) to CAM-based ATA
On Wed, Apr 20, 2011 at 03:35:38PM -0700, Doug Barton wrote: On 04/20/2011 15:18, Scott Long wrote: I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using [...] mount-by-label +1 When I first saw this on linux my gut reaction was e, different. But now that I've worked with it a bit, I really like it. Doing this by default in 9.0 would be a really useful step forward, and would allow greater innovation down the road. Is there a handy tutorial somewhere for making this change in FreeBSD? Or is it even possible to do in a rational way? Judging from the thread that followed this: no. I agree with you that there should be and that mount-by-label is the way to go. I seem to recall some flakiness with mounting labelled gmirrors. Anyone know if that's been resolved? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG signature.asc Description: Digital signature
Re: Switch from legacy ata(4) to CAM-based ATA
On Thu, Apr 21, 2011 at 9:18 AM, Ted Faber fa...@isi.edu wrote: I seem to recall some flakiness with mounting labelled gmirrors. Anyone know if that's been resolved? Purely anecdotal, but we've been using gmirror on top of glabel since FreeBSD 7.0. First on CompactFlash disks using CF-to-IDE adapters (ata(4)), then with CF-to-SATA adapters (ahci(4)), then with SSDs (ahci(4)). These systems have been upgraded through 7.1, 7.2, 7.3, 8.0, 8.1, 8.2, and now run 8-STABLE (from early April). No issues relating to the use of gmirror or glabel, even when replacing disks in the mirror. I've also run gmirror on glabelled USB sticks, although the quality of the sticks and the USB stack made that flaky in the extreme when combined with a very active ZFS pool (7.x days). We've since removed the CF disks and switched to using SSDs due to speed issues. -- Freddie Cash fjwc...@gmail.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: Switch from legacy ata(4) to CAM-based ATA
I also think that labeling disks partitions should be the default approach on new installations. I wonder why the new bsdinstaller does not adopt this policy yet. It is practical, easy and saves a lot of hassles when it comes to disk replacements. On Thu, Apr 21, 2011 at 7:18 PM, Ted Faber fa...@isi.edu wrote: On Wed, Apr 20, 2011 at 03:35:38PM -0700, Doug Barton wrote: On 04/20/2011 15:18, Scott Long wrote: I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using [...] mount-by-label +1 When I first saw this on linux my gut reaction was e, different. But now that I've worked with it a bit, I really like it. Doing this by default in 9.0 would be a really useful step forward, and would allow greater innovation down the road. Is there a handy tutorial somewhere for making this change in FreeBSD? Or is it even possible to do in a rational way? Judging from the thread that followed this: no. I agree with you that there should be and that mount-by-label is the way to go. I seem to recall some flakiness with mounting labelled gmirrors. Anyone know if that's been resolved? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAk2wWMYACgkQaUz3f+Zf+XtI2ACfUz7zukI/G/4d5jEmsOuR73v4 YMgAoNsRHB255xZpx9IbEmoV+IxKWkTM =HvFZ -END PGP SIGNATURE- -- George Kontostanos aisecure.net http://www.aisecure.net ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Apr 20, 2011, at 2:57 AM, Alexander Motin m...@freebsd.org wrote: Hi. With 9.0 release approaching quickly, I believe it the best time now to manage migration from legacy ata(4) ATA to the new CAM-based one. New ATA code present in the tree for more then a year now, used by many people and proved it's superior functionality and reliability. The only major issue with it now is the migration process. Sooner or later we have to pass it, but due to major UI and API changes we can't do it after 9.0 release. So I propose to do it the next Sunday (April 24) to have as much time for troubleshooting as possible. I have prepared the following patch to do it: http://people.freebsd.org/~mav/ata_switch.patch I haven't added geom_raid to the kernel configurations because we have no other GEOM classes there. But tell me if you thing I should. If somebody has any problems with new ATA stack, please repeat your tests with latest HEAD code and contact me if problem is still there. Next three weeks before BSDCan I am going to dedicate to fixing possibly Although this may not be a list of fixable issues, here are some observations (in part with the new geom raid infrastructure): 1. Channels are no longer fixed of course because ata uses cam now, and I believe that device numbering is done based on probe ordering. This is fun to work with when dealing with appliances or configurations that require deterministic probe and mount, especially when drives fail, go missing, etc, but can be hacked around in device.hints. This is why it would be nice for geom labels to work in a sane manner. 2. When testing with USB thumb drives on 7.x with a custom kernel / sourcebase, it was enumerating the thumbdrive as da0, the first sata drive as ada1, etc. This may not be true for vanilla FreeBSD or later versions of FreeBSD. 3. Directly mappable analogs between atacontrol and camcontrol don't exist in areas; I'll come up with a laundry list for this because I said I would earlier via private email. 4. IIRC atacontrol and graid status reported different sets of raid volume states, depending on the underlying controller, in particular they changed the textual name for healthy from optimal to ready somewhere around the ICH7/8/9 era. Thanks again for all your hard work! -Garrett___ 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
Devices numbering [Was Re: Switch from legacy ata(4) to CAM-based ATA]
Hi, On Thu, Apr 21, 2011 at 1:31 PM, Garrett Cooper yaneg...@gmail.com wrote: Although this may not be a list of fixable issues, here are some observations (in part with the new geom raid infrastructure): 1. Channels are no longer fixed of course because ata uses cam now, and I believe that device numbering is done based on probe ordering. This is fun to work with when dealing with appliances or configurations that require deterministic probe and mount, especially when drives fail, go missing, etc, but can be hacked around in device.hints. This is why it would be nice for geom labels to work in a sane manner. Out of context, but the same issue appear with network interfaces. If you're got 6 networks interface and the 3rd chip die, the 3 last get a bad numbering. I am not sure it is fixable by any device.hints. The Linux' world has the same issue (well, worse actually, as all interfaces uses the same 'eth' name). RedHat has been/will be introducing Consistent Network Device Naming[0,1] in Fedora 15, which may be an interesting move. - Arnaud [0]: http://domsch.com/linux/lpc2010/lpc2010-network-device-naming.pdf [1]: http://domsch.com/blog/?p=455 ___ 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: Switch from legacy ata(4) to CAM-based ATA
Hello, Ted. You wrote 21 апреля 2011 г., 20:18:15: When I first saw this on linux my gut reaction was e, different. But now that I've worked with it a bit, I really like it. Doing this by default in 9.0 would be a really useful step forward, and would allow greater innovation down the road. Is there a handy tutorial somewhere for making this change in FreeBSD? Or is it even possible to do in a rational way? I seem to recall some flakiness with mounting labelled gmirrors. Anyone know if that's been resolved? It seems, not. I've got some probelms with gimirror/glabel (UFS Label) mess when I've installed 8.1-RELEASE (it was before 8.2) some time ago, and it seems, that no changes in this area in HEAD too... -- // Black Lion AKA Lev Serebryakov l...@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: Switch from legacy ata(4) to CAM-based ATA
Hello, Warren. You wrote 21 апреля 2011 г., 3:01:59: Not sure I understand the question. I have a little article called FreeBSD Labeled Filesystems: http://www.wonkity.com/~wblock/docs/html/labels.html This article says nothing about what should I do when gmirror tastes after glabel (and tasting order is completely out of user control now) and pickup one of LABELS as mirror part (instead of raw device)... -- // Black Lion AKA Lev Serebryakov l...@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: Switch from legacy ata(4) to CAM-based ATA
Date: Thu, 21 Apr 2011 01:37:14 -0400 From: Arnaud Lacombe lacom...@gmail.com Sender: owner-freebsd-curr...@freebsd.org Hi, On Wed, Apr 20, 2011 at 10:26 PM, Benjamin Kaduk ka...@mit.edu wrote: On Wed, 20 Apr 2011, Arnaud Lacombe wrote: Hi, On Wed, Apr 20, 2011 at 9:17 PM, Warren Block wbl...@wonkity.com wrote: On Wed, 20 Apr 2011, Arnaud Lacombe wrote: On Wed, Apr 20, 2011 at 6:38 PM, Garrett Cooper yaneg...@gmail.com wrote: On Wed, Apr 20, 2011 at 3:35 PM, Doug Barton do...@freebsd.org wrote: glabel create label /dev/blah Just tested that with a kernel from HEAD and a 8.x userland. This does not seem to survive a reboot. No, create makes a temporary label. label writes a label to the last block of the device. ... which does not seem be doable when the fs is mounted: [in single-user, with only / mounted r/w and /dev] # geom label label root /dev/ad0s1a geom: Can't store metadata on /dev/ad0s1a: Operation not permitted. As an anti-foot-shooting measure, this is blocked unless the flag sysctl kern.geom.debugflags |= 16 is set unfortunately, that condition alone is not enough, the geom (not sure the term is correct) should also have a rank of 1, which is not the case on my [fairly standard ?] disk. Here is some more info from ddb: db show geom class: SWAP (0xc0875260) class: DISK (0xc0853720) geom: ad0 (0xc1d56900), rank=1 provider: ad0 (0xc1d56880), access=r1w1e3 consumer: 0xc20b9e40 (ad0), access=r1w1e3 consumer: 0xc20ba000 (ad0), access=r0w0e0 class: DEV (0xc0853600) geom: ad0s1a (0xc1d56700), rank=4 consumer: 0xc20b9b00 (ad0s1a), access=r0w0e0 geom: ad0s1 (0xc1d56480), rank=3 consumer: 0xc20b9d80 (ad0s1), access=r0w0e0 geom: ad0 (0xc1d56780), rank=2 consumer: 0xc20ba000 (ad0), access=r0w0e0 class: LABEL (0xc0853ca0) class: VFS (0xc0853c00) geom: ffs.ad0s1a (0xc1d56c80), rank=4 consumer: 0xc20b9980 (ad0s1a), access=r1w1e1 class: PART (0xc0854520) geom: ad0s1 (0xc1d56200), rank=3 provider: ad0s1a (0xc1d56100), access=r1w1e1 consumer: 0xc20b9980 (ad0s1a), access=r1w1e1 consumer: 0xc20b9b00 (ad0s1a), access=r0w0e0 consumer: 0xc20b9cc0 (ad0s1), access=r1w1e2 geom: ad0 (0xc1d56680), rank=2 provider: ad0s1 (0xc1d56580), access=r1w1e2 consumer: 0xc20b9cc0 (ad0s1), access=r1w1e2 consumer: 0xc20b9d80 (ad0s1), access=r0w0e0 consumer: 0xc20b9e40 (ad0), access=r1w1e3 So right now, I still have no transition mechanism from 8.x to 9.x, beside dropping in single user and edition /etc/fstab manually. In the mean time, I'd assume that GEOM labels can be used in `vfs.root.mountfrom', am I right ? Since the issue of labels and changes is under discussion, I have a pet peeve that is in this area. For some reason that I can't fathom, the /dev/partition_format entries that are created for /dev/ufs vanish when the device is mounted. Why? This is not the case for ntfs, msdosfs, gpt, or any other. This inconsistent behavior has resulted in lots of kludges in HAL and other places and no one has ever given any good reason for it. Worse, many operations on a UFS partition/file system cause a devd create event even though there was no destroy event. I guess this is a bug, though, so I can open a PR on it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Thu, Apr 21, 2011 at 01:26:25PM +0300, Alexander Motin wrote: Marius Strobl wrote: On Wed, Apr 20, 2011 at 12:57:47PM +0300, Alexander Motin wrote: With 9.0 release approaching quickly, I believe it the best time now to manage migration from legacy ata(4) ATA to the new CAM-based one. New ATA code present in the tree for more then a year now, used by many people and proved it's superior functionality and reliability. The only major issue with it now is the migration process. Sooner or later we have to pass it, but due to major UI and API changes we can't do it after 9.0 release. So I propose to do it the next Sunday (April 24) to have as much time for troubleshooting as possible. I have prepared the following patch to do it: http://people.freebsd.org/~mav/ata_switch.patch Could you please add descriptions of the controllers supported by ahci(4), mvs(4) and siis(4) to the kernel configuration files and preserve alphabetical ordering, i.e. list ata(4) after ahci(4)? OK. Here is the new patch: http://people.freebsd.org/~mav/ata_switch2.patch Thanks! Marius ___ 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: Devices numbering [Was Re: Switch from legacy ata(4) to CAM-based ATA]
On Apr 21, 2011, at 10:48 AM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Thu, Apr 21, 2011 at 1:31 PM, Garrett Cooper yaneg...@gmail.com wrote: Although this may not be a list of fixable issues, here are some observations (in part with the new geom raid infrastructure): 1. Channels are no longer fixed of course because ata uses cam now, and I believe that device numbering is done based on probe ordering. This is fun to work with when dealing with appliances or configurations that require deterministic probe and mount, especially when drives fail, go missing, etc, but can be hacked around in device.hints. This is why it would be nice for geom labels to work in a sane manner. Out of context, but the same issue appear with network interfaces. If you're got 6 networks interface and the 3rd chip die, the 3 last get a bad numbering. I am not sure it is fixable by any device.hints. The Linux' world has the same issue (well, worse actually, as all interfaces uses the same 'eth' name). RedHat has been/will be introducing Consistent Network Device Naming[0,1] in Fedora 15, which may be an interesting move. I'll have to look at this more in-depth, but this could be promising -- depending on how portable the biosdevhelper tool is. Thanks, -Garrett PS while we may have a similar problem, at least the BSD interface names are more sane than the Linux ones. Overall it would be nice to alias multiple logical names like management, data, etc, like we may present to customers, but I don't know if someone has come up with an intelligent way to map out system topologies yet. It would be nice if serial numbers were exposed using a vendor independent mechanism. ___ 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: Devices numbering [Was Re: Switch from legacy ata(4) to CAM-based ATA]
On Thu, 21 Apr 2011, Arnaud Lacombe wrote: Hi, On Thu, Apr 21, 2011 at 1:31 PM, Garrett Cooper yaneg...@gmail.com wrote: Although this may not be a list of fixable issues, here are some observations (in part with the new geom raid infrastructure): 1. Channels are no longer fixed of course because ata uses cam now, and I believe that device numbering is done based on probe ordering. This is fun to work with when dealing with appliances or configurations that require deterministic probe and mount, especially when drives fail, go missing, etc, but can be hacked around in device.hints. This is why it would be nice for geom labels to work in a sane manner. Out of context, but the same issue appear with network interfaces. If you're got 6 networks interface and the 3rd chip die, the 3 last get a bad numbering. I am not sure it is fixable by any device.hints. The Linux' world has the same issue (well, worse actually, as all interfaces uses the same 'eth' name). RedHat has been/will be introducing Consistent Network Device Naming[0,1] in Fedora 15, which may be an interesting move. - Arnaud [0]: http://domsch.com/linux/lpc2010/lpc2010-network-device-naming.pdf [1]: http://domsch.com/blog/?p=455 Solaris /etc/path_to_inst anyone? }B- -- DE ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, 20 Apr 2011 12:57:47 +0300 Alexander Motin m...@freebsd.org wrote: If somebody has any problems with new ATA stack, please repeat your tests with latest HEAD code and contact me if problem is still there. Next three weeks before BSDCan I am going to dedicate to fixing possibly remaining issues. I've not checked recently with -current, but at least on the latest 8-stable there's a problem with using ATA_CAM on Xen: during boot there's a pause for a minute after which run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config is displayed. -- Bruce Cran ___ 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: Switch from legacy ata(4) to CAM-based ATA
Bruce Cran wrote: On Wed, 20 Apr 2011 12:57:47 +0300 Alexander Motin m...@freebsd.org wrote: If somebody has any problems with new ATA stack, please repeat your tests with latest HEAD code and contact me if problem is still there. Next three weeks before BSDCan I am going to dedicate to fixing possibly remaining issues. I've not checked recently with -current, but at least on the latest 8-stable there's a problem with using ATA_CAM on Xen: during boot there's a pause for a minute after which run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config is displayed. Verbose dmesg from the fresh system would be appreciated. -- Alexander Motin ___ 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: Switch from legacy ata(4) to CAM-based ATA
Yes, I believe that now is the time to do this. ___ 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: Switch from legacy ata(4) to CAM-based ATA
Bruce Cran wrote: On Wed, 20 Apr 2011 12:57:47 +0300 Alexander Motin m...@freebsd.org wrote: If somebody has any problems with new ATA stack, please repeat your tests with latest HEAD code and contact me if problem is still there. Next three weeks before BSDCan I am going to dedicate to fixing possibly remaining issues. I've not checked recently with -current, but at least on the latest 8-stable there's a problem with using ATA_CAM on Xen: during boot there's a pause for a minute after which run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config is displayed. Verbose dmesg from the fresh system would be appreciated. I have a similar problem, but it's under 8.2-stable: ... FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #43 r4876: Fri Mar 25 12:00:48 IST 2011 danny@rnd:/home/obj/rnd/r+d/stable/8/sys/HUJI amd64 Preloaded elf kernel /boot/kernel/kernel at 0x80f08000. Preloaded elf obj module /boot/kernel/geom_stripe.ko at 0x80f081a8. Preloaded elf obj module /boot/kernel/ahci.ko at 0x80f087d8. Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2261016004 Hz CPU: Intel(R) Xeon(R) CPU E5507 @ 2.27GHz (2261.02-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM, Features2=0x9ce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 25769803776 (24576 MB) ... ums0: Mouse on usbus3 ums0: 3 buttons and [Z] coordinates ID=0 ata2: p0: SATA connect time=0ms status=0113 ata2: p1: SATA connect timeout status= ata2: reset tp1 mask=03 ostat0=00 ostat1=00 ata2: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata2: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata2: reset tp2 stat0=00 stat1=00 devices=0x3 (aprobe0:ata2:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata2:0:1:0): CAM status: Command timeout (aprobe0:ata2:0:1:0): SIGNATURE: eb14 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config ata2: p0: SATA connect time=0ms status=0113 ata2: p1: SATA connect timeout status= ata2: reset tp1 mask=03 ostat0=00 ostat1=00 ata2: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata2: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata2: reset tp2 stat0=00 stat1=00 devices=0x3 (aprobe0:ata2:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata2:0:1:0): CAM status: Command timeout pass0 at ata2 bus 0 scbus0 target 0 lun 0 pass0: TSSTcorp DVD+-RW TS-L633C D250 Removable CD-ROM SCSI-0 device pass0: Serial Number e1F3456789KLMN4P pass0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) ATA PseudoRAID loaded lapic22: CMCI unmasked lapic0: CMCI unmasked SMP: AP CPU #3 Launched! lapic4: CMCI unmasked lapic18: CMCI unmasked ... cheers, danny ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, 20 Apr 2011 15:21:48 +0300 Alexander Motin m...@freebsd.org wrote: Verbose dmesg from the fresh system would be appreciated. I've put a verbose dmesg at http://www.cran.org.uk/~brucec/freebsd/dmesg.verbose_20110420.txt -- Bruce Cran ___ 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: Switch from legacy ata(4) to CAM-based ATA
Bruce Cran wrote: On Wed, 20 Apr 2011 15:21:48 +0300 Alexander Motin m...@freebsd.org wrote: Verbose dmesg from the fresh system would be appreciated. I've put a verbose dmesg at http://www.cran.org.uk/~brucec/freebsd/dmesg.verbose_20110420.txt Thank you. I've compared your and Daniel dmesgs, and while they are showing different emulated controllers, the problems seems to be common: ata_generic_reset() reports two devices on the channel with CD, while there is only one. As result, attempts to send requests to the missing device predictably cause timeouts. I have doubts that problem is specific to CAM-based ATA. It looks more probable to me that difference is just in command timeouts: 1 second with legacy ATA, and 30 seconds with CAM. Could you show me verbose dmesg with legacy ATA to make sure? Same time I'll try to think what can we do about it. -- Alexander Motin ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, 20.04.2011 at 12:57:47 +0300, Alexander Motin wrote: Hi. With 9.0 release approaching quickly, I believe it the best time now to manage migration from legacy ata(4) ATA to the new CAM-based one. New ATA code present in the tree for more then a year now, used by many people and proved it's superior functionality and reliability. The only major issue with it now is the migration process. Sooner or later we have to pass it, but due to major UI and API changes we can't do it after 9.0 release. So I propose to do it the next Sunday (April 24) to have as much time for troubleshooting as possible. I have prepared the following patch to do it: http://people.freebsd.org/~mav/ata_switch.patch I haven't added geom_raid to the kernel configurations because we have no other GEOM classes there. But tell me if you thing I should. If somebody has any problems with new ATA stack, please repeat your tests with latest HEAD code and contact me if problem is still there. Next three weeks before BSDCan I am going to dedicate to fixing possibly remaining issues. Can we then please get the ad device prefix back? I seem to remember that when they were introduced they were thought to be a temporary thing ... Unless both stacks can run in parallel, I don't see a problem with having them both show up as /dev/ad0, etc. People with problems must send in a complete dmesg anyway, so it should be clear what stack they are running. The POLA violation for people upgrading from 8.x to 9.0 however is pretty big ... and unnecessary. Cheers, Uli ___ 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: Switch from legacy ata(4) to CAM-based ATA
Ulrich Spörlein wrote: Can we then please get the ad device prefix back? I seem to remember that when they were introduced they were thought to be a temporary thing ... Unless both stacks can run in parallel, I don't see a problem with having them both show up as /dev/ad0, etc. People with problems must send in a complete dmesg anyway, so it should be clear what stack they are running. The POLA violation for people upgrading from 8.x to 9.0 however is pretty big ... and unnecessary. Stacks do can run in parallel, and it really happens when people loading ahci(4) driver for SATA disks without using `options ATA_CAM` of ata(4) for PATA. As result, SATA will use new stack and PATA - old one. What's about POLA violation, it is inevitable, because present kernel uses ata(4) with ATA_STATIC_ID option, that is not applicable in modern SATA world order. So at least device numbers will change. Also you should take into account, that many people and some software already adapted to adaX names and change back will break POLA for them. -- Alexander Motin ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, Apr 20, 2011 at 12:57:47PM +0300, Alexander Motin wrote: Hi. With 9.0 release approaching quickly, I believe it the best time now to manage migration from legacy ata(4) ATA to the new CAM-based one. New ATA code present in the tree for more then a year now, used by many people and proved it's superior functionality and reliability. The only major issue with it now is the migration process. Sooner or later we have to pass it, but due to major UI and API changes we can't do it after 9.0 release. So I propose to do it the next Sunday (April 24) to have as much time for troubleshooting as possible. I have prepared the following patch to do it: http://people.freebsd.org/~mav/ata_switch.patch Could you please add descriptions of the controllers supported by ahci(4), mvs(4) and siis(4) to the kernel configuration files and preserve alphabetical ordering, i.e. list ata(4) after ahci(4)? Marius ___ 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: Switch from legacy ata(4) to CAM-based ATA
Alexander Motin wrote:
Bruce Cran wrote:
On Wed, 20 Apr 2011 15:21:48 +0300
Alexander Motin m...@freebsd.org wrote:
Verbose dmesg from the fresh system would be appreciated.
I've put a verbose dmesg at
http://www.cran.org.uk/~brucec/freebsd/dmesg.verbose_20110420.txt
Thank you. I've compared your and Daniel dmesgs, and while they are
showing different emulated controllers, the problems seems to be common:
ata_generic_reset() reports two devices on the channel with CD, while
there is only one. As result, attempts to send requests to the missing
device predictably cause timeouts. I have doubts that problem is
specific to CAM-based ATA. It looks more probable to me that difference
is just in command timeouts: 1 second with legacy ATA, and 30 seconds
with CAM. Could you show me verbose dmesg with legacy ATA to make sure?
Same time I'll try to think what can we do about it.
2 Bruce: Looking on XEN sources, it seems that the only place how it
differs missing and present disk is the device signature. ata(4) at this
moment doesn't checks signature if it is not ATAPI and READY bit is set.
Attached patch should solve the problem by using more strict check, and
I only hope it won't break anything else. Try it please.
2 Daniel: Your situation is different, as both devices reported equally
during soft-reset. The only place where I see difference is on SATA
layer. But the funny thing is that I can't find SATA support in XEN
sources. What are you using? Can you send me full verbose dmesg and
`pciconf -lvcb`?
--
Alexander Motin
Index: ata-lowlevel.c
===
--- ata-lowlevel.c (revision 220837)
+++ ata-lowlevel.c (working copy)
@@ -535,7 +535,7 @@
if (lsb == ATAPI_MAGIC_LSB msb == ATAPI_MAGIC_MSB) {
ch-devices |= ATA_ATAPI_MASTER;
}
- else if (stat0 ATA_S_READY) {
+ else if (lsb == 0 msb == 0 (stat0 ATA_S_READY)) {
ch-devices |= ATA_ATA_MASTER;
}
}
@@ -568,7 +568,7 @@
if (lsb == ATAPI_MAGIC_LSB msb == ATAPI_MAGIC_MSB) {
ch-devices |= ATA_ATAPI_SLAVE;
}
- else if (stat1 ATA_S_READY) {
+ else if (lsb == 0 msb == 0 (stat1 ATA_S_READY)) {
ch-devices |= ATA_ATA_SLAVE;
}
}
___
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: Switch from legacy ata(4) to CAM-based ATA
On Wed, 20 Apr 2011 21:54:52 +0300 Alexander Motin m...@freebsd.org wrote: Could you show me verbose dmesg with legacy ATA to make sure? Same time I'll try to think what can we do about it. You're right - with the verbose dmesg with ata(4) there are lines: unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 The full dmesg is at http://www.cran.org.uk/~brucec/freebsd/dmesg.verbose_ata_20110420.txt . -- Bruce Cran ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Thu, 21 Apr 2011 00:17:44 +0300 Alexander Motin m...@freebsd.org wrote: 2 Bruce: Looking on XEN sources, it seems that the only place how it differs missing and present disk is the device signature. ata(4) at this moment doesn't checks signature if it is not ATAPI and READY bit is set. Attached patch should solve the problem by using more strict check, and I only hope it won't break anything else. Try it please. That seems to have fixed it. Thanks! -- Bruce Cran ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Apr 20, 2011, at 2:50 PM, Alexander Motin wrote: Ulrich Spörlein wrote: Can we then please get the ad device prefix back? I seem to remember that when they were introduced they were thought to be a temporary thing ... Unless both stacks can run in parallel, I don't see a problem with having them both show up as /dev/ad0, etc. People with problems must send in a complete dmesg anyway, so it should be clear what stack they are running. The POLA violation for people upgrading from 8.x to 9.0 however is pretty big ... and unnecessary. Stacks do can run in parallel, and it really happens when people loading ahci(4) driver for SATA disks without using `options ATA_CAM` of ata(4) for PATA. As result, SATA will use new stack and PATA - old one. What's about POLA violation, it is inevitable, because present kernel uses ata(4) with ATA_STATIC_ID option, that is not applicable in modern SATA world order. So at least device numbers will change. Also you should take into account, that many people and some software already adapted to adaX names and change back will break POLA for them. I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using either mount-by-label, or be working to introduce generic device names to GEOM. Right now, device names are an implementation detail that have no functional use other than to complicate the fstab. Disks exposed through the block layer are simply direct-access block-array devices, nothing more. There's no functional difference to the kernel or userland between ad, ar, da, aacd, mfid, amrd, etc when it comes to reading and writing sectors off of them. But yet we give them unique names and pretend that those names mean something. We could give them all the name of disk and the system would still function exactly that same. The name attributes are interesting when it comes to doing out-of-band management, but it's also trivial to create a human-readable map and a programatic API between the generic name and the attribute name. Same goes for volumes labels, and I'd almost argue that they're more powerful than generic device names. In other words, ada isn't the problem here, it's that we all still think in terms of the 1980's when systems didn't autoconfigure and device names were important hints to system functionality. That time has thankfully passed, and it's time for us to catch up. Scott ___ 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: Switch from legacy ata(4) to CAM-based ATA
On 04/20/2011 15:18, Scott Long wrote: I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using [...] mount-by-label +1 When I first saw this on linux my gut reaction was e, different. But now that I've worked with it a bit, I really like it. Doing this by default in 9.0 would be a really useful step forward, and would allow greater innovation down the road. Is there a handy tutorial somewhere for making this change in FreeBSD? Or is it even possible to do in a rational way? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: Switch from legacy ata(4) to CAM-based ATA
On Wed, Apr 20, 2011 at 3:35 PM, Doug Barton do...@freebsd.org wrote: On 04/20/2011 15:18, Scott Long wrote: I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using [...] mount-by-label +1 When I first saw this on linux my gut reaction was e, different. But now that I've worked with it a bit, I really like it. Doing this by default in 9.0 would be a really useful step forward, and would allow greater innovation down the road. Is there a handy tutorial somewhere for making this change in FreeBSD? Or is it even possible to do in a rational way? glabel create label /dev/blah sed -i 's,/dev/blah,/dev/labels/label,g' /etc/fstab ? Thanks, -Garrett ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, 20 Apr 2011, Doug Barton wrote: On 04/20/2011 15:18, Scott Long wrote: I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using [...] mount-by-label +1 When I first saw this on linux my gut reaction was e, different. But now that I've worked with it a bit, I really like it. Doing this by default in 9.0 would be a really useful step forward, and would allow greater innovation down the road. Is there a handy tutorial somewhere for making this change in FreeBSD? Or is it even possible to do in a rational way? Not sure I understand the question. I have a little article called FreeBSD Labeled Filesystems: http://www.wonkity.com/~wblock/docs/html/labels.html It uses filesystem labels instead of device labels (except for swap). The differences are the utility used to create the labels and where the labels show up in /dev. ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, 20 Apr 2011, Scott Long wrote: ... I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using either mount-by-label, or be working to introduce generic device names to GEOM. Right now, device names are an implementation detail that have no functional use other than to complicate the fstab. Disks exposed through the block layer are simply direct-access block-array devices, nothing more. There's no functional difference to the kernel or userland between ad, ar, da, aacd, mfid, amrd, etc when it comes to reading and writing sectors off of them. But yet we give them unique names and pretend that those names mean something. We could give them all the name of disk and the system would still function exactly that same. The name attributes are interesting when it comes to doing out-of-band management, but it's also trivial to create a human-readable map and a programatic API between the generic name and the attribute name. Same goes for volumes labels, and I'd almost argue that they're more powerful than generic device names. In other words, ada isn't the problem here, it's that we all still think in terms of the 1980's when systems didn't autoconfigure and device names were important hints to system functionality. That time has thankfully passed, and it's time for us to catch up. Still, keep in mind that conservative leanings have to be appeased. Back in SparcStation1 development (1989) we kept on calling the root device Fred as in Let's boot fred now. That said, you would not *believe* the flack I took for having the root filesystem on sd3 instead of sd0 in SS1, even though there was no reason it couldn't have just been called fred. ___ 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: Switch from legacy ata(4) to CAM-based ATA
now that I've worked with it a bit, I really like it. Doing this by default in 9.0 would be a really useful step forward, and would allow greater innovation down the road. Is there a handy tutorial somewhere for making this change in FreeBSD? Or is it even possible to do in a rational way? glabel create label /dev/blah sed -i 's,/dev/blah,/dev/labels/label,g' /etc/fstab or, dumpfs /dev/ad0a (or whatever it is) to get the UFS id, and do that, as in: /dev/ufsid/4cbfaf39a70e852e / ufs rw 1 1 ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, Apr 20, 2011 at 4:37 PM, Matthew Jacob m...@feral.com wrote: now that I've worked with it a bit, I really like it. Doing this by default in 9.0 would be a really useful step forward, and would allow greater innovation down the road. Is there a handy tutorial somewhere for making this change in FreeBSD? Or is it even possible to do in a rational way? glabel create label /dev/blah sed -i 's,/dev/blah,/dev/labels/label,g' /etc/fstab or, dumpfs /dev/ad0a (or whatever it is) to get the UFS id, and do that, as in: /dev/ufsid/4cbfaf39a70e852e / ufs rw 1 1 Same basic idea works for other filesystems according to the glabel manpage. It's just that the above method is pretty straigtforward to deal with and won't change if you newfs a partition, right :) (only if you wipe out whatever is used on the backend for holding the partition data)? Thanks, -Garrett ___ 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: Switch from legacy ata(4) to CAM-based ATA
On 04/20/2011 16:01, Warren Block wrote: Not sure I understand the question. I have a little article called FreeBSD Labeled Filesystems: http://www.wonkity.com/~wblock/docs/html/labels.html That's a good article, but it highlights what seem to be some deficiencies in the various implementations. For the most part they seem ufs-centric, although glabel shows some promise for supporting ext2fs and msdosfs (both of which are workhorse file systems for me). In your article you point out another thing that seems sub-optimal to me, different locations for different types of things which are all referred to as labels. My primary concern however is, quite frankly, that it isn't being done the way linux does it, on 2 fronts. First, I like the fact that on linux the labels are created with uuidgen at install time, and all the configuration is transparent to the user. Here is a good article that gives an overview: http://www.linux.com/archive/feature/146951, although searching for linux uuid disk label yielded a lot of good results. (Testing with our uuidgen(1) I noticed that we would probably need to do some work to support more methods to make it a little less predictable, but that shouldn't be difficult). The other concern I have is that having installed linux (ubuntu specifically) it's already created labels for things. If I run glabel is it potentially going to overwrite them? Why can't 'glabel list' (or some other tool) see those labels? And if this kind of label already exists, why can't we just use it? Finally, is glabel (which seems to be the only option for multi-fs labeling) be used safely for at least msdosfs and ext2fs? And if glabel is safe to use for all of our supported file systems, can they safely be mounted that way? Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: Switch from legacy ata(4) to CAM-based ATA
Hi, On Wed, Apr 20, 2011 at 6:38 PM, Garrett Cooper yaneg...@gmail.com wrote: On Wed, Apr 20, 2011 at 3:35 PM, Doug Barton do...@freebsd.org wrote: On 04/20/2011 15:18, Scott Long wrote: I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using [...] mount-by-label +1 When I first saw this on linux my gut reaction was e, different. But now that I've worked with it a bit, I really like it. Doing this by default in 9.0 would be a really useful step forward, and would allow greater innovation down the road. Is there a handy tutorial somewhere for making this change in FreeBSD? Or is it even possible to do in a rational way? glabel create label /dev/blah Just tested that with a kernel from HEAD and a 8.x userland. This does not seem to survive a reboot. - Arnaud sed -i 's,/dev/blah,/dev/labels/label,g' /etc/fstab ? Thanks, -Garrett ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, 20 Apr 2011, Doug Barton wrote: On 04/20/2011 16:01, Warren Block wrote: Not sure I understand the question. I have a little article called FreeBSD Labeled Filesystems: http://www.wonkity.com/~wblock/docs/html/labels.html That's a good article, but it highlights what seem to be some deficiencies in the various implementations. For the most part they seem ufs-centric, although glabel shows some promise for supporting ext2fs and msdosfs (both of which are workhorse file systems for me). Multiple filesystems are supported, although the labels appear in different places. See 'man glabel | less -p tunefs'. If your MS-DOS or ext2fs filesystem is natively labeled, the system automatically creates those labels in the appropriate directories in /dev. In your article you point out another thing that seems sub-optimal to me, different locations for different types of things which are all referred to as labels. It seemed spread out to me, too. But it hasn't been a problem, and I've come to think of it as namespaces. ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, 20 Apr 2011, Arnaud Lacombe wrote: On Wed, Apr 20, 2011 at 6:38 PM, Garrett Cooper yaneg...@gmail.com wrote: On Wed, Apr 20, 2011 at 3:35 PM, Doug Barton do...@freebsd.org wrote: glabel create label /dev/blah Just tested that with a kernel from HEAD and a 8.x userland. This does not seem to survive a reboot. No, create makes a temporary label. label writes a label to the last block of the device. ___ 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: Switch from legacy ata(4) to CAM-based ATA
Hi, On Wed, Apr 20, 2011 at 9:17 PM, Warren Block wbl...@wonkity.com wrote: On Wed, 20 Apr 2011, Arnaud Lacombe wrote: On Wed, Apr 20, 2011 at 6:38 PM, Garrett Cooper yaneg...@gmail.com wrote: On Wed, Apr 20, 2011 at 3:35 PM, Doug Barton do...@freebsd.org wrote: glabel create label /dev/blah Just tested that with a kernel from HEAD and a 8.x userland. This does not seem to survive a reboot. No, create makes a temporary label. label writes a label to the last block of the device. ... which does not seem be doable when the fs is mounted: [in single-user, with only / mounted r/w and /dev] # geom label label root /dev/ad0s1a geom: Can't store metadata on /dev/ad0s1a: Operation not permitted. Unfortunately, I do not have physical access to the machine. I guess that transition will be a royal PITA for a lot of people. Btw, you mentioned device, I guess you meant file-system, didn't you ? - Arnaud ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, 20 Apr 2011, Arnaud Lacombe wrote: Hi, On Wed, Apr 20, 2011 at 9:17 PM, Warren Block wbl...@wonkity.com wrote: On Wed, 20 Apr 2011, Arnaud Lacombe wrote: On Wed, Apr 20, 2011 at 6:38 PM, Garrett Cooper yaneg...@gmail.com wrote: On Wed, Apr 20, 2011 at 3:35 PM, Doug Barton do...@freebsd.org wrote: glabel create label /dev/blah Just tested that with a kernel from HEAD and a 8.x userland. This does not seem to survive a reboot. No, create makes a temporary label. label writes a label to the last block of the device. ... which does not seem be doable when the fs is mounted: [in single-user, with only / mounted r/w and /dev] # geom label label root /dev/ad0s1a geom: Can't store metadata on /dev/ad0s1a: Operation not permitted. As an anti-foot-shooting measure, this is blocked unless the flag sysctl kern.geom.debugflags |= 16 is set Unfortunately, I do not have physical access to the machine. I guess that transition will be a royal PITA for a lot of people. Btw, you mentioned device, I guess you meant file-system, didn't you ? The label is on the device, using space that is (hopefully) left over after the filesystem's allocation. -Ben Kaduk___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, Apr 20, 2011 at 6:18 PM, Scott Long sco...@samsco.org wrote: On Apr 20, 2011, at 2:50 PM, Alexander Motin wrote: Ulrich Spörlein wrote: Can we then please get the ad device prefix back? I seem to remember that when they were introduced they were thought to be a temporary thing ... Unless both stacks can run in parallel, I don't see a problem with having them both show up as /dev/ad0, etc. People with problems must send in a complete dmesg anyway, so it should be clear what stack they are running. The POLA violation for people upgrading from 8.x to 9.0 however is pretty big ... and unnecessary. Stacks do can run in parallel, and it really happens when people loading ahci(4) driver for SATA disks without using `options ATA_CAM` of ata(4) for PATA. As result, SATA will use new stack and PATA - old one. What's about POLA violation, it is inevitable, because present kernel uses ata(4) with ATA_STATIC_ID option, that is not applicable in modern SATA world order. So at least device numbers will change. Also you should take into account, that many people and some software already adapted to adaX names and change back will break POLA for them. I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using either mount-by-label, or be working to introduce generic device names to GEOM. Right now, device names are an implementation detail that have no functional use other than to complicate the fstab. Disks exposed through the block layer are simply direct-access block-array devices, nothing more. There's no functional difference to the kernel or userland between ad, ar, da, aacd, mfid, amrd, etc when it comes to reading and writing sectors off of them. But yet we give them unique names and pretend that those names mean something. We could give them all the name of disk and the system would still function exactly that same. The name attributes are interesting when it comes to doing out-of-band management, but it's also trivial to create a human-readable map and a programatic API between the generic name and the attribute name. Same goes for volumes labels, and I'd almost argue that they're more powerful than generic device names. In other words, ada isn't the problem here, it's that we all still think in terms of the 1980's when systems didn't autoconfigure and device names were important hints to system functionality. That time has thankfully passed, and it's time for us to catch up. Scott Defining disk units/partitions by labels is a vital requirement , especially , because of external devices such as USB sticks , USB attached disks and other disk-like units ( Compact Flash , etc. ) . When these units are attached , let's say into USB 0 , USB 1 , and so on , and we expect that USB stick is attached into USB 0 is da0 is NOT valid because attaching an external HDD is changing numbering of attached parts on the fly , and making them unusable . When there is a boot USB stick in slot USB 0 , and a HDD in slot USB 1 ( or larger number ) is NOT allowing boot from USB stick , because of this drive number change . To solve this problem , it is necessary to mount units from fstab with respect to their labels or ( their physical ports which NOT desirable ) instead of /dev/. definitions . FreeBSD 9.0-Current snapshots installed by bsdinstall by Nathan Whitehorn is also using /dev/... definitions in fstab and this structure is making such installs to USB devices unusable . Perhaps there are work arounds , but having a smoothly working default structure is most preferably one . At least , a choice may be made in fstab to allow either of these definitions : Current /dev/ system : device /dev/da0 ... device /dev/da1 ... and others , OR , attachment based on physical structure : port USB0 port USB1 port cd0 port SATA0 port SATA1 port PATA2 OR , or attachment based on labels , physical attachment point is NOT relevant for the user : label FreeBSD_8_2_Root ... label FreeBSD_8_2_Usr and others . This selection may be made during installation . I am trying to understand a way to design a PHYSICALLY secure FreeBSD , but encountering the above serious problem as arbitrary drive numbering which is preventing the boot of the system at the beginning . Thank you very much . Mehmet Erol Sanliturk ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, Apr 20, 2011 at 6:35 PM, Doug Barton do...@freebsd.org wrote: On 04/20/2011 15:18, Scott Long wrote: I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using [...] mount-by-label +1 When I first saw this on linux my gut reaction was e, different. But now that I've worked with it a bit, I really like it. Doing this by default in 9.0 would be a really useful step forward, and would allow greater innovation down the road. Is there a handy tutorial somewhere for making this change in FreeBSD? Or is it even possible to do in a rational way? Doug -- In Linux , if GRUB is used , with respect to my experience up to now , /dev/sda , /dev/sdb etc. structure is used , and changing cables of disks ( attaching it to another slot ) is preventing boot of the system because GRUB is NOT able to find the partitions with respect to /dev/... definitions . Here , I assume that , the user is NOT experienced sufficiently to edit the GRUB boot definition files before such attached slot changes or the used slot is broken unexpectedly ( requires use of a Rescue OS ) . All of my Linux installations are based on this structure , BUT perhaps some Linux distribution(s) which I am not using is using definitions of partitions by labels which is a very good approach . Thank you very much Mehmet Erol Sanliturk ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, Apr 20, 2011 at 7:01 PM, Warren Block wbl...@wonkity.com wrote: On Wed, 20 Apr 2011, Doug Barton wrote: On 04/20/2011 15:18, Scott Long wrote: I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using [...] mount-by-label +1 When I first saw this on linux my gut reaction was e, different. But now that I've worked with it a bit, I really like it. Doing this by default in 9.0 would be a really useful step forward, and would allow greater innovation down the road. Is there a handy tutorial somewhere for making this change in FreeBSD? Or is it even possible to do in a rational way? Not sure I understand the question. I have a little article called FreeBSD Labeled Filesystems: http://www.wonkity.com/~wblock/docs/html/labels.html It uses filesystem labels instead of device labels (except for swap). The differences are the utility used to create the labels and where the labels show up in /dev. ___ These steps are used AFTER installations of the FreeBSD . To have them selectable DURING installation is a much more desired structure . Also thank you very much for your articles . Thank you very much . Mehmet Erol Sanliturk ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Wed, Apr 20, 2011 at 10:30:33PM -0400, Mehmet Erol Sanliturk wrote: On Wed, Apr 20, 2011 at 6:18 PM, Scott Long sco...@samsco.org wrote: On Apr 20, 2011, at 2:50 PM, Alexander Motin wrote: Ulrich Spörlein wrote: Can we then please get the ad device prefix back? I seem to remember that when they were introduced they were thought to be a temporary thing ... Unless both stacks can run in parallel, I don't see a problem with having them both show up as /dev/ad0, etc. People with problems must send in a complete dmesg anyway, so it should be clear what stack they are running. The POLA violation for people upgrading from 8.x to 9.0 however is pretty big ... and unnecessary. Stacks do can run in parallel, and it really happens when people loading ahci(4) driver for SATA disks without using `options ATA_CAM` of ata(4) for PATA. As result, SATA will use new stack and PATA - old one. What's about POLA violation, it is inevitable, because present kernel uses ata(4) with ATA_STATIC_ID option, that is not applicable in modern SATA world order. So at least device numbers will change. Also you should take into account, that many people and some software already adapted to adaX names and change back will break POLA for them. I agree with what Alexander is saying, but I'd like to take it a step further. We should all be using either mount-by-label, or be working to introduce generic device names to GEOM. Right now, device names are an implementation detail that have no functional use other than to complicate the fstab. Disks exposed through the block layer are simply direct-access block-array devices, nothing more. There's no functional difference to the kernel or userland between ad, ar, da, aacd, mfid, amrd, etc when it comes to reading and writing sectors off of them. But yet we give them unique names and pretend that those names mean something. We could give them all the name of disk and the system would still function exactly that same. The name attributes are interesting when it comes to doing out-of-band management, but it's also trivial to create a human-readable map and a programatic API between the generic name and the attribute name. Same goes for volumes labels, and I'd almost argue that they're more powerful than generic device names. In other words, ada isn't the problem here, it's that we all still think in terms of the 1980's when systems didn't autoconfigure and device names were important hints to system functionality. That time has thankfully passed, and it's time for us to catch up. Scott Defining disk units/partitions by labels is a vital requirement , especially , because of external devices such as USB sticks , USB attached disks and other disk-like units ( Compact Flash , etc. ) . When these units are attached , let's say into USB 0 , USB 1 , and so on , and we expect that USB stick is attached into USB 0 is da0 is NOT valid because attaching an external HDD is changing numbering of attached parts on the fly , and making them unusable . When there is a boot USB stick in slot USB 0 , and a HDD in slot USB 1 ( or larger number ) is NOT allowing boot from USB stick , because of this drive number change . To solve this problem , it is necessary to mount units from fstab with respect to their labels or ( their physical ports which NOT desirable ) instead of /dev/. definitions . FreeBSD 9.0-Current snapshots installed by bsdinstall by Nathan Whitehorn is also using /dev/... definitions in fstab and this structure is making such installs to USB devices unusable . Perhaps there are work arounds , but having a smoothly working default structure is most preferably one . At least , a choice may be made in fstab to allow either of these definitions : Current /dev/ system : device /dev/da0 ... device /dev/da1 ... and others , OR , attachment based on physical structure : port USB0 port USB1 port cd0 port SATA0 port SATA1 port PATA2 OR , or attachment based on labels , physical attachment point is NOT relevant for the user : label FreeBSD_8_2_Root ... label FreeBSD_8_2_Usr and others . This selection may be made during installation . I am trying to understand a way to design a PHYSICALLY secure FreeBSD , but encountering the above serious problem as arbitrary drive numbering which is preventing the boot of the system at the beginning . Personally Id love to see a structured layout of devices just for type disk whether it be USB ATA SCSI... and be able to attach all those to one virtual layer that organizes them into, Where (diskN) is the virtual layer that works very much like what the wlan(4) devices do for wireless adapters but transparent to the user and the user wouldn't have to worry about if I'm using this driver then WTF is my disk called now /dev/disk0/ [label] [guid] [ufsid] [zfsid] [gptid] [slice1 or part1] And [label]
Re: Switch from legacy ata(4) to CAM-based ATA
Hi, On Wed, Apr 20, 2011 at 10:26 PM, Benjamin Kaduk ka...@mit.edu wrote: On Wed, 20 Apr 2011, Arnaud Lacombe wrote: Hi, On Wed, Apr 20, 2011 at 9:17 PM, Warren Block wbl...@wonkity.com wrote: On Wed, 20 Apr 2011, Arnaud Lacombe wrote: On Wed, Apr 20, 2011 at 6:38 PM, Garrett Cooper yaneg...@gmail.com wrote: On Wed, Apr 20, 2011 at 3:35 PM, Doug Barton do...@freebsd.org wrote: glabel create label /dev/blah Just tested that with a kernel from HEAD and a 8.x userland. This does not seem to survive a reboot. No, create makes a temporary label. label writes a label to the last block of the device. ... which does not seem be doable when the fs is mounted: [in single-user, with only / mounted r/w and /dev] # geom label label root /dev/ad0s1a geom: Can't store metadata on /dev/ad0s1a: Operation not permitted. As an anti-foot-shooting measure, this is blocked unless the flag sysctl kern.geom.debugflags |= 16 is set unfortunately, that condition alone is not enough, the geom (not sure the term is correct) should also have a rank of 1, which is not the case on my [fairly standard ?] disk. Here is some more info from ddb: db show geom class: SWAP (0xc0875260) class: DISK (0xc0853720) geom: ad0 (0xc1d56900), rank=1 provider: ad0 (0xc1d56880), access=r1w1e3 consumer: 0xc20b9e40 (ad0), access=r1w1e3 consumer: 0xc20ba000 (ad0), access=r0w0e0 class: DEV (0xc0853600) geom: ad0s1a (0xc1d56700), rank=4 consumer: 0xc20b9b00 (ad0s1a), access=r0w0e0 geom: ad0s1 (0xc1d56480), rank=3 consumer: 0xc20b9d80 (ad0s1), access=r0w0e0 geom: ad0 (0xc1d56780), rank=2 consumer: 0xc20ba000 (ad0), access=r0w0e0 class: LABEL (0xc0853ca0) class: VFS (0xc0853c00) geom: ffs.ad0s1a (0xc1d56c80), rank=4 consumer: 0xc20b9980 (ad0s1a), access=r1w1e1 class: PART (0xc0854520) geom: ad0s1 (0xc1d56200), rank=3 provider: ad0s1a (0xc1d56100), access=r1w1e1 consumer: 0xc20b9980 (ad0s1a), access=r1w1e1 consumer: 0xc20b9b00 (ad0s1a), access=r0w0e0 consumer: 0xc20b9cc0 (ad0s1), access=r1w1e2 geom: ad0 (0xc1d56680), rank=2 provider: ad0s1 (0xc1d56580), access=r1w1e2 consumer: 0xc20b9cc0 (ad0s1), access=r1w1e2 consumer: 0xc20b9d80 (ad0s1), access=r0w0e0 consumer: 0xc20b9e40 (ad0), access=r1w1e3 So right now, I still have no transition mechanism from 8.x to 9.x, beside dropping in single user and edition /etc/fstab manually. In the mean time, I'd assume that GEOM labels can be used in `vfs.root.mountfrom', am I right ? Thanks, - Arnaud ___ 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
