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
Alexander Motin m...@freebsd.org 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.
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 l...@freebsd.org
___
Lev Serebryakov l...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no 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,
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
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
Freddie Cash fjwc...@gmail.com 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
Maxim Sobolev sobo...@freebsd.org writes:
Richard Tector richardtec...@thekeelecentre.com 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
Dag-Erling Smørgrav wrote:
Maxim Sobolev sobo...@freebsd.org writes:
Richard Tector richardtec...@thekeelecentre.com 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
Alexander Motin m...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no 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
Dag-Erling Smørgrav wrote:
Alexander Motin m...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no 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
On Apr 27, 2010, at 7:34 AM, Dag-Erling Smørgrav wrote:
Maxim Sobolev sobo...@freebsd.org writes:
Richard Tector richardtec...@thekeelecentre.com 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
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 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
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
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
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:
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
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
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
In message: 20100426181209.gb3...@garage.freebsd.pl
Pawel Jakub Dawidek p...@freebsd.org 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
On Mon, Apr 26, 2010 at 12:19:46PM -0600, M. Warner Losh wrote:
In message: 20100426181209.gb3...@garage.freebsd.pl
Pawel Jakub Dawidek p...@freebsd.org 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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.
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
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
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
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 Fri, Apr 23, 2010 at 1:41 AM, Paul Wootton
p...@fletchermoorland.co.ukwrote:
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
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
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
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
2010/4/22 Alexander Motin m...@freebsd.org
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
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
On Thu, Apr 22, 2010 at 11:25 AM, Julian Elischer jul...@elischer.orgwrote:
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
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
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.
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).
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
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
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
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
On Thu, 22 Apr 2010 22:28:03 +0400
Lev Serebryakov l...@freebsd.org 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
60 matches
Mail list logo
