On 2006-01-21, Matthew Dillon <[EMAIL PROTECTED]> wrote:
> A devfs is not going to impact performance. That isn't the problem
> with it. There are three problems with it.
Maybe I missed something, but as I see this thread mentioned performance
only in connection with GEOM, not devfs.
>
Matthew Dillon wrote:
> A devfs is not going to impact performance. That isn't the problem
> with it. There are three problems with it.
[...]
> ...I think all you need is to have base names in a special
> filesystem or filesystem overlay and a VFS layer which parses the name
>
A devfs is not going to impact performance. That isn't the problem
with it. There are three problems with it.
First, the dynamic nature of a devfs means that set permissions
and ownership for devices are not 'sticky' across reboots unless you
add hacks to adjust them on boot.
Csaba Henk wrote:
I have an idea
of a "dynamic dev" solution which would be based on the unique (planned)
feature set of Dfly.
That sounds like a good design. Well explained, too.
On 2006-01-20, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Kris Kennaway wrote:
>
>
>>
>> Well, I asked because I *have* measured and found no measurable
>> performance lost in real-world scenarios. Can you be more specific
>> about the reference you are thinking of?
>
> I have measured also,
Kris Kennaway wrote:
>
> Well, I asked because I *have* measured and found no measurable
> performance lost in real-world scenarios. Can you be more specific
> about the reference you are thinking of?
I have measured also, and i cannot agree with you in general. I have
an Athlon machine, singl
On 2006-01-19, Erik V. Smith <[EMAIL PROTECTED]> wrote:
> If Matt, or anyone else very knowledgeable, would like to lead the way
> with designing a devd, I will implement it. If not, I'll do my best.
To start off, I'm not one of the very knowledgeable, yet I have an idea
of a "dynamic dev" soluti
> One method that would work would be to have a specially tagged directory
> and then have the system parse device names in that directory. So
> instead of having to create 37 /dev/ad0* files we would only have to
> create one "/dev/ad0" and lookups of things like "/dev/ad0s1h" would
> automatical
On 2006-01-19, Andreas Hauser <[EMAIL PROTECTED]> wrote:
> kkenn wrote @ Sun, 15 Jan 2006 04:45:07 -0500:
>
>> Is there even any evidence that it costs performance?
>
> Yes. Look into FreeBSD mailinglist archives and find it doubling the time
> for some tests (afair phk then implemented some direct
:I'm more concerned about the concept than the perfomance. Im against
:the automatic creation and removal of files in /dev. Im sure the
:problems devfs tries to address is solvable in a much cleaner
:solution.
:
:If Im not mistaken there was a similar thread here at these lists a
:year ago where M
I'm more concerned about the concept than the perfomance. Im against
the automatic creation and removal of files in /dev. Im sure the
problems devfs tries to address is solvable in a much cleaner
solution.
If Im not mistaken there was a similar thread here at these lists a
year ago where Matt stat
kkenn wrote @ Sun, 15 Jan 2006 04:45:07 -0500:
> Is there even any evidence that it costs performance?
Yes. Look into FreeBSD mailinglist archives and find it doubling the time
for some tests (afair phk then implemented some direct passthrough that
mends it a bit). Since the whole concept of GEOM
Peter Schuller wrote:
I also agree about /dev. IIRC the website stated (still states?) that
a devfs style solution is not preferred for DragonFly. Does this mean
The site says something else:
From the FAQ:
"""
Will DragonFly use a dynamic /dev filesystem, as in devfs?
Current plans are to
nntp.dragonflybsd.org wrote:
whoops mangled my sender name
--
mph
Simon 'corecode' Schubert wrote:
cool! how about a little talk about the design and then you can knock
yourself out :)
If Matt, or anyone else very knowledgeable, would like to lead the way
with designing a devd, I will implement it. If not, I'll do my best.
Good morning,
just a small additional note to GEOM:
Am Wed, dem 11. Jan 2006, um 9:04 +0100 Uhr schrubte Thomas E. Zander
zum Thema [Re: cowloop technology]:
> Well, it blocks raw device write if the reference count of this device
> is not zero, i.e. you can't change the partition
Peter Schuller wrote:
I also agree about /dev. IIRC the website stated (still states?) that
a devfs style solution is not preferred for DragonFly.
A devd is preferred rather than a devfs. It will arrive eventually,
even if I must code it myself.
> For me GEOM, and devfs are not clear but huge wins of FreeBSD-(5,6)
> over FreeBSD-4. I could not care less if that costs a little
> performance when it works so beautifully. Not only encrypting modules
> but also GEOM raid management modules work perfectly, as far as i have
> seen. They are both
There's no way that it wouldn't cost performance, it would have to
execute some additional code :)
- BC
On 2006-01-11, Michel Talon <[EMAIL PROTECTED]> wrote:
> Thomas E. Zander wrote:
>
>
>>
>> On the other hand, the new GEOM modules like GDBE and GELI are indeed
>> very much appreciated and they work pretty well, so for my personal
>> daily usage, GEOM is a clear win.
>
> For me GEOM, and devfs ar
Thomas E. Zander wrote:
>
> On the other hand, the new GEOM modules like GDBE and GELI are indeed
> very much appreciated and they work pretty well, so for my personal
> daily usage, GEOM is a clear win.
For me GEOM, and devfs are not clear but huge wins of FreeBSD-(5,6)
over FreeBSD-4. I could
Thomas E. Zander wrote:
Well, it blocks raw device write if the reference count of this device
is not zero, i.e. you can't change the partition table of a disk in
multi-user mode if you have mounted filesystems on that disk.
It's a bit uncomfortable sometimes but I wouldn't go as far as to speak
Am Tue, dem 10. Jan 2006, um 22:48 +0100 Uhr schrubte Peter Schuller
zum Thema [Re: cowloop technology]:
> I have seen semi-negative references to GEOM before, but I have been
> unable to find what exactly it is people have a problem with. Out of
> curiousity, is there anything in partic
> We don't have a generic block device layering interface yet. I'd like
> to have something like this before, then supporting cloop for instance
> would be nice as well. I know some people don't like the
> implementation of GEOM, but I think the basic principle is needed
> anyways. Some kind of
Erik V. Smith wrote:
ATmission Linux has a very creative feature that would be a really nice
addition to DragonFly.
Yes, seems nice. Basically a union mount on the block layer. There are
some issues tho:
What do you do if the lower layer gets modified?
- while running
- while not running
Cowloop looks pretty neat - not entirely sure what to use it for though.
- BC
additional RPM's,
* start a database on boot,
* configure a firewall,
* .. anything you can do with a normal Linux system, and
* preserve your changes in a file located on hard disk or a USB
memory stick
these features are based on ATmission's "cowloop&q
27 matches
Mail list logo
