that consumer.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-
(9)?
>Or do some sort of geom spoil on it?
Basically yes.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be e
In message <4d9d4b10.1080...@freebsd.org>, Andriy Gapon writes:
>on 07/04/2011 03:09 Poul-Henning Kamp said the following:
>> In message <4d9c7b52.5010...@freebsd.org>, Andriy Gapon writes:
>>
>>> Suppose we implemented a mechanism to detect removal or change o
nsistency.
And good observation btw, it was a big mistake to use the same /dev
entry for both drive and media, but waaay to late to fix it now.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
In message <20110407125054.ga71...@psconsult.nl>, Paul Schenkeveld writes:
>On Thu, Apr 07, 2011 at 10:10:58AM +0000, Poul-Henning Kamp wrote:
>> And good observation btw, it was a big mistake to use the same /dev
>> entry for both drive and media, but waaay to late to fix it
In message <4d9ea91b.80...@freebsd.org>, Andriy Gapon writes:
>
>It doesn't look like EDIRIOCTL is used anywhere in the code.
>Are there any plans to use it for something in the future or is it just a
>leftover?
I think it is a leftover.
--
Poul-Henning Kamp | UNI
ut not enforce it.
There are a lot of valid reasons to not track-align, most commonly
the desire to not shoot RAID-5 performance in the foot.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
N
linder]
^^
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incomp
wo lines */
>g_detach(cp);
>g_destroy_consumer(cp);
It really depends what "a lot" actually is.
It is perfectly legal and acceptable for a consumer to be attached to a provider
without holding an access count.
But lacking an access count, there are obviously things you cannot do t
out holding the topology lock.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
In message <5088fe30.2030...@freebsd.org>, Andriy Gapon writes:
>on 25/10/2012 11:41 Poul-Henning Kamp said the following:
>To clarify, if that's needed, by "geom's access method" I meant the 'access'
>member with g_access_t type in stru
In message <50890251.8090...@freebsd.org>, Andriy Gapon writes:
>Now need to think hard how to avoid doing that nasty thing...
Nothing prevents a GEOM from having multiple consumers attached to the
same provider. That opens a lot of interesting options.
--
Poul-Hen
In message
, Luca
Ferrari writes:
>I'm curious to know if GEOM stands for something or does not have any
>particular meaning. I was unable to figure it out.
It's shorthand for "geometry"
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.
o know.
The cost 20 64bit counters in struct devstat (N|R|W|E)*5*8 = 160
bytes, but since devstat is already 288 bytes, that isn't a major
catastropy.
The ability to measure latency precisly should be retained, but it
could be made a sysctl enabled debugging facility.
The %busy crap should b
In message <516c71bc.4000...@freebsd.org>, Alexander Motin writes:
>On 15.04.2013 23:43, Poul-Henning Kamp wrote:
>> In message <516c515a.9090...@freebsd.org>, Alexander Motin writes:
>>
>> For tuning anything on a non-ridiculous SSD device or modern
>> h
In message <20131101103158.GA35397@lemon>, symbol...@gmx.com writes:
>A few example things I'd like to work on (in no particular order):
Go for it.
My calendar does not allow me to be your mentor at this time, but
I hope somebody else will step up ?
--
Poul-Henning Kamp
sed on the exported XML state of the geom-mesh and support
modules mirroring actual logic for all relevant geoms, that way
it would at least live in userland.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD si
ks unpredictable.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
a driver bug to call disk_destroy() before purging all in-flight bios
with biodone()
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to m
In message <8de79017-f0b0-c86a-93c5-65be4d97b...@freebsd.org>, Andriy Gapon wri
tes:
>So, the correct sequence should be:
>- call disk_gone() to prevent new I/O
>- handle all in-flight I/O
>- call disk_destroy()
>Is that right?
exactly!
--
Poul-Henning Kamp
gt;attached and when vfs_mountroot runs, but I wouldn't want to rely on that.
>
>Am I missing something?
As I recall, the actual open will stall on the non-empty event-queue.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
Fre
a temp-space:
allocate temp buffer
if (write)
copy write data to temp buffer
issue bio downwards on temp buffer
if timeout
park temp buffer until biodone
return(timeout)
if (read)
copy temp buffer to r
WRITE|DELETE} are wrapped in these.
BIO_GETATTR should probably not require a BIO_OPEN/BIO_CLOSE.
Poul-Henning
[1] The alternative would be to have different sub-trees, each of
which can be locked individually, but that requires a LOT of
housekeeping and class-complexity in order to find
In message <5e416eb6-0e79-1419-f09a-eb747215d...@freebsd.org>, Andriy Gapon
writes:
>On 12/03/2018 20:07, Poul-Henning Kamp wrote:
>> If we want to have an architectural sound way to do slow operations
>> before any "user-I/O" is initiated, the right w
t; hacks to ensure some fairness, but that
can get to to worst-case-seek-time per I/O request land.
[2] Not sure if anybody has looked at this yet, otherwise: Good
project to get your hands wet with disk-I/O and benchmarking.
NB: Beware of clustering.
--
Poul-Henning Kamp | UNIX since Zil
Warner Losh writes:
> The root of this problem, I think, is the following:
> % man 9 bio
> No manual entry for bio
> I think I'll have to massage this email into an appropriate man page.
Please do, and charge the necessary beer to my account :-)
--
26 matches
Mail list logo
