moving providers between unaware geoms.
So my question is: does it make sense to try fix/modernize it, or it
just be easier to remove it? Does anybody still use it, or see some
future for it?
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing
ll most likely result in breaking compatibility and inability to read
previously written data. ZFS already uses physical block size when
possible -- on pool creation or new vdev addition. When not possible
(pool already created wrong) it just complains about it, so that user
would know that his config
27;t see much other
checks for BIO_DONE, so I would guess it should not be a problem. Any
way, unlocked BIO_DONE setting there should be pointless or at least
unreliable, except may be for some debugging.
--
Alexander Motin
___
freebsd-geom@freebsd.org
esent in GRAID. AFAIR the
problem is in keeping lock order between GEOM topology lock and class'
own lock.
The only "excuse" is that it is not very reasonable to have ZFS on top
of GMIRROR or GRAID.
--
Alexander Motin
___
freebsd-geom@fr
may
cause incorrect combination of BIO flags and addresses.
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
On 07.10.2013 19:09, John Baldwin wrote:
On Sunday, October 06, 2013 3:30:42 am Alexander Motin wrote:
On 02.10.2013 20:30, John Baldwin wrote:
On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote:
On 07.09.2013 02:02, Jeremie Le Hen wrote:
On Fri, Sep 06, 2013 at 11:29:11AM
On 02.10.2013 20:30, John Baldwin wrote:
On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote:
On 07.09.2013 02:02, Jeremie Le Hen wrote:
On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote:
On 06.09.2013 11:06, Jeremie Le Hen wrote:
On Fri, Sep 06, 2013 at 12:46:27AM
On 07.09.2013 02:02, Jeremie Le Hen wrote:
On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote:
On 06.09.2013 11:06, Jeremie Le Hen wrote:
On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé wrote:
On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin wrote:
I've
On 06.09.2013 11:06, Jeremie Le Hen wrote:
On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé wrote:
On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin wrote:
I've found and fixed possible double request completion, that could cause
such symptoms if happened. Updated patch lo
On 04.09.2013 19:31, Olivier Cochard-Labbé wrote:
On Wed, Sep 4, 2013 at 9:01 AM, Alexander Motin wrote:
- HP EliteBook 8460p (amd64: r255188) with DVD replaced by a second
hardrive (where fbsd is installed): It crash just after the message
"GEOM: new disk ada1" during boot
scr
On 04.09.2013 15:45, Nathan Whitehorn wrote:
On 09/04/13 02:01, Alexander Motin wrote:
On 04.09.2013 00:48, Olivier Cochard-Labbé wrote:
On Tue, Sep 3, 2013 at 8:10 PM, Outback Dingo
wrote:
Can anyone confirm how well tested/stable this patch set might be?? if
theres positive input i have a
to some GEOM class. Could you describe/show all GEOM
topology, file systems, etc. you have there?
gpart show
sysctl kern.geom.confxml
...
Thank you!
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman
ed by iXsystems, Inc.
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
On 15.04.2013 23:43, Poul-Henning Kamp wrote:
In message <516c515a.9090...@freebsd.org>, Alexander Motin writes:
I propose to switch that
statistics from using binuptime() to getbinuptime() to solve the problem
globally.
No objections here, but I wonder if you were able to compa
On 15.04.2013 21:42, Pawel Jakub Dawidek wrote:
On Sat, Apr 13, 2013 at 12:59:49PM +0300, Alexander Motin wrote:
Hi.
It is long known that collecting disk and GEOM statistics may cause
significant processing overhead under high IOPS. On my recent high-IOPS
benchmarks performance difference was
to the timecounter performance:
http://people.freebsd.org/~mav/devstat_time.patch
Are there any objections against it?
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe
if (error == 0 && i != 0)
disk->d_flags |= G_MIRROR_DISK_FLAG_CANDELETE;
if (md->md_provider[0] != '\0')
disk->d_flags |= G_MIRROR_DISK_FLAG_HARDCODED;
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
The following reply was made to PR kern/147667; it has been noted by GNATS.
From: Alexander Motin
To: bug-follo...@freebsd.org, sven.kirm...@kzone.ch
Cc:
Subject: Re: kern/147667: [gmirror] Booting with one component of a gmirror,
then with the other leads to an inconsistent gmirror device
The following reply was made to PR kern/170038; it has been noted by GNATS.
From: Alexander Motin
To: bug-follo...@freebsd.org, frankrep...@googlemail.com
Cc:
Subject: Re: kern/170038: [geom] geom_mirror always starts degraded after
reboot
Date: Tue, 15 Jan 2013 10:34:16 +0200
That is
The following reply was made to PR kern/169539; it has been noted by GNATS.
From: Alexander Motin
To: bug-follo...@freebsd.org, al...@alter.org.ua
Cc:
Subject: Re: kern/169539: [geom] [patch] fix ability to run gmirror on MSI
MegaRaid (/dev/ar* vs /dev/gm*)
Date: Tue, 15 Jan 2013 03:40:23
On 24.07.2012 10:49, Andriy Gapon wrote:
on 23/07/2012 16:42 Alexander Motin said the following:
Patch can be found here:
http://people.freebsd.org/~mav/mediachange8.patch
Any comments/objections/propositions?
Alexander,
would it make sense for scsi_cd to also use GET EVENT STATUS
32
command slots per port can be enough for many workloads to enqueue all
commands to the hardware and leave queue empty as you've described. But
if you take harder workload, or controller/ device without command
queueing support, extra requests will
ESTROY cdev=msdosfs/NIKON D7000
Patch can be found here:
http://people.freebsd.org/~mav/mediachange8.patch
Any comments/objections/propositions?
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-
On 11.05.2012 15:59, Karl Pielorz wrote:
--On 11 May 2012 14:32 +0300 Alexander Motin wrote:
Yes, sometimes bubble and in rare cases panic. I am working on the first
part right now.
Is the same true for reads?
No, On read error graid repeats reading from another disk and does
remapping
On 11.05.2012 14:08, Karl Pielorz wrote:
--On 10 May 2012 18:26 +0300 Alexander Motin wrote:
This panic is not in graid code, but it can be called a problem of the
graid's RAID1 implementation. If some disk returns _write_ failure, that
failure may now be reported to higher levels. Probl
On 10.05.2012 19:36, Trent Nelson wrote:
On Thu, May 10, 2012 at 08:41:28AM -0700, Alexander Motin wrote:
Hi.
> It'd be ideal if there was a way of teaching gmultipath about a path
> cost/priority, so that it can make an informed decision about which
> path to choose
as all
paths have exactly the same metadata and provider names are not
mentioned there, separate paths properties are not possible at this moment.
As dirty workaround, you may periodically run some script to enforce
active path on your specific preference.
--
A
t
nearest time.
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
The following reply was made to PR kern/165745; it has been noted by GNATS.
From: Alexander Motin
To: bug-follo...@freebsd.org, woll...@csail.mit.edu
Cc:
Subject: Re: kern/165745: [geom] geom_multipath page fault on removed drive
Date: Tue, 13 Mar 2012 17:37:28 +0200
New GEOM_MULTIPATH code
Hi.
> I expect there must be an easier way.
If your system has one of supported software RAID BIOSes (Intel,
AMD/Promise, NVIDIA, SiI, JMicron), you may just use geom_raid to boot
from it's RAID10 volume with no additional magic.
--
Alexand
On 01/20/12 15:27, Nikolay Denev wrote:
On Jan 20, 2012, at 2:31 PM, Alexander Motin wrote:
On 01/20/12 14:13, Nikolay Denev wrote:
On Jan 20, 2012, at 1:30 PM, Alexander Motin wrote:
On 01/20/12 13:08, Nikolay Denev wrote:
On 20.01.2012, at 12:51, Alexander Motinwrote:
On 01/20/12
On 01/20/12 14:13, Nikolay Denev wrote:
On Jan 20, 2012, at 1:30 PM, Alexander Motin wrote:
On 01/20/12 13:08, Nikolay Denev wrote:
On 20.01.2012, at 12:51, Alexander Motin wrote:
On 01/20/12 10:09, Nikolay Denev wrote:
Another thing I've observed is that active/active probably only
On 01/20/12 13:08, Nikolay Denev wrote:
On 20.01.2012, at 12:51, Alexander Motin wrote:
On 01/20/12 10:09, Nikolay Denev wrote:
Another thing I've observed is that active/active probably only makes sense if
you are accessing single LUN.
In my tests where I have 24 LUNS that form 4 vde
/active devices without knowledge about each other with
some probability will send part of requests via the same links, while
ZFS itself already does some balancing between vdevs.
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://li
On 10/31/11 22:10, Alexander Motin wrote:
> Attempt to fix some GEOM MULTIPATH issues made me almost rewrite it. So
> I would like to present my results and request for testing and feedback.
>
> The main changes:
> - Improved locking and destruction process to fix crashe
bably just look through the built-in help, see "create", and then use it.
> (I'm guilty as charged here, I didn't realize at first that I was using
> manual mode.)
It is a somewhat unified among several GEOM classes that label is for
automatic method and create is for ma
On 11/01/11 14:39, Pawel Jakub Dawidek wrote:
> On Mon, Oct 31, 2011 at 10:10:14PM +0200, Alexander Motin wrote:
>> Attempt to fix some GEOM MULTIPATH issues made me almost rewrite it. So
>> I would like to present my results and request for testing and feedback.
>>
~mav/gmultipath4.patch
Feedbacks are welcome!
Sponsored by: iXsystems, Inc.
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
idea, IMHO.
And what if class is not loaded/supported? There should be a way to
manage/clear that label.
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
ge metadata format for these GEOMs, so it will not be
> backward-compatible.
>
> And, yes, it seems to be much more intrusive change in GEOM
> subsystem (because it will change tasting sequence), and should be
> supervised by other developers from very beginning.
>
> I co
o prevent disk
resurrection in most cases.
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
d
itself) is tightly hardcoded to talk to ZFS, fetching statuses and
making control actions. Not sure whether this functionality could be
scripted within geom-events, but having single mechanism indeed would be
nice.
--
Alexander Motin
___
freebsd-geom@fr
Gavin Atkinson wrote:
> On Thu, 23 Jun 2011, Alexander Motin wrote:
>> On 23.06.2011 20:53, Gavin Atkinson wrote:
>>> While debugging a problem that looks like it was unrelated to geom_raid,
>>> I realised that it tastes all providers, including each partition and
&
ady, putting it in GENERIC may
at least help slightly...
Aggressive tasting for each metadata format was actually the reason why
I haven't added it. If we load all GEOM modules, then some floppy
tasting will take ages.
--
Alexander Motin
___
freebsd
set in
case if user specified wanted alignment on command line. Proper fix I
think would be in adding there:
offset %= alignment;
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To u
.
Special thanks to Cisco Systems, Inc. and iXsystems, Inc. for sponsoring
this project.
--
Alexander Motin
___
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd
46 matches
Mail list logo
