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
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 fai
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
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
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
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
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 th
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 documen
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
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.
>>
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 i
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. at
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 depe
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
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 op
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
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 ``r
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 technolog
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
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 own
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 it
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 t
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
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
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 imp
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
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 ca
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 j
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).
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 Dece
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-tim
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`
> wrap
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/c
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-re
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
_
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
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
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 b
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
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,..
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
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
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
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 (
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
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)
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
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 acces
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
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 sup
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 ("unfortunal
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
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
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
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 usi
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
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:/
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...@fr
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 a
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 y
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 pse
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
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, an
63 matches
Mail list logo
