Re: Switchover to CAM ATA?
On Mon, Apr 26, 2010 at 09:18:07AM -0600, Scott Long wrote: > On Apr 26, 2010, at 6:51 AM, Alexander Motin wrote: > > Marius Strobl wrote: > >> As noted earlier, pc98 and sparc64 need ada(4)/CAM ATA to perform > >> geometry translation as done by ad_firmware_geom_adjust() for ad(4), > >> which the following patch hooks up to both: > >> http://people.freebsd.org/~marius/ata_disk_firmware_geom_adjust.diff > >> You preferred to implement such functionality via XPT_CALC_GEOMETRY > >> though (I'm still not convinced that it makes sense to put this > >> functionality into every ATA SIM the same way it is done for SCSI > >> rather than letting ada(4) handle it the same way for all SIMs > >> however). Have you looked into implementing XPT_CALC_GEOMETRY for > >> ATA CAM or is it okay to commit the above patch? > > > > Sorry, I have forgotten about this. > > > > I don't have better idea. For ATA translation seems indeed more > > platform- then controller-specific. May be I would just preferred to see > > this hack to be done inside XPT_CALC_GEOMETRY handler, as it is done now > > for PC98 SCSI. But looking that whole this topic is quite crappy and > > hopefully going to die sometimes, I won't argue much against committing > > this as-is for now. > > Put this into XPT_CALC_GEOMETRY. There's no point in perpetuating the > mistakes of the ata driver. > Give me a day or two to think of a reasonable way to do it right. > Did you get further with this approach? 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: Switchover to CAM ATA?
Lev Serebryakov writes: > "Dag-Erling Smørgrav" writes: > > Most pseudo-raid kit has nifty features like checksum offloading, > > composite writes etc. > Why are they called ``PSEUDO-raids'' then? Several reasons - they don't present the array to the OS as a single device, they don't handle failover, etc. DES -- Dag-Erling Smørgrav - d...@des.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: Switchover to CAM ATA?
Hello, Dag-Erling. You wrote 27 апреля 2010 г., 17:34:14: > Most pseudo-raid kit has nifty features like checksum offloading, > composite writes etc. Why are they called ``PSEUDO-raids'' then? -- // Black Lion AKA Lev Serebryakov ___ 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: Switchover to CAM ATA?
Alexander Motin writes: > I haven't dug really deep into current ataraid(4), but AFAIK it is all > done in software. At least there is no any offloading support on the > controller drivers level. None of ata(4) drivers do anything except > executing one ATA command at a time. Correct. That doesn't mean they *shouldn't* use offloading. Like I said, I started working on checksum offloading for Promise SATA controllers, but ZFS came along and I replaced the controllers because of data corruption issues (which turned out to be either a driver bug or a PCI timing bug which sos@ worked around in the driver, I forget which) > Any URLs? Google "Promise FastTrak SATA RAID" I have two or three of those, including one with on-board SDRAM (but no battery backup) DES -- Dag-Erling Smørgrav - d...@des.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: Switchover to CAM ATA?
On Apr 27, 2010, at 5:33 AM, Gavin Atkinson wrote: > On Mon, 2010-04-26 at 10:33 -0600, M. Warner Losh wrote: >> My opinion for the path forward: >> (1) Send a big heads up about the future of ataraid(5). It will be >>shot in the head soon, to be replaced be a bunch of geom classes >>for each different container format. At least that seems to be >>the rough consensus I've seen so far. We need worker bees to do >>many of these classes, although much can be mined from the ataraid >>code today. > > Losing ataraid would be bad. I suspect there are a lot of installs > using it - especially as there is no way to create any other mirror from > sysinstall. However, I'm not actually sure that the functionality it > provides is easy to push down into GEOM. > > ataraid depends on knowing a lot about the underlying hardware, in order > to know which format of metadata to use. i.e. it needs to know that the > disks are attached to (say) a Highpoint controller. This is unfortunately true, especially on older controllers. I think that there are reasonable ways to address this though, by having CAM SIMs provide a bit more information in their PATH_INQ response. 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: Switchover to CAM ATA?
On Apr 26, 2010, at 11:39 PM, Luke Dean wrote: > > > On Thu, 22 Apr 2010, Alexander Motin wrote: > >> So what is the public opinion: Is the lack of ataraid(4) fatal or we can >> live without it? > > Hardware mirroring is very important to me. It's the only solution I'm aware > of for realtime protection from drive failure in systems that boot multiple > operating systems. ATARAID doesn't do hardware mirroring. If you need that feature, buy an MPT card or a real RAID controller. 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: Switchover to CAM ATA?
On Apr 27, 2010, at 7:34 AM, Dag-Erling Smørgrav wrote: > Maxim Sobolev writes: >> Richard Tector writes: >>> Could I also add that the removal of ataraid would affect those >>> users who dual-boot with Windows and rely on the psuedo-raid >>> provided by most Intel chipsets to be able to share the same pair of >>> disks. >> Well, this won't be a problem if we have GEOM classes that can >> understand metadata created by the ATA RAID BIOS(es). > > Most pseudo-raid kit has nifty features like checksum offloading, > composite writes etc. which can improve performance considerably. You > can't access those from GEOM. If my "most" you mean "a small subset of vendors and products", then yes, you're correct. For the vast remaining majority, all you get is a special BIOS that can do striping and mirroring at boot. Sometimes that special BIOS requires a special hook in the controller chip, which is why you have ICHxxR vs ICHxx chips, for example. All the 'R' means is that the silicon supports an external ROM. 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: Switchover to CAM ATA?
Dag-Erling Smørgrav wrote: > Alexander Motin writes: >> Dag-Erling Smørgrav writes: >>> Most pseudo-raid kit has nifty features like checksum offloading, >>> composite writes etc. which can improve performance considerably. You >>> can't access those from GEOM. >> Have you ever seen them documented? > > ISTR I got the info from sos@ at some point. I have several Promise > cards lying around and was working onm RAID5 offloading, but I stopped > when ZFS became usable. Out Promise driver doesn't even have ATAPI support, not speaking about more advanced features. >> Does the need to specifically handle dozens of incompatible >> implementations with limited resources worth those (probably not >> major) benefits? > > The details probably vary from controller to controller, but the > capabilities are pretty much the same: perform the same write operation > to several disks at once, split a write operation across several disks, > compute and write parity. > > IIRC, composite writes are already supported but not used. I haven't dug really deep into current ataraid(4), but AFAIK it is all done in software. At least there is no any offloading support on the controller drivers level. None of ata(4) drivers do anything except executing one ATA command at a time. Looking that most of modern controllers threat every SATA channel independently, with separate request queue, status, interrupts and so on, I can hardly imagine how could they partially accelerate such things. The only alike example I know is a parity calculation accelerator in Marvel ARM SoCs. But it is completely separate device, unrelated to SATA controller. Any URLs? -- 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: Switchover to CAM ATA?
Alexander Motin writes: > Dag-Erling Smørgrav writes: > > Most pseudo-raid kit has nifty features like checksum offloading, > > composite writes etc. which can improve performance considerably. You > > can't access those from GEOM. > Have you ever seen them documented? ISTR I got the info from sos@ at some point. I have several Promise cards lying around and was working onm RAID5 offloading, but I stopped when ZFS became usable. > Does the need to specifically handle dozens of incompatible > implementations with limited resources worth those (probably not > major) benefits? The details probably vary from controller to controller, but the capabilities are pretty much the same: perform the same write operation to several disks at once, split a write operation across several disks, compute and write parity. IIRC, composite writes are already supported but not used. DES -- Dag-Erling Smørgrav - d...@des.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: Switchover to CAM ATA?
Dag-Erling Smørgrav wrote: > Maxim Sobolev writes: >> Richard Tector writes: >>> Could I also add that the removal of ataraid would affect those >>> users who dual-boot with Windows and rely on the psuedo-raid >>> provided by most Intel chipsets to be able to share the same pair of >>> disks. >> Well, this won't be a problem if we have GEOM classes that can >> understand metadata created by the ATA RAID BIOS(es). > > Most pseudo-raid kit has nifty features like checksum offloading, > composite writes etc. which can improve performance considerably. You > can't access those from GEOM. Have you ever seen them documented? Does the need to specifically handle dozens of incompatible implementations with limited resources worth those (probably not major) benefits? -- 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: Switchover to CAM ATA?
Maxim Sobolev writes: > Richard Tector writes: > > Could I also add that the removal of ataraid would affect those > > users who dual-boot with Windows and rely on the psuedo-raid > > provided by most Intel chipsets to be able to share the same pair of > > disks. > Well, this won't be a problem if we have GEOM classes that can > understand metadata created by the ATA RAID BIOS(es). Most pseudo-raid kit has nifty features like checksum offloading, composite writes etc. which can improve performance considerably. You can't access those from GEOM. DES -- Dag-Erling Smørgrav - d...@des.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: Switchover to CAM ATA?
Freddie Cash writes: > If a lowly user's vote counts for anything, I'd vote for the complete > removal of ataraid support. We have gstripe, gmirror, graid3, graid5, and > zfs (and gvinum for the masochistics). :) We don't need to support any of > the crappy pseudo-raid "hardware" out there. ataraid(4) has served it's > purpose, tiding us over until GEOM RAID facilities were in place. Now it's > time for it to be retired. gstripe can't create a bootable striped set; ataraid can. DES -- Dag-Erling Smørgrav - d...@des.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: Switchover to CAM ATA?
Gavin Atkinson wrote: > Losing ataraid would be bad. I suspect there are a lot of installs > using it - especially as there is no way to create any other mirror from > sysinstall. However, I'm not actually sure that the functionality it > provides is easy to push down into GEOM. > > ataraid depends on knowing a lot about the underlying hardware, in order > to know which format of metadata to use. i.e. it needs to know that the > disks are attached to (say) a Highpoint controller. This is especially > important when creating new ATA RAID devices, although there is so > little identifying metadata on the disks themselves that in some cases > it doesn't look like it is possible to identify or even confirm the > existence of metadata without knowing the PCI ID of the controller to > which the disks are attached. > > I'm not sure I can see a way to do this from within GEOM. CAM allows every SIM driver to report several arbitrary string values, describing driver and hardware. They are almost unused now. I don't see much problems in exporting them to GEOM and making tasting method to analyze 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: Switchover to CAM ATA?
On Mon, 2010-04-26 at 10:33 -0600, M. Warner Losh wrote: > My opinion for the path forward: > (1) Send a big heads up about the future of ataraid(5). It will be > shot in the head soon, to be replaced be a bunch of geom classes > for each different container format. At least that seems to be > the rough consensus I've seen so far. We need worker bees to do > many of these classes, although much can be mined from the ataraid > code today. Losing ataraid would be bad. I suspect there are a lot of installs using it - especially as there is no way to create any other mirror from sysinstall. However, I'm not actually sure that the functionality it provides is easy to push down into GEOM. ataraid depends on knowing a lot about the underlying hardware, in order to know which format of metadata to use. i.e. it needs to know that the disks are attached to (say) a Highpoint controller. This is especially important when creating new ATA RAID devices, although there is so little identifying metadata on the disks themselves that in some cases it doesn't look like it is possible to identify or even confirm the existence of metadata without knowing the PCI ID of the controller to which the disks are attached. I'm not sure I can see a way to do this from within GEOM. Gavin ___ 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: Switchover to CAM ATA?
On Thu, 22 Apr 2010, Alexander Motin wrote: So what is the public opinion: Is the lack of ataraid(4) fatal or we can live without it? Hardware mirroring is very important to me. It's the only solution I'm aware of for realtime protection from drive failure in systems that boot multiple operating systems. ___ 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: Switchover to CAM ATA?
On 27/04/2010, at 5:18 AM, Lev Serebryakov wrote: > Hello, Pawel. > You wrote 26 апреля 2010 г., 23:10:12: > >> You most likely got it right, I'm just saying creating separate GEOM >> class for each metadata format is wrong direction. :) > Does ataraid translations and checksuming (in case of RAID5) now or > it configures chipsets only? > > All these ``raids'' are known as ``soft raids'' or ``fake raids'', > but what does do real work -- BIOS or driver (Ataraid in case of > FreeBSD)? Both.. ataraid does it when FreeBSD is running but the BIOS does it before then so boot0, the loader, et al can read the disk without having an underlying driver. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: Switchover to CAM ATA?
Hello, Pawel. You wrote 26 апреля 2010 г., 23:10:12: > You most likely got it right, I'm just saying creating separate GEOM > class for each metadata format is wrong direction. :) Does ataraid translations and checksuming (in case of RAID5) now or it configures chipsets only? All these ``raids'' are known as ``soft raids'' or ``fake raids'', but what does do real work -- BIOS or driver (Ataraid in case of FreeBSD)? -- // Black Lion AKA Lev Serebryakov ___ 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: Switchover to CAM ATA?
On Mon, Apr 26, 2010 at 12:19:46PM -0600, M. Warner Losh wrote: > In message: <20100426181209.gb3...@garage.freebsd.pl> > Pawel Jakub Dawidek writes: > : On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote: > : > I've read most of this thread. I think this is cool technology. > : > However, before we move forward with this, we need to have a plan for > : > the various issues that have come up. The plan needs to be specific, > : > have owners for key items, warnings about ownerless == obsoleted, and > : > target dates. > : > > : > I think this is one of the cases where we should record the plan of > : > record on a wiki. It worked well for other times we've had big, > : > disruptive changes. > : > > : > My opinion for the path forward: > : > (1) Send a big heads up about the future of ataraid(5). It will be > : > shot in the head soon, to be replaced be a bunch of geom classes > : > for each different container format. At least that seems to be > : > the rough consensus I've seen so far. We need worker bees to do > : > many of these classes, although much can be mined from the ataraid > : > code today. > : > : This shouldn't be a bunch of GEOM classes. This should one class which > : recognize multiple formats, just like the LABEL class. > : I don't think it is feasible to reuse gmirror for that, it wasn't > : designed in something like this in mind. > > OK. Maybe I got the consensus wrong... My key point is that we need > a plan moving forward, we need to identify what's actively being > worked on vs "somebody else[tm] should do tihs" and when it needs to > be done "or else". You most likely got it right, I'm just saying creating separate GEOM class for each metadata format is wrong direction. :) > : > (5) Issues with glabel and ataraid(5) need an owner, and need to be > : > resolved, since the device names here are likely to change. > : > : What are the issues? > > ataraid doesn't remove the underlying ad* devices, so glabel often > picks those up instead of the ataraid device, and you only get 1 > disk's worth of raid device... So no mirroring or only 1/2 a striped > volume. It not only leave ad* devices, it doesn't even open them properly using GEOM. It's internal ATA hack, which is PITA. -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpC74JvN8hWL.pgp Description: PGP signature
Re: Switchover to CAM ATA?
In message: <20100426181209.gb3...@garage.freebsd.pl> Pawel Jakub Dawidek writes: : On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote: : > I've read most of this thread. I think this is cool technology. : > However, before we move forward with this, we need to have a plan for : > the various issues that have come up. The plan needs to be specific, : > have owners for key items, warnings about ownerless == obsoleted, and : > target dates. : > : > I think this is one of the cases where we should record the plan of : > record on a wiki. It worked well for other times we've had big, : > disruptive changes. : > : > My opinion for the path forward: : > (1) Send a big heads up about the future of ataraid(5). It will be : > shot in the head soon, to be replaced be a bunch of geom classes : > for each different container format. At least that seems to be : > the rough consensus I've seen so far. We need worker bees to do : > many of these classes, although much can be mined from the ataraid : > code today. : : This shouldn't be a bunch of GEOM classes. This should one class which : recognize multiple formats, just like the LABEL class. : I don't think it is feasible to reuse gmirror for that, it wasn't : designed in something like this in mind. OK. Maybe I got the consensus wrong... My key point is that we need a plan moving forward, we need to identify what's actively being worked on vs "somebody else[tm] should do tihs" and when it needs to be done "or else". : > (2) Send another big heads up strongly recommending people go to : > glabel based fstabs. Maybe the right option here is to provide a : > simple script walk people through the conversion. This will : > render the carnage of ad -> ada (or da) a mostly non-event, and : > also protect people from 'oops' of rebooting with that thumb drive : > in the system. : > (3) Create a wiki to record all the new geom classes needed. Find : > people to own each one, or note it is unowned, and support will be : > dropped if no owner can be found. : > (4) sysinstall should default to creating label systems, if it doesn't : > already. : > (5) Issues with glabel and ataraid(5) need an owner, and need to be : > resolved, since the device names here are likely to change. : : What are the issues? ataraid doesn't remove the underlying ad* devices, so glabel often picks those up instead of the ataraid device, and you only get 1 disk's worth of raid device... So no mirroring or only 1/2 a striped volume. Warner ___ 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: Switchover to CAM ATA?
On Mon, 26 Apr 2010, M. Warner Losh wrote: I've read most of this thread. I think this is cool technology. However, before we move forward with this, we need to have a plan for the various issues that have come up. The plan needs to be specific, have owners for key items, warnings about ownerless == obsoleted, and target dates. I think this is one of the cases where we should record the plan of record on a wiki. It worked well for other times we've had big, disruptive changes. This is my reading too: this is a big deal change, it's excellent that it's happening, but if we want it to go well we need to do a bit of planning. In particular, if we want to maximize our effectiveness in convincing people to write replacements parts for ataraid, doing the heads up and schedule/warnings the right way will help a lot. While the schedule doesn't need to be as long as the mpsafe network stack/device drivers process, it worked well in practice and so I'd encourage something similar. More generally, and to raise a point not so much in your list: I wonder if global-based fstabs are the right way to go or not. If they are we need to push the migration heavily, and especially provide a pre-upgrade tool to help users get their fstab changes right (i.e., a script that takes your /etc/fstab and system configuration and tells you what to put in your new fstab). I still wonder if we should be trying a bit harder to provide compatibility with the old ata names -- our experience is that "flag day" upgrades cause a lot of user attrition on -current and in the releases, and it might be that making a few architectural sacrifices to ease the upgrade path is worth it. I for one don't want to be on the wrong end of all the users who install a new kernel and discover that /etc/fstab isn't forwards-compatible! All that said: this is really great work, and I'm sure I speak for many when I say thanks to Alexander for the hard work that has gone into this. A bit more perserverence and we'll be there :-). Robert My opinion for the path forward: (1) Send a big heads up about the future of ataraid(5). It will be shot in the head soon, to be replaced be a bunch of geom classes for each different container format. At least that seems to be the rough consensus I've seen so far. We need worker bees to do many of these classes, although much can be mined from the ataraid code today. (2) Send another big heads up strongly recommending people go to glabel based fstabs. Maybe the right option here is to provide a simple script walk people through the conversion. This will render the carnage of ad -> ada (or da) a mostly non-event, and also protect people from 'oops' of rebooting with that thumb drive in the system. (3) Create a wiki to record all the new geom classes needed. Find people to own each one, or note it is unowned, and support will be dropped if no owner can be found. (4) sysinstall should default to creating label systems, if it doesn't already. (5) Issues with glabel and ataraid(5) need an owner, and need to be resolved, since the device names here are likely to change. (6) Someone needs to write-up a detailed description of how to do this for UPDATING. Maybe we can reuse text from #2. (7) We need a target time line for these things to happen. We can't just break ataraid(5) by default with little or no warning. Realistically, this will be for 9.0 and later systems, so we have some time before the branch to give warning, as well as pull the switch and have adequate testing time. (8) Fill in all the parts that I've missed :) Comments? Warner ___ 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: Switchover to CAM ATA?
On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote: > I've read most of this thread. I think this is cool technology. > However, before we move forward with this, we need to have a plan for > the various issues that have come up. The plan needs to be specific, > have owners for key items, warnings about ownerless == obsoleted, and > target dates. > > I think this is one of the cases where we should record the plan of > record on a wiki. It worked well for other times we've had big, > disruptive changes. > > My opinion for the path forward: > (1) Send a big heads up about the future of ataraid(5). It will be > shot in the head soon, to be replaced be a bunch of geom classes > for each different container format. At least that seems to be > the rough consensus I've seen so far. We need worker bees to do > many of these classes, although much can be mined from the ataraid > code today. This shouldn't be a bunch of GEOM classes. This should one class which recognize multiple formats, just like the LABEL class. I don't think it is feasible to reuse gmirror for that, it wasn't designed in something like this in mind. > (2) Send another big heads up strongly recommending people go to > glabel based fstabs. Maybe the right option here is to provide a > simple script walk people through the conversion. This will > render the carnage of ad -> ada (or da) a mostly non-event, and > also protect people from 'oops' of rebooting with that thumb drive > in the system. > (3) Create a wiki to record all the new geom classes needed. Find > people to own each one, or note it is unowned, and support will be > dropped if no owner can be found. > (4) sysinstall should default to creating label systems, if it doesn't > already. > (5) Issues with glabel and ataraid(5) need an owner, and need to be > resolved, since the device names here are likely to change. What are the issues? -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp9zbeI5WsV4.pgp Description: PGP signature
Re: Switchover to CAM ATA?
I've read most of this thread. I think this is cool technology. However, before we move forward with this, we need to have a plan for the various issues that have come up. The plan needs to be specific, have owners for key items, warnings about ownerless == obsoleted, and target dates. I think this is one of the cases where we should record the plan of record on a wiki. It worked well for other times we've had big, disruptive changes. My opinion for the path forward: (1) Send a big heads up about the future of ataraid(5). It will be shot in the head soon, to be replaced be a bunch of geom classes for each different container format. At least that seems to be the rough consensus I've seen so far. We need worker bees to do many of these classes, although much can be mined from the ataraid code today. (2) Send another big heads up strongly recommending people go to glabel based fstabs. Maybe the right option here is to provide a simple script walk people through the conversion. This will render the carnage of ad -> ada (or da) a mostly non-event, and also protect people from 'oops' of rebooting with that thumb drive in the system. (3) Create a wiki to record all the new geom classes needed. Find people to own each one, or note it is unowned, and support will be dropped if no owner can be found. (4) sysinstall should default to creating label systems, if it doesn't already. (5) Issues with glabel and ataraid(5) need an owner, and need to be resolved, since the device names here are likely to change. (6) Someone needs to write-up a detailed description of how to do this for UPDATING. Maybe we can reuse text from #2. (7) We need a target time line for these things to happen. We can't just break ataraid(5) by default with little or no warning. Realistically, this will be for 9.0 and later systems, so we have some time before the branch to give warning, as well as pull the switch and have adequate testing time. (8) Fill in all the parts that I've missed :) Comments? Warner ___ 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: Switchover to CAM ATA?
On Apr 26, 2010, at 6:51 AM, Alexander Motin wrote: > Marius Strobl wrote: >> As noted earlier, pc98 and sparc64 need ada(4)/CAM ATA to perform >> geometry translation as done by ad_firmware_geom_adjust() for ad(4), >> which the following patch hooks up to both: >> http://people.freebsd.org/~marius/ata_disk_firmware_geom_adjust.diff >> You preferred to implement such functionality via XPT_CALC_GEOMETRY >> though (I'm still not convinced that it makes sense to put this >> functionality into every ATA SIM the same way it is done for SCSI >> rather than letting ada(4) handle it the same way for all SIMs >> however). Have you looked into implementing XPT_CALC_GEOMETRY for >> ATA CAM or is it okay to commit the above patch? > > Sorry, I have forgotten about this. > > I don't have better idea. For ATA translation seems indeed more > platform- then controller-specific. May be I would just preferred to see > this hack to be done inside XPT_CALC_GEOMETRY handler, as it is done now > for PC98 SCSI. But looking that whole this topic is quite crappy and > hopefully going to die sometimes, I won't argue much against committing > this as-is for now. Put this into XPT_CALC_GEOMETRY. There's no point in perpetuating the mistakes of the ata driver. Give me a day or two to think of a reasonable way to do it right. 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: usb/da vs sata geometry calculations (was Re: Switchover to CAM ATA?)
Andrew Reilly wrote: > Was this the result of the umass/da driver having a different > synthetic geometry calculation routine than the SATA driver? ATA and SCSI disk drivers indeed have different geometry calculation algorithms. ATA fetches geometry from DEVICE IDENTIFY data, while SCSI seems just fakes them in many cases. > This was all on an 8-STABLE system about 400 days old, fwiw. > > Should I expect any on-going badness as a result of this > difference in "geometry" between two identical drives? I hope not. LBA-aware loaders should use LBA offsets of the partitions, which are not depending on geometry. -- 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: Switchover to CAM ATA?
Marius Strobl wrote: > As noted earlier, pc98 and sparc64 need ada(4)/CAM ATA to perform > geometry translation as done by ad_firmware_geom_adjust() for ad(4), > which the following patch hooks up to both: > http://people.freebsd.org/~marius/ata_disk_firmware_geom_adjust.diff > You preferred to implement such functionality via XPT_CALC_GEOMETRY > though (I'm still not convinced that it makes sense to put this > functionality into every ATA SIM the same way it is done for SCSI > rather than letting ada(4) handle it the same way for all SIMs > however). Have you looked into implementing XPT_CALC_GEOMETRY for > ATA CAM or is it okay to commit the above patch? Sorry, I have forgotten about this. I don't have better idea. For ATA translation seems indeed more platform- then controller-specific. May be I would just preferred to see this hack to be done inside XPT_CALC_GEOMETRY handler, as it is done now for PC98 SCSI. But looking that whole this topic is quite crappy and hopefully going to die sometimes, I won't argue much against committing this as-is for now. -- 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: Switchover to CAM ATA?
On 04/25/10 19:03, Scott Long wrote: > On Apr 25, 2010, at 7:58 PM, Doug Barton wrote: >> On 04/25/10 03:23, Alexander Best wrote: >>> another option would be to have a ata(4)->cam(4)->ata(4) >>> emulation. >> >> What would be the value of doing all of that work as opposed to >> just using one of the available options that already work with cam >> such as cdrecord? >> > > I think that there's a valid argument for having a cd recording > program in the base system. I'm not sure I agree with you, but that's orthogonal to the OP. :) > cdrecord is an excellent program, but I > don't believe that it's a good candidate to try to import into > FreeBSD. Agreed on that ... and I'm not opposed to your previous idea of rewriting burncd to work with the new world order. I'm just not sure that the multi-layer idea to make the old burncd work is a good idea. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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: Switchover to CAM ATA?
On Apr 25, 2010, at 7:58 PM, Doug Barton wrote: > On 04/25/10 03:23, Alexander Best wrote: >> another option would be to have a ata(4)->cam(4)->ata(4) emulation. > > What would be the value of doing all of that work as opposed to just > using one of the available options that already work with cam such as > cdrecord? > I think that there's a valid argument for having a cd recording program in the base system. cdrecord is an excellent program, but I don't believe that it's a good candidate to try to import into FreeBSD. Scoot ___ 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: Switchover to CAM ATA?
On 04/25/10 03:23, Alexander Best wrote: > another option would be to have a ata(4)->cam(4)->ata(4) emulation. What would be the value of doing all of that work as opposed to just using one of the available options that already work with cam such as cdrecord? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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: Switchover to CAM ATA?
On Apr 25, 2010, at 4:23 AM, Alexander Best wrote: > Jaakko Heinonen schrieb am 2010-04-23: >> On 2010-04-23, Alexander Best wrote: >>> has anybody thought about adding scsi support to burncd(8)? i've >>> been using >>> ATA CAM for quite a while now and really love it. however i miss >>> burncd(8). > >> I have thought about it. The mail I posted in December didn't >> generate >> any interest. > > i'm sorry i didn't notice your mail back then. i'm very interested in using > burncd on a pass(4) device and would like to test any patches you may have. > > another option would be to have a ata(4)->cam(4)->ata(4) emulation. layer (the > opposite of the current ATA_CAM option). that way all ata binaries would > continue to work. what /dev/ata* would be used for is to receive ata > commands, convert them to cam commands and then send them to pass. i wrote a > mail with the idea to freebsd-questions@, but also got no response [1]. > Compatibility is a good thing, and I see nothing wrong with adding a simple ioctl module to the pass or cd driver that achieves this. The only thing that I'd worry about is that there might be semantics to the old ata ioctls that rely on quirky operations of the old ata driver. It's really going to be counter-productive to try too hard to emulate the old driver; the whole point of CAM_ATA is to move on from the sins of it. Also, other than burncd, what else exists to justify this emulation layer? If it's just burncd, have you considered writing a CAM-oriented replacement for it? Maybe something that is as versatile as cdrecord, but with an unencumbered BSD license so it can exist in the base system? 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: Switchover to CAM ATA?
Jaakko Heinonen schrieb am 2010-04-23: > On 2010-04-23, Alexander Best wrote: > > has anybody thought about adding scsi support to burncd(8)? i've > > been using > > ATA CAM for quite a while now and really love it. however i miss > > burncd(8). > I have thought about it. The mail I posted in December didn't > generate > any interest. i'm sorry i didn't notice your mail back then. i'm very interested in using burncd on a pass(4) device and would like to test any patches you may have. another option would be to have a ata(4)->cam(4)->ata(4) emulation. layer (the opposite of the current ATA_CAM option). that way all ata binaries would continue to work. what /dev/ata* would be used for is to receive ata commands, convert them to cam commands and then send them to pass. i wrote a mail with the idea to freebsd-questions@, but also got no response [1]. [1]: http://www.mail-archive.com/freebsd-questi...@freebsd.org/msg229439.html > http://docs.freebsd.org/cgi/mid.cgi?20091214182645.GA2764 -- Alexander Best ___ 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"
usb/da vs sata geometry calculations (was Re: Switchover to CAM ATA?)
Hi all, Sorry to interrupt this thread with an off-topic question, but it seems vaguely related, and you folk seem to be the right ones to ask: I've recently done a drive upgrade in a 1U rack machine that only had space for the two active drives that were in it, and I couldn't afford the down-time that it would take to install from scratch. So I formatted and populated the first replacement drive in an external USB cradle, and when it was looking like a good replacement for the (gmirror'd) image that was running, I did the physical swap, and all was good, as expected. All except that that the identical drive that I inserted as the second element of the mirror would *not* accept a copy of the first disk's MBR block (with fdisk). It said that the calculated geometry was incompatible. Luckily for me (I think) the calculated geometry was a megabyte or so *larger* than the first drive, so I was still able to bsdlabel it to match, and slot it into the gmirror as planned. Was this the result of the umass/da driver having a different synthetic geometry calculation routine than the SATA driver? This was all on an 8-STABLE system about 400 days old, fwiw. Should I expect any on-going badness as a result of this difference in "geometry" between two identical drives? Cheers, -- Andrew ___ 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: Switchover to CAM ATA?
On Thu, Apr 22, 2010 at 06:31:37PM +0300, Alexander Motin wrote: > Hi. > > With time passed, CAM-based ATA infrastructure IMHO looks enough mature > now to enable it in HEAD. Now we have two new stable drivers ahci(4) and > siis(4), covering major part of modern SATA HBAs, `options ATA_CAM` > wrapper for ata(4) to supports legacy hardware, and one more improved > driver for Marvell HBAs (mvs) is now in development and soon will be > present for testing. Together with many other people I have tested above > at least on i386, amd64, arm and spart64 architectures. > > This switchover would give us significant performance improvement on new > hardware because of NCQ support in ahci/siis/mvs drivers; improved > functionality, including SATA Port Multipliers support, better hot-plug > support; and reduced code duplication between ata(4) and cam(4) > subsystems and applications. > > Two issues left at this moment are: > 1) POLA breakage due to disk device being renamed from adX to adaY; > 2) lack of araraid(4) alternative in new infrastructure. It should be > reimplemented in GEOM in some way, but it still wasn't. > > So what is the public opinion: Is the lack of ataraid(4) fatal or we can > live without it? > > Can we do switchover now, or some more reasons preventing this? > As noted earlier, pc98 and sparc64 need ada(4)/CAM ATA to perform geometry translation as done by ad_firmware_geom_adjust() for ad(4), which the following patch hooks up to both: http://people.freebsd.org/~marius/ata_disk_firmware_geom_adjust.diff You preferred to implement such functionality via XPT_CALC_GEOMETRY though (I'm still not convinced that it makes sense to put this functionality into every ATA SIM the same way it is done for SCSI rather than letting ada(4) handle it the same way for all SIMs however). Have you looked into implementing XPT_CALC_GEOMETRY for ATA CAM or is it okay to commit the above patch? 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: Switchover to CAM ATA?
On Fri, Apr 23, 2010 at 09:40:59AM +0300, Andriy Gapon wrote: > on 23/04/2010 07:48 Szilveszter Adam said the following: > > There is one interesting tidbit though: previously it used to be > > possible to run cdda2wav also as non-root, provided the user running it > > had read access to the /dev/cd0 device. This seems to no longer work. > > Probably you also need access to the corresponding passX device, which you can > find from output of 'camcontrol devlist'. > You didn't need that with *a*cd0. That seems to be it, the perms on pass1 needed fixing. Thanks for the tip! -- Regards: Szilveszter ADAM Budapest Hungary ___ 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: Switchover to CAM ATA?
Hello, Nenhum_de_Nos.
You wrote 23 апреля 2010 г., 09:08:05:
>> > and RAID5 (due to lack of module in a base system).
>> I'm cleaning up gradi5 now according to style(9) and want to make
>> port out of it in month or two ("unfortunalety", I have alot of paid
>> work, which is not FreeBSD-related in any way).
>> It works very well for me on, and I have one HDD crash already,
>> recovered with graid5 :)
> this means graid5 in the tree ?
Unfortunalety, it means graid5 in ports only for now. But in
future... who knows?
--
// Black Lion AKA Lev Serebryakov
___
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: Switchover to CAM ATA?
On 2010-04-23, Scott Long wrote: > My advice is to retrain your fingers to use cdrecord. Burncd is > highly specific to the old ata driver, and "adding SCSI support" to it > would likely involve a complete rewrite. Well, I did that by porting parts of acd(4) to user space. -- Jaakko ___ 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: Switchover to CAM ATA?
On Fri, Apr 23, 2010 at 1:41 AM, Paul Wootton wrote: > Alexander Motin wrote: > >> >> Can we do switchover now, or some more reasons preventing this? >> >> The only thing I miss about the old ATA layer was that I knew that a drive > on a particular controller would always be assigned the same adX number, > whether is was present at boot time, or added days later. This could get a > little messy having ad2, ad4, ad12, ad20 and ad22, but at least if I added a > new drive, it would always attach to say ad8. > > Can this be done on the new CAM ATA? I have not tried it with ATA_CAM, but in theory, you should be able to wire things down the same as with SCSI devices. Just takes a bit of mucking around with camcontrol output, and sticking the right info into /boot/loader.conf. See the man page for camcontrol for all the details. -- 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: Switchover to CAM ATA?
John Baldwin wrote: > On Thursday 22 April 2010 11:31:37 am Alexander Motin wrote: >> If ataraid(4) should be reimplemented in GEOM, then how exactly? One >> more separate RAID infrastructure in GEOM (third?) looks excessive. >> Reuse gmirror, gstripe,... code would be nice, but will make them more >> complicated and could be not easy for RAID0+1 (due to common metadata) >> and RAID5 (due to lack of module in a base system). > > Scott's view (which sounds good to me) is that GEOM should include a library > of routines for working with common transforms such as RAID1, striping, etc. > Each ATA RAID vendor format would then consist of a small GEOM module that > used the library routines to manage all the I/O and the bulk of the module > would be managing a specific metadata format. Yes, I remember he proposed it somewhere. Idea is fine. Somebody with sharp axe and lack of fear should just chop half of GEOM modules into small pieces and collect them back. ;) -- 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: Switchover to CAM ATA?
On Apr 23, 2010, at 7:50 AM, John Baldwin wrote: > On Thursday 22 April 2010 11:31:37 am Alexander Motin wrote: >> If ataraid(4) should be reimplemented in GEOM, then how exactly? One >> more separate RAID infrastructure in GEOM (third?) looks excessive. >> Reuse gmirror, gstripe,... code would be nice, but will make them more >> complicated and could be not easy for RAID0+1 (due to common metadata) >> and RAID5 (due to lack of module in a base system). > > Scott's view (which sounds good to me) is that GEOM should include a library > of routines for working with common transforms such as RAID1, striping, etc. > Each ATA RAID vendor format would then consist of a small GEOM module that > used the library routines to manage all the I/O and the bulk of the module > would be managing a specific metadata format. > THIS It's hard for me to talk about RAID and FreeBSD without getting into a long sermon, so I'll try to keep this short. RAID is about data integrity, not about mirror/stripe/parity algorithms. Those algorithms are just a small part of RAID, and are merely tools for achieving the goals of RAID. But RAID != algorithms. It's like how we use linked lists extensively within the kernel, but the kernel != linked lists. A well-designed software raid stack is going to be an engine that manages topology, executes and rolls back I/O transactions, and handles error recovery. On-disk metadata is again just an algorithm that is part of this whole picture, and should be modularized as such along with the transforms. And to be even more brief, the existing GEOM RAID modules are designed in completely the wrong direction from this. Caveat Emptor. 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: Switchover to CAM ATA?
On Apr 23, 2010, at 8:00 AM, Jaakko Heinonen wrote: > On 2010-04-23, Alexander Best wrote: >> has anybody thought about adding scsi support to burncd(8)? i've been using >> ATA CAM for quite a while now and really love it. however i miss burncd(8). > > I have thought about it. The mail I posted in December didn't generate > any interest. > > http://docs.freebsd.org/cgi/mid.cgi?20091214182645.GA2764 > My advice is to retrain your fingers to use cdrecord. Burncd is highly specific to the old ata driver, and "adding SCSI support" to it would likely involve a complete rewrite. 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: Switchover to CAM ATA?
On Fri, Apr 23, 2010 at 09:50:33AM -0400, John Baldwin wrote: > On Thursday 22 April 2010 11:31:37 am Alexander Motin wrote: > > If ataraid(4) should be reimplemented in GEOM, then how exactly? One > > more separate RAID infrastructure in GEOM (third?) looks excessive. > > Reuse gmirror, gstripe,... code would be nice, but will make them more > > complicated and could be not easy for RAID0+1 (due to common metadata) > > and RAID5 (due to lack of module in a base system). > > Scott's view (which sounds good to me) is that GEOM should include a library > of routines for working with common transforms such as RAID1, striping, etc. > Each ATA RAID vendor format would then consist of a small GEOM module that > used the library routines to manage all the I/O and the bulk of the module > would be managing a specific metadata format. I remember that SCSI standard has support for xor read-modify-write operations in addition to normal read/write to reduce R5 latency and bandwith. I'm not sure if any devices actually support it, but I think this may be worthwhile for networked devices. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Switchover to CAM ATA?
On 2010-04-23, Alexander Best wrote: > has anybody thought about adding scsi support to burncd(8)? i've been using > ATA CAM for quite a while now and really love it. however i miss burncd(8). I have thought about it. The mail I posted in December didn't generate any interest. http://docs.freebsd.org/cgi/mid.cgi?20091214182645.GA2764 -- Jaakko ___ 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: Switchover to CAM ATA?
On Thursday 22 April 2010 11:31:37 am Alexander Motin wrote: > If ataraid(4) should be reimplemented in GEOM, then how exactly? One > more separate RAID infrastructure in GEOM (third?) looks excessive. > Reuse gmirror, gstripe,... code would be nice, but will make them more > complicated and could be not easy for RAID0+1 (due to common metadata) > and RAID5 (due to lack of module in a base system). Scott's view (which sounds good to me) is that GEOM should include a library of routines for working with common transforms such as RAID1, striping, etc. Each ATA RAID vendor format would then consist of a small GEOM module that used the library routines to manage all the I/O and the bulk of the module would be managing a specific metadata format. -- John Baldwin ___ 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: Switchover to CAM ATA?
On 04/23/10 14:32, Andriy Gapon wrote: on 23/04/2010 12:28 Alexander Best said the following: has anybody thought about adding scsi support to burncd(8)? i've been using ATA CAM for quite a while now and really love it. however i miss burncd(8). i found it to be much easier to use and less buggy than cdrecord(1). burncd for CAM (SCSI, ATAPI) will be something very close to cdrecord or growisofs. How different are the interfaces? I mean - since they talk to the same device, are the differences just API / superficial or is there something fundamentally different that cannot be implemented within burncd? (I agree that burncd is very nice to have and more logical to use than cdrecord.) ___ 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: Switchover to CAM ATA?
on 23/04/2010 12:28 Alexander Best said the following: > has anybody thought about adding scsi support to burncd(8)? i've been using > ATA CAM for quite a while now and really love it. however i miss burncd(8). i > found it to be much easier to use and less buggy than cdrecord(1). burncd for CAM (SCSI, ATAPI) will be something very close to cdrecord or growisofs. -- Andriy Gapon ___ 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: Switchover to CAM ATA?
Paul Wootton wrote: > Alexander Motin wrote: >> Can we do switchover now, or some more reasons preventing this? > > The only thing I miss about the old ATA layer was that I knew that a > drive on a particular controller would always be assigned the same adX > number, whether is was present at boot time, or added days later. This > could get a little messy having ad2, ad4, ad12, ad20 and ad22, but at > least if I added a new drive, it would always attach to say ad8. > > Can this be done on the new CAM ATA? Binding to controller ports and device IDs can be managed for any CAM device via device.hints as described in cam(4). This scheme is a slightly more complicated (you have to explicitly define wanted mapping), but more flexible. Previous one just inapplicable now. Modern controllers (especially with Port Multipliers) could support different (often big) number of devices per channel, making device list with static numbering too sparse. -- 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: Switchover to CAM ATA?
has anybody thought about adding scsi support to burncd(8)? i've been using ATA CAM for quite a while now and really love it. however i miss burncd(8). i found it to be much easier to use and less buggy than cdrecord(1). since eventually the whole ata(4) subsystem will be dumped in favour of cam(4) i guess the fate of ata(4) dependant binaries in the base should also be discussed. maybe somebody could put together a list of ata(4) dependant binaries currently in base in addition to burncd(8) and atacontrol(8)? -- Alexander Best ___ 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: Switchover to CAM ATA?
Alexander Motin wrote: Can we do switchover now, or some more reasons preventing this? The only thing I miss about the old ATA layer was that I knew that a drive on a particular controller would always be assigned the same adX number, whether is was present at boot time, or added days later. This could get a little messy having ad2, ad4, ad12, ad20 and ad22, but at least if I added a new drive, it would always attach to say ad8. Can this be done on the new CAM ATA? Paul ___ 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: Switchover to CAM ATA?
on 23/04/2010 07:48 Szilveszter Adam said the following: > There is one interesting tidbit though: previously it used to be > possible to run cdda2wav also as non-root, provided the user running it > had read access to the /dev/cd0 device. This seems to no longer work. Probably you also need access to the corresponding passX device, which you can find from output of 'camcontrol devlist'. You didn't need that with *a*cd0. -- Andriy Gapon ___ 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: Switchover to CAM ATA?
On Fri, Apr 23, 2010 at 06:48:09AM +0200 I heard the voice of Szilveszter Adam, and lo! it spake thus: > > There is one interesting tidbit though: previously it used to be > possible to run cdda2wav also as non-root, provided the user running it > had read access to the /dev/cd0 device. This seems to no longer work. > > Has anybody else noticed this? I think you may need to use the /dev/xpt* or /dev/pass* perms. Can't remember which. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: Switchover to CAM ATA?
On 22-04-2010 18:31, Alexander Motin wrote: > Hi. > > With time passed, CAM-based ATA infrastructure IMHO looks enough mature > now to enable it in HEAD. Now we have two new stable drivers ahci(4) and > siis(4), covering major part of modern SATA HBAs, `options ATA_CAM` > wrapper for ata(4) to supports legacy hardware, and one more improved > driver for Marvell HBAs (mvs) is now in development and soon will be > present for testing. Together with many other people I have tested above > at least on i386, amd64, arm and spart64 architectures. If we want this in 9.0 we should probably switch to CAM ATA in HEAD now in order to allow enough testing before the release. -- Joel ___ 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: Switchover to CAM ATA?
On Thu, 22 Apr 2010 22:28:03 +0400
Lev Serebryakov wrote:
> Hello, Alexander.
> You wrote 22 апреля 2010 г., 19:31:37:
>
> > and RAID5 (due to lack of module in a base system).
> I'm cleaning up gradi5 now according to style(9) and want to make
> port out of it in month or two ("unfortunalety", I have alot of paid
> work, which is not FreeBSD-related in any way).
> It works very well for me on, and I have one HDD crash already,
> recovered with graid5 :)
this means graid5 in the tree ?
if so, great :)
never seen how to make simple raid5 in not-so-great memory systems tht can't
afford to have zfs. I have a Pentium II with 192MB ram that is a great small
file server and runs both gmirror and gstripe fine.
thanks,
matheus
--
We will call you cygnus,
The God of balance you shall be
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
http://en.wikipedia.org/wiki/Posting_style
___
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: Switchover to CAM ATA?
Dear Alexander, dear collegaues, On Thu, Apr 22, 2010 at 06:31:37PM +0300, Alexander Motin wrote: > Can we do switchover now, or some more reasons preventing this? I have been using ATA_CAM with legacy support for ata(4) for some time, and have found it to be stable and very useable. I have even removed atapicam from the kernel, since it is no longer needed, I have the /dev/cd0 device also without. So, in my opinion it is ready for prime-time also on legacy hw. There is one interesting tidbit though: previously it used to be possible to run cdda2wav also as non-root, provided the user running it had read access to the /dev/cd0 device. This seems to no longer work. Has anybody else noticed this? -- Regards: Szilveszter ADAM Budapest Hungary ___ 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: Switchover to CAM ATA?
Richard Tector wrote: On 22/04/2010 19:48, Maxim Sobolev wrote: Alexander Motin wrote: So what is the public opinion: Is the lack of ataraid(4) fatal or we can live without it? I believe it's fatal in long run. This would present significant challenge for users who rely on this functionality from upgrading from 8.x to 9.0 later on. Especially for ones using striped disks and RAID5. Therefore while it's no problem to have it in HEAD for now, but it will have to be addressed before the release. Could I also add that the removal of ataraid would affect those users who dual-boot with Windows and rely on the psuedo-raid provided by most Intel chipsets to be able to share the same pair of disks. Well, this won't be a problem if we have GEOM classes that can understand metadata created by the ATA RAID BIOS(es). But we don't those classes at the moment. -Maxim ___ 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: Switchover to CAM ATA?
On 22/04/2010 19:48, Maxim Sobolev wrote: Alexander Motin wrote: So what is the public opinion: Is the lack of ataraid(4) fatal or we can live without it? I believe it's fatal in long run. This would present significant challenge for users who rely on this functionality from upgrading from 8.x to 9.0 later on. Especially for ones using striped disks and RAID5. Therefore while it's no problem to have it in HEAD for now, but it will have to be addressed before the release. Could I also add that the removal of ataraid would affect those users who dual-boot with Windows and rely on the psuedo-raid provided by most Intel chipsets to be able to share the same pair of disks. Regards, Richard ___ 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: Switchover to CAM ATA?
Alexander Motin wrote: So what is the public opinion: Is the lack of ataraid(4) fatal or we can live without it? I believe it's fatal in long run. This would present significant challenge for users who rely on this functionality from upgrading from 8.x to 9.0 later on. Especially for ones using striped disks and RAID5. Therefore while it's no problem to have it in HEAD for now, but it will have to be addressed before the release. -Maxim ___ 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: Switchover to CAM ATA?
Hello, Alexander.
You wrote 22 апреля 2010 г., 19:31:37:
> and RAID5 (due to lack of module in a base system).
I'm cleaning up gradi5 now according to style(9) and want to make
port out of it in month or two ("unfortunalety", I have alot of paid
work, which is not FreeBSD-related in any way).
It works very well for me on, and I have one HDD crash already,
recovered with graid5 :)
--
// Black Lion AKA Lev Serebryakov
___
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: Re: Switchover to CAM ATA?
22.04.10, 11:17, "Adam Vande More": > I think sade(and by further discussion sysinstall) is now getting some > attention and now supports geom devices, zfs, etc at least in one person's > testbed. I know that's it's been tried before but there are actually > screenshots from it. > > http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016418.html Yes, I have plans to add support of simple GEOM-based RAID management in sade. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Switchover to CAM ATA?
Short opinion from me: Yes, for HEAD. Not MFC'able. It's too major a change for that. ___ 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: Switchover to CAM ATA?
On Thu, Apr 22, 2010 at 11:25 AM, Julian Elischer wrote: > just one little fly in that ointment... booting. > > You need to be able to act with the raid in the same way the bios does > or you can't boot. I don't think geom would easlily do that but I could be > wrong. Certainly if you treat teh ata raid as just a bunch of striped disks, > then the bios will not be able to boot off it. > > of course don't take my word too seriosly asn I'm not running an ata raid > system at the moment. > gmirror booting works great only thing to change is fstab to reflect block dev changes, gstripe doesn't. I honestly wasn't aware ataraid could boot a striped volume, if so it does something geom can't. -- 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: Switchover to CAM ATA?
On 4/22/10 9:17 AM, Adam Vande More wrote: +1 on ataraid's retirement. just one little fly in that ointment... booting. You need to be able to act with the raid in the same way the bios does or you can't boot. I don't think geom would easlily do that but I could be wrong. Certainly if you treat teh ata raid as just a bunch of striped disks, then the bios will not be able to boot off it. of course don't take my word too seriosly asn I'm not running an ata raid system at the moment. ___ 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: Switchover to CAM ATA?
On Thu, Apr 22, 2010 at 10:42 AM, Freddie Cash wrote: > If a lowly user's vote counts for anything, I'd vote for the complete > removal of ataraid support. We have gstripe, gmirror, graid3, graid5, and > zfs (and gvinum for the masochistics). :) We don't need to support any of > the crappy pseudo-raid "hardware" out there. ataraid(4) has served it's > purpose, tiding us over until GEOM RAID facilities were in place. Now it's > time for it to be retired. > +1 on ataraid's retirement. > It doesn't seem to me that sysinstall supports gmirror or gstripe, so > even if they could be better, currently I think many users still use > ataraid for simple installations with mirrored disks. It's hard to say, I'm sure there are some. It's fairly trivial to create gmirrors or gstripes after the install is complete. Also, gstripe's are not bootable volumes. Handbook documentation has been guiding users to gmirror for some time now and gmirror is just much easier to work with IMO. I think sade(and by further discussion sysinstall) is now getting some attention and now supports geom devices, zfs, etc at least in one person's testbed. I know that's it's been tried before but there are actually screenshots from it. http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016418.html -- 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: Switchover to CAM ATA?
Freddie Cash ha scritto: >> So what is the public opinion: Is the lack of ataraid(4) fatal or we can >> live without it? Lack of ataraid means no more arX devices, right? I'd say it's not fatal for HEAD, but it is for a -STABLE branch. > ataraid(4) has served it's > purpose, tiding us over until GEOM RAID facilities were in place. Now it's > time for it to be retired. It doesn't seem to me that sysinstall supports gmirror or gstripe, so even if they could be better, currently I think many users still use ataraid for simple installations with mirrored disks. -- Alex Dupre ___ 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: Switchover to CAM ATA?
2010/4/22 Alexander Motin > With time passed, CAM-based ATA infrastructure IMHO looks enough mature > now to enable it in HEAD. Now we have two new stable drivers ahci(4) and > siis(4), covering major part of modern SATA HBAs, `options ATA_CAM` > wrapper for ata(4) to supports legacy hardware, and one more improved > driver for Marvell HBAs (mvs) is now in development and soon will be > present for testing. Together with many other people I have tested above > at least on i386, amd64, arm and spart64 architectures. > I haven't updated my 8-STABLE box in a couple of weeks. Have the issues with ATAPI DVD-burners been worked out, when using ATA_CAM? Back in Jan/Feb, thereabouts, I tested an ATA_CAM kernel and could not get a device node of any kind to show up for the DVD burner (no acd0, no cd0, nothing in dmesg). A non-ATA_CAM kernel shows both acd0 and cd0. Maybe I'll update my system this weekend and give ATA_CAM another test run. This switchover would give us significant performance improvement on new > hardware because of NCQ support in ahci/siis/mvs drivers; improved > functionality, including SATA Port Multipliers support, better hot-plug > support; and reduced code duplication between ata(4) and cam(4) > subsystems and applications. > > Two issues left at this moment are: > 1) POLA breakage due to disk device being renamed from adX to adaY; > 2) lack of araraid(4) alternative in new infrastructure. It should be > reimplemented in GEOM in some way, but it still wasn't. > > So what is the public opinion: Is the lack of ataraid(4) fatal or we can > live without it? > > Can we do switchover now, or some more reasons preventing this? > > If ataraid(4) should be reimplemented in GEOM, then how exactly? One > more separate RAID infrastructure in GEOM (third?) looks excessive. > Reuse gmirror, gstripe,... code would be nice, but will make them more > complicated and could be not easy for RAID0+1 (due to common metadata) > and RAID5 (due to lack of module in a base system). If a lowly user's vote counts for anything, I'd vote for the complete removal of ataraid support. We have gstripe, gmirror, graid3, graid5, and zfs (and gvinum for the masochistics). :) We don't need to support any of the crappy pseudo-raid "hardware" out there. ataraid(4) has served it's purpose, tiding us over until GEOM RAID facilities were in place. Now it's time for it to be retired. -- 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"
