Re: The ext3 way of journalling

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Just to clarify, I had about 60 days of uptime, and hence at least
> 60 days since the last FS check/mount/etc., when Linux crashed those
> few days ago, and wanted to start checking disks with "9192 days since
> last file system check".

This, however sounds like a typical "RTC has forgotten time" problem which
is typical for some motherboards. 9192days is very close to 1984. I never
see any coruption like that, but broken BIOS clocks quite often.

Gruss
Bernd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The ext3 way of journalling

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 Just to clarify, I had about 60 days of uptime, and hence at least
 60 days since the last FS check/mount/etc., when Linux crashed those
 few days ago, and wanted to start checking disks with 9192 days since
 last file system check.

This, however sounds like a typical RTC has forgotten time problem which
is typical for some motherboards. 9192days is very close to 1984. I never
see any coruption like that, but broken BIOS clocks quite often.

Gruss
Bernd

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory management in embedded systems

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Make kernel configuration option? (e.g. disable "over commit"
> mis-feature :-)

# egrep . /proc/sys/vm/overcommit_*
/proc/sys/vm/overcommit_memory:0
/proc/sys/vm/overcommit_ratio:50

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory management in embedded systems

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 Make kernel configuration option? (e.g. disable over commit
 mis-feature :-)

# egrep . /proc/sys/vm/overcommit_*
/proc/sys/vm/overcommit_memory:0
/proc/sys/vm/overcommit_ratio:50

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: memset as memzero

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> it doesn't add value memset with a constant 0 is just as fast
> (since the compiler knows it's 0) than any wrapper around it, and the
> syntax around it is otherwise the same.

it would however allow easier changing if you need to add a page cleaning
system (for example new architecture which has support for it). On the other
hand, is memset used for anything else than zero filling or redzone
"filling"?

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: A revised timerfd API

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>  1. This design stretches the POSIX timers API in strange
> ways.

Maybe it is possible to reimplement the POSIX API in usermode using the
kernel's FD implementation? (and drop the posix support from kernel)

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: A revised timerfd API

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
  1. This design stretches the POSIX timers API in strange
 ways.

Maybe it is possible to reimplement the POSIX API in usermode using the
kernel's FD implementation? (and drop the posix support from kernel)

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: memset as memzero

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 it doesn't add value memset with a constant 0 is just as fast
 (since the compiler knows it's 0) than any wrapper around it, and the
 syntax around it is otherwise the same.

it would however allow easier changing if you need to add a page cleaning
system (for example new architecture which has support for it). On the other
hand, is memset used for anything else than zero filling or redzone
filling?

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: unfamiliar notation

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> What's the deal with the underscore and the parentheses surrounding the
> call to menu_get_help?

it is a macro from gettext, used to translate the string. Usually this
should only be used on string constants.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: unfamiliar notation

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 What's the deal with the underscore and the parentheses surrounding the
 call to menu_get_help?

it is a macro from gettext, used to translate the string. Usually this
should only be used on string constants.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NFS4 authentification / fsuid

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> So you can't draw any relationships between "Protect the end-user"  
> with "Protect the device FROM the end-user", the former can be done  
> very reliably to whatever level of risk-reduction you need and the  
> latter can't practically be done at all.

Unless you use a TPM Chip.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NFS4 authentification / fsuid

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 So you can't draw any relationships between Protect the end-user  
 with Protect the device FROM the end-user, the former can be done  
 very reliably to whatever level of risk-reduction you need and the  
 latter can't practically be done at all.

Unless you use a TPM Chip.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: do_coredump and O_NOFOLLOW

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I found that O_NOFOLLOW is used for opened core file in Linux 2.6.10. 

I think that is for security reasons, otherwise one has to (atomically)
check who is the owner of the symlink and where it points to. If you dont
have hostile users on your system you might be able to remove it, but it is
not a good idea in the general public.

Maybe we need a coreadm tool like Solaris has, where you can put the
corefiles where you want. That would change the corepattern to include a
path and be specific to a process (tree).

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: do_coredump and O_NOFOLLOW

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 I found that O_NOFOLLOW is used for opened core file in Linux 2.6.10. 

I think that is for security reasons, otherwise one has to (atomically)
check who is the owner of the symlink and where it points to. If you dont
have hostile users on your system you might be able to remove it, but it is
not a good idea in the general public.

Maybe we need a coreadm tool like Solaris has, where you can put the
corefiles where you want. That would change the corepattern to include a
path and be specific to a process (tree).

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ext2 on flash memory

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> All of the posts fail to address the question here: what is the
> correct file system, or does one exist yet, for wear leveling flash
> storage.  JFFS2 and logfs are nice for MTD, but for better flash
> memories that are likely to be used in the future like solid state
> hard disks, what is the answer?

FAT - you can stick it into Windows Boxes on the road.

Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ext2 on flash memory

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 All of the posts fail to address the question here: what is the
 correct file system, or does one exist yet, for wear leveling flash
 storage.  JFFS2 and logfs are nice for MTD, but for better flash
 memories that are likely to be used in the future like solid state
 hard disks, what is the answer?

FAT - you can stick it into Windows Boxes on the road.

Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: slow open() calls and o_nonblock

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> In short, I'm distributing logs in realtime for about 600,000
> websites.  The sources of the logs (http, ftp, realmedia, etc) are
> flexible, however the base framework was build around a large cluster
> of webservers.  The output can be to several hundred thousand files
> across about two dozen filers for user consumption - some can be very
> active, some can be completely inactive.

Asuming you have multiple request log summary files, I would just run
multiple "splitters".

> You can certainly open the file, but not block on the call to do it.
> What confuses me is why the kernel would "block" for 415ms on an open
> call.  Thats an eternity to suspend a process that has to distribute
> data such as this.

Because it has to, to return the result with the given API. 

But If you would have a async interface, the operation would still take that
long and your throughput will still be limited by the opens/sec your filers
support, or?

> Except I cant very well keep 600,000 files open over NFS.  :)  Pool
> and queue, and cycle through the pool.  I've managed to achieve a
> balance in my production deployment with this method - my email was
> more of a rant after months of trying to work around a problem (caused
> by a limitation in system calls),

I agree that a unified async layer is nice from the programmers POV, but I
disagree that it would help your performance problem which is caused by NFS
and/or NetApp (and I wont blame them).

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: slow open() calls and o_nonblock

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> (ps.  having come from the socket side of the fence, its incredibly
> frustrating to be unable to poll() or epoll regular file FDs --
> Especially knowing that the kernel is translating them into a TCP
> socket to do NFS anyway.  Please add regular files to epoll and give
> me a way to do the opens in the same fasion as connects!)

You might want to use Windows? :) 

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: slow open() calls and o_nonblock

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 (ps.  having come from the socket side of the fence, its incredibly
 frustrating to be unable to poll() or epoll regular file FDs --
 Especially knowing that the kernel is translating them into a TCP
 socket to do NFS anyway.  Please add regular files to epoll and give
 me a way to do the opens in the same fasion as connects!)

You might want to use Windows? :) 

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: slow open() calls and o_nonblock

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 In short, I'm distributing logs in realtime for about 600,000
 websites.  The sources of the logs (http, ftp, realmedia, etc) are
 flexible, however the base framework was build around a large cluster
 of webservers.  The output can be to several hundred thousand files
 across about two dozen filers for user consumption - some can be very
 active, some can be completely inactive.

Asuming you have multiple request log summary files, I would just run
multiple splitters.

 You can certainly open the file, but not block on the call to do it.
 What confuses me is why the kernel would block for 415ms on an open
 call.  Thats an eternity to suspend a process that has to distribute
 data such as this.

Because it has to, to return the result with the given API. 

But If you would have a async interface, the operation would still take that
long and your throughput will still be limited by the opens/sec your filers
support, or?

 Except I cant very well keep 600,000 files open over NFS.  :)  Pool
 and queue, and cycle through the pool.  I've managed to achieve a
 balance in my production deployment with this method - my email was
 more of a rant after months of trying to work around a problem (caused
 by a limitation in system calls),

I agree that a unified async layer is nice from the programmers POV, but I
disagree that it would help your performance problem which is caused by NFS
and/or NetApp (and I wont blame them).

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH - 1/1] Documentation/HOWTO

[Bernd Eckenfels]

On Fri, May 25, 2007 at 11:24:46AM -0500, Scott Preece wrote:
> However, it might be phrased more diplomatically in this context, like
> "because you are sacrificing time that could be spent adding features,
> to fix somebody else's mistakes".

Not all Bugs are mistakes of the coder. I still think it is not correct to
blame developers. And it is also not a good idea to treat helping hands as
second class only because they improve instead of create things.

Linux Kernel is developed in a collaborative evolutionary process. The
documentation change is completely wrong worded.

(However the idea to ask ppl to look for small clear tasks, especially if
not everybody has the option to work on it (hardware) is good) - and very
rewarding.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH - 1/1] Documentation/HOWTO

[Bernd Eckenfels]

On Fri, May 25, 2007 at 11:24:46AM -0500, Scott Preece wrote:
 However, it might be phrased more diplomatically in this context, like
 because you are sacrificing time that could be spent adding features,
 to fix somebody else's mistakes.

Not all Bugs are mistakes of the coder. I still think it is not correct to
blame developers. And it is also not a good idea to treat helping hands as
second class only because they improve instead of create things.

Linux Kernel is developed in a collaborative evolutionary process. The
documentation change is completely wrong worded.

(However the idea to ask ppl to look for small clear tasks, especially if
not everybody has the option to work on it (hardware) is good) - and very
rewarding.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: VFS design question

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I tried to make it clear that I am clearly lacking expertise in this
> topic. I am currently working on a somewhat related topic and was hoping
> to get some reactions that would point me in the right directions as it
> is somewhat hard to judge the VFS design when you do not have prior
> experience in writing a file system on your own. Nowhere did I ask for a
> 10 paged review on the matter.

VFS abstraction is not too limiting, because the interface to user space is
fixed by posix or other standards in the libc. So als long as the new
filesystem want to support that semantic, it is not really limited.

There are some cases which are a bit hard, for example inode numbers -
especially when you want to provice NFS support, but that is not
specifically a VFS Problem.

And: VFS has evolved over time, that is the advantage of open source, you
can just include new functions in the old filesystems when you think you
need to impriove the framework.

That said, if you look at Reiser4 for example, there are some plug-in
extensions which are not yet possible in VFS, since it is a more high level
interface...

There are some different file close/lock semantics out there, and VFS does
not even try to abstract them.

gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: it seems at XFS bug?!

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> 500   8   6   1   2   5   4   9   -   r   w   -   r   -   -   r
>3638 3231 3435 2039 722d 2d77 2d72 722d
> 520   -   -   1   r   o   o   t   r   o   o   t
>2d2d 3120 7220 6f6f 2074 6f72 746f 2020
> 540   0   2   0   0   7   -   0   5   -   0   6
>2020 2020 2030 3032 3730 302d 2d35 3630
> 560   1   2   :   4   1  \n  \0
>3120 3a32 3134 a020 000a
> 571

That file with the inode 8612549 has indeed an empty name. (And I wonder a
bit about the trailing \0, my ls does not do that?)

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: it seems at XFS bug?!

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> -rw-r--r-- 1 root root  0 2007-05-06 12:41
> 
> the last line is very interesting, this file has no name and the size is 0 
> byte.

Well, 0 byte files are nothing special, and the name: it might be a 
non-printable char?

> touch ' '

will produce a similiar file. Try "ls -li | od -cx"

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ht CPU flag

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> From now I'll use Intel recomendation to run their utility to resolve all 
> questions.

You mean this, right?
 
http://www.intel.com/support/processors/sb/cs-001632.htm

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ht CPU flag

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> To authors of /proc/cpuinfo:
> 
> Plz, fix stepping identification:

It might be a bug in the kernel code, however it is pretty unlikely: It just
reads what the CPU reports. You have an odd chip, nothing what the kernel
can do about. I see "family 15, model 2, stepping 4" usually beeing a P4
2.4GHz CPU. Maybe thats one of those relabling cases.

The information you list is a dual-cpu with HT configuration.

You could give us the output of any of your windows tools, but I am quite
sure they will report the same thing.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ht CPU flag

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 To authors of /proc/cpuinfo:
 
 Plz, fix stepping identification:

It might be a bug in the kernel code, however it is pretty unlikely: It just
reads what the CPU reports. You have an odd chip, nothing what the kernel
can do about. I see family 15, model 2, stepping 4 usually beeing a P4
2.4GHz CPU. Maybe thats one of those relabling cases.

The information you list is a dual-cpu with HT configuration.

You could give us the output of any of your windows tools, but I am quite
sure they will report the same thing.

Greetings
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ht CPU flag

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 From now I'll use Intel recomendation to run their utility to resolve all 
 questions.

You mean this, right?
 
http://www.intel.com/support/processors/sb/cs-001632.htm

Greetings
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: it seems at XFS bug?!

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 -rw-r--r-- 1 root root  0 2007-05-06 12:41
 
 the last line is very interesting, this file has no name and the size is 0 
 byte.

Well, 0 byte files are nothing special, and the name: it might be a 
non-printable char?

 touch ' '

will produce a similiar file. Try ls -li | od -cx

Greetings
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: it seems at XFS bug?!

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 500   8   6   1   2   5   4   9   -   r   w   -   r   -   -   r
3638 3231 3435 2039 722d 2d77 2d72 722d
 520   -   -   1   r   o   o   t   r   o   o   t
2d2d 3120 7220 6f6f 2074 6f72 746f 2020
 540   0   2   0   0   7   -   0   5   -   0   6
2020 2020 2030 3032 3730 302d 2d35 3630
 560   1   2   :   4   1  \n  \0
3120 3a32 3134 a020 000a
 571

That file with the inode 8612549 has indeed an empty name. (And I wonder a
bit about the trailing \0, my ls does not do that?)

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: VFS design question

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 I tried to make it clear that I am clearly lacking expertise in this
 topic. I am currently working on a somewhat related topic and was hoping
 to get some reactions that would point me in the right directions as it
 is somewhat hard to judge the VFS design when you do not have prior
 experience in writing a file system on your own. Nowhere did I ask for a
 10 paged review on the matter.

VFS abstraction is not too limiting, because the interface to user space is
fixed by posix or other standards in the libc. So als long as the new
filesystem want to support that semantic, it is not really limited.

There are some cases which are a bit hard, for example inode numbers -
especially when you want to provice NFS support, but that is not
specifically a VFS Problem.

And: VFS has evolved over time, that is the advantage of open source, you
can just include new functions in the old filesystems when you think you
need to impriove the framework.

That said, if you look at Reiser4 for example, there are some plug-in
extensions which are not yet possible in VFS, since it is a more high level
interface...

There are some different file close/lock semantics out there, and VFS does
not even try to abstract them.

gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fork Bombing Attack

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>   I found one more interesting thing related with fork
> bombing attack. i have set following in /etc/security/limits.conf file
> 
> [EMAIL PROTECTED]hard  nproc  3000
> [EMAIL PROTECTED] hard  nproc  500

The # is a comment character. So those lines are not used.

BTW: the @ means group, you really want that? BTW2: you need to log out/in
and the session leader must actually be PAM regulated (i.e. not for daemons)

So it is good to check "ulimit -n" in the shell where you want to try the
forbomb. If it is below 100 you should be safe.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ht CPU flag

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Am I right that is chipset on mainboard, who is saying - "I know", not 
> CPU itself?

It is a feature bitfield read directly from the CPU.

> Is it better to switch off HT support in BIOS?

The CPU will still report that flag. Might speed up the boot, not sure.

> Is it possible to generate CPU name as: "Pentium D 930" in /proc/cpuinfo?

No, cause those are marketing names, not reported by the CPU. You can only
lookup family, model and stepping with the vendors data sheets to get a
first impression of the possible chip.

Some chip cores get reconfigured by the vendor depending on QA (if it is not
able to cleanly process at high speed it gets sold as a slower chip).

> On the other server I have some 2GHz HT Xeons which can't be identified on 
> Intel site because of strange naming pattern.

Google for model and stepping.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ht CPU flag

[Bernd Eckenfels]

On Fri, May 18, 2007 at 12:07:09PM -0700, Siddha, Suresh B wrote:
> On Fri, May 18, 2007 at 11:45:59AM -0700, H. Peter Anvin wrote:
> > IIRC, the HT flag is also reported for multicore CPUs.
> 
> Yes. Thats correct.

And for some Single-Core Non-HT CPUs.

Gruss
Bernd
-- 
  (OO) -- [EMAIL PROTECTED] --
 ( .. )[EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o   1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+49721151516129
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ht CPU flag

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I have Pentium D CPU, which many Windows utilities like cpuz, wcpuid, 
> everest identify as D 930 (Dual Core, 3GHz). From Intel site I find out 
> that it has no HT feature, nor Windows XP identify it as HT.

the ht flag reported by the CPU and cpuinfo is not a reliable detection if
HT is available on your CPU or your motherboard/bios.

> Why do I have "ht" flag in cpuinfo?

Because your CPU reports it. You will see that also in cpuz output.

However, you can see ht in the sibblings value (for a single core it will be
2 if you have HT, I am not sure if it is 4 for a dual core CPU)

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH - 1/1] Documentation/HOWTO

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>> bugs is one of the best ways to get merits among other developers, because
>> not many people like wasting time fixing other people's bugs.
>   ^^^ 
> 
> you might want to find a less demeaning term for debugging than
> "wasting time."  just a thought.

and it is not even correct.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] log out-of-virtual-memory events

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> +   printk(KERN_INFO
> +  "out of virtual memory for process %d (%s): total_vm=%lu, 
> uid=%d\n",
> +   current->pid, current->comm, total_vm, current->uid);

And align this one with the print_fatal layout:

   printk(KERN_WARNING
  "%s/%d process cannot request more virtual memory: total_vm=%lu, 
uid=%d\n",
   current->comm, current->pid, total_vm, current->uid);

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] log out-of-virtual-memory events

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>printk("%s/%d: potentially unexpected fatal signal %d.\n",
>current->comm, current->pid, signr);

can we have both KERN_WARNING please?

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] log out-of-virtual-memory events

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 +   printk(KERN_INFO
 +  out of virtual memory for process %d (%s): total_vm=%lu, 
 uid=%d\n,
 +   current-pid, current-comm, total_vm, current-uid);

And align this one with the print_fatal layout:

   printk(KERN_WARNING
  %s/%d process cannot request more virtual memory: total_vm=%lu, 
uid=%d\n,
   current-comm, current-pid, total_vm, current-uid);

Greetings
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] log out-of-virtual-memory events

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
printk(%s/%d: potentially unexpected fatal signal %d.\n,
current-comm, current-pid, signr);

can we have both KERN_WARNING please?

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH - 1/1] Documentation/HOWTO

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 bugs is one of the best ways to get merits among other developers, because
 not many people like wasting time fixing other people's bugs.
   ^^^ 
 
 you might want to find a less demeaning term for debugging than
 wasting time.  just a thought.

and it is not even correct.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ht CPU flag

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 I have Pentium D CPU, which many Windows utilities like cpuz, wcpuid, 
 everest identify as D 930 (Dual Core, 3GHz). From Intel site I find out 
 that it has no HT feature, nor Windows XP identify it as HT.

the ht flag reported by the CPU and cpuinfo is not a reliable detection if
HT is available on your CPU or your motherboard/bios.

 Why do I have ht flag in cpuinfo?

Because your CPU reports it. You will see that also in cpuz output.

However, you can see ht in the sibblings value (for a single core it will be
2 if you have HT, I am not sure if it is 4 for a dual core CPU)

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ht CPU flag

[Bernd Eckenfels]

On Fri, May 18, 2007 at 12:07:09PM -0700, Siddha, Suresh B wrote:
 On Fri, May 18, 2007 at 11:45:59AM -0700, H. Peter Anvin wrote:
  IIRC, the HT flag is also reported for multicore CPUs.
 
 Yes. Thats correct.

And for some Single-Core Non-HT CPUs.

Gruss
Bernd
-- 
  (OO) -- [EMAIL PROTECTED] --
 ( .. )[EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o   1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+49721151516129
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ht CPU flag

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 Am I right that is chipset on mainboard, who is saying - I know, not 
 CPU itself?

It is a feature bitfield read directly from the CPU.

 Is it better to switch off HT support in BIOS?

The CPU will still report that flag. Might speed up the boot, not sure.

 Is it possible to generate CPU name as: Pentium D 930 in /proc/cpuinfo?

No, cause those are marketing names, not reported by the CPU. You can only
lookup family, model and stepping with the vendors data sheets to get a
first impression of the possible chip.

Some chip cores get reconfigured by the vendor depending on QA (if it is not
able to cleanly process at high speed it gets sold as a slower chip).

 On the other server I have some 2GHz HT Xeons which can't be identified on 
 Intel site because of strange naming pattern.

Google for model and stepping.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fork Bombing Attack

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
   I found one more interesting thing related with fork
 bombing attack. i have set following in /etc/security/limits.conf file
 
 [EMAIL PROTECTED]hard  nproc  3000
 [EMAIL PROTECTED] hard  nproc  500

The # is a comment character. So those lines are not used.

BTW: the @ means group, you really want that? BTW2: you need to log out/in
and the session leader must actually be PAM regulated (i.e. not for daemons)

So it is good to check ulimit -n in the shell where you want to try the
forbomb. If it is below 100 you should be safe.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: undeprecate raw driver.

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> in short, do *not* remove its "deprecated" status.  rather, remove its
> "obsolete" status and *make* it deprecated.

it is deprecated and obsolete.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: undeprecate raw driver.

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 in short, do *not* remove its deprecated status.  rather, remove its
 obsolete status and *make* it deprecated.

it is deprecated and obsolete.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] ip_local_port_range sysctl has annoying default

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> However, there are a large number of applications which have registered
> ports in this range.

And some application who request random listening ports actually query the
/etc/services file to ensure it is a "unnamed" port.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] "volatile considered harmful", take 2

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> +Consider a typical block of kernel code:
> +
> +spin_lock(_lock);
> +do_something_on(_data);
> +do_something_else_with(_data);
> +spin_unlock(_lock);
> +
> +If all the code follows the locking rules, the value of shared_data cannot
> +change unexpectedly while the_lock is held.

Well maybe it is trivial, but I would add e.g. "all places where the
shared_data is accessed must be protected by this spinlock"

> +  - The jiffies variable is special in that it can have a different value

what about other atomic readable counters (like interface counters)?

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] volatile considered harmful, take 2

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 +Consider a typical block of kernel code:
 +
 +spin_lock(the_lock);
 +do_something_on(shared_data);
 +do_something_else_with(shared_data);
 +spin_unlock(the_lock);
 +
 +If all the code follows the locking rules, the value of shared_data cannot
 +change unexpectedly while the_lock is held.

Well maybe it is trivial, but I would add e.g. all places where the
shared_data is accessed must be protected by this spinlock

 +  - The jiffies variable is special in that it can have a different value

what about other atomic readable counters (like interface counters)?

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] ip_local_port_range sysctl has annoying default

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 However, there are a large number of applications which have registered
 ports in this range.

And some application who request random listening ports actually query the
/etc/services file to ensure it is a unnamed port.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Ext3 vs NTFS performance

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> For this particular case, Ted is probably right and the only place
> we'll ever see this insane poor man's pre-allocate pattern is from the
> Windows CIFS client, in which case fixing this in Samba makes sense -
> although I'm a bit horrified by the idea of writing 128K of zeroes to
> pre-allocate... oh well, it's temporary, and what we care about here
> is the read performance, more than the write performance.

What about an ioctl or advice to avoid holes? Which could be issued by
samba? Is that related to SetFileValidData and SetEndOfFile win32 functions?
What is the windows client calling, and what command is transmitted by smb?

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Ext3 vs NTFS performance

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 For this particular case, Ted is probably right and the only place
 we'll ever see this insane poor man's pre-allocate pattern is from the
 Windows CIFS client, in which case fixing this in Samba makes sense -
 although I'm a bit horrified by the idea of writing 128K of zeroes to
 pre-allocate... oh well, it's temporary, and what we care about here
 is the read performance, more than the write performance.

What about an ioctl or advice to avoid holes? Which could be issued by
samba? Is that related to SetFileValidData and SetEndOfFile win32 functions?
What is the windows client calling, and what command is transmitted by smb?

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> You can't have it even do a search to see if it already has something similar 
> without creating an account and logging in.  Since I'm out of wall space, and 
> the missus is bugging me to paint over all that, I left.

Well, thats not a bugzilla problem. upstream bugzilla allows anonymous
search.

Infact bugme.osdl.org allows search right on the frontpage. And if you want
to dig deeper, use the query function.

This is the quicksearch on "USB":



> I repeat:  Usefull?  For what?

Try again.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> If it is considered useful it shouldn't be a problem to automatically 
> forward all incoming Bugzilla bugs to linux-kernel.

Yes, most of it to linux-kernel, some components (netdev@, architecture) to
a more specific list.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 You can't have it even do a search to see if it already has something similar 
 without creating an account and logging in.  Since I'm out of wall space, and 
 the missus is bugging me to paint over all that, I left.

Well, thats not a bugzilla problem. upstream bugzilla allows anonymous
search.

Infact bugme.osdl.org allows search right on the frontpage. And if you want
to dig deeper, use the query function.

This is the quicksearch on USB:

http://bugme.osdl.org/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=OPENbug_status=ASSIGNEDbug_status=REOPENEDfield0-0-0=producttype0-0-0=substringvalue0-0-0=usbfield0-0-1=componenttype0-0-1=substringvalue0-0-1=usbfield0-0-2=short_desctype0-0-2=substringvalue0-0-2=usbfield0-0-3=status_whiteboardtype0-0-3=substringvalue0-0-3=usb

 I repeat:  Usefull?  For what?

Try again.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 If it is considered useful it shouldn't be a problem to automatically 
 forward all incoming Bugzilla bugs to linux-kernel.

Yes, most of it to linux-kernel, some components (netdev@, architecture) to
a more specific list.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REPORT] cfs-v4 vs sd-0.44

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>  a) it may do so for a short and bound time, typically less than the
> maximum acceptable latency for other tasks

if you have n threads in runq and each of them can have mhttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REPORT] cfs-v4 vs sd-0.44

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
  a) it may do so for a short and bound time, typically less than the
 maximum acceptable latency for other tasks

if you have n threads in runq and each of them can have md (d=max latency
deadline) overhead, you will have to account on d/n slices. This is
typically not possible for larger number of ready threads.

Therefore another aproach would be to make sure the next thread gets a
smaller slice, but then you will have to move around that debit and
distribute it fair, which is the whole problem we face here.

(Besides it is not clear to me if fair scheduling gets the best results, see
the X problem or compare threads vs. process vs. subsystems).

Gruss
Bernd

PS: sorry for that Cc trimming, I need to get rid of my mail2news gateway,
however I will make sure to copy important info to all concerend parties -
dont think thats needed for my ramblings .)


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REPORT] cfs-v4 vs sd-0.44

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Could you explain for the audience the technical definition of fairness
> and what sorts of error metrics are commonly used? There seems to be
> some disagreement, and you're neutral enough of an observer that your
> statement would help.

And while we are at it, why it is a good thing. I could understand that fair
means no missbehaving (intentionally or unintentionally) application can
harm the rest of the system. However a responsive desktop might not
necesarily be very fair to compute jobs.

Even a simple thing as "who gets accounted" can be quite different in
different workloads. (larger multi user systems tend to be fair based on the
user, on servers you more balance by thread or job and single user systems
should be as unfair as the user wants them as long as no process can "run
away")

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REPORT] cfs-v4 vs sd-0.44

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 Could you explain for the audience the technical definition of fairness
 and what sorts of error metrics are commonly used? There seems to be
 some disagreement, and you're neutral enough of an observer that your
 statement would help.

And while we are at it, why it is a good thing. I could understand that fair
means no missbehaving (intentionally or unintentionally) application can
harm the rest of the system. However a responsive desktop might not
necesarily be very fair to compute jobs.

Even a simple thing as who gets accounted can be quite different in
different workloads. (larger multi user systems tend to be fair based on the
user, on servers you more balance by thread or job and single user systems
should be as unfair as the user wants them as long as no process can run
away)

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor FAQ

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Perhaps -- until your httpd is compromised via a buffer overflow or 
> simply misbehaves due to a software or configuration flaw, then the 
> assumptions being made about its use of pathnames and their security 
> properties are out the window.

Hu? Even a compromised httpd (especially a compromised httpd) is bound to
the app armor policies. This means it cannot (for example) write to
/var/www/* - if it never needed to at normal/profiling time.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Top (VCPU maybe?)
>User
>Process
>Thread

The problem with that is, that not all Schedulers might work on the User
level. You can think of Batch/Job, Parent, Group, Session or namespace
level. That would be IMHO a generic Top, with no need for a level above.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 Top (VCPU maybe?)
User
Process
Thread

The problem with that is, that not all Schedulers might work on the User
level. You can think of Batch/Job, Parent, Group, Session or namespace
level. That would be IMHO a generic Top, with no need for a level above.

Greetings
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor FAQ

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 Perhaps -- until your httpd is compromised via a buffer overflow or 
 simply misbehaves due to a software or configuration flaw, then the 
 assumptions being made about its use of pathnames and their security 
 properties are out the window.

Hu? Even a compromised httpd (especially a compromised httpd) is bound to
the app armor policies. This means it cannot (for example) write to
/var/www/* - if it never needed to at normal/profiling time.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ZFS with Linux: An Open Plea

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>> Unfortunatelle Latency is critical for a number of critical applications
>> like databases or file based transaction systems (mail, news) - mainly the
>> users of fsync().
> 
> Whether you mix audio in userspace or kernel does not impact latency -
> you still need to schedule the application playing audio every N
> milliseconds or there will be dropouts.  I don't see where audio
> mixing issue has any relevance to this thread.

Well, I was not talking about Audio - I was saying that there are a class of
applications which need low latency on commits (fsync or rename).

And for the audio mixer, the problem is that you have multiple reschedules
and data ping pong if you do user mode mixing - i guess.

Anyway.. not important. I still think filesystem servers can be a good
thing. And I really hope we will find some interesting numbers on ZFS
advantages...

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ZFS with Linux: An Open Plea

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I meant that the central requirement on the design and implementation of
> audio subsystems is an (ideally guaranteed) bounded maximum of
> latencies; and that's exactly the major point where I heard that there
> are problems with ALSA driver components in userspace.  You were talking
> about throughput of storage systems, for which latencies of the software
> part of the stack do not play such a central role.  Therefore your
> comparison appeared off the mark to me.

Unfortunatelle Latency is critical for a number of critical applications
like databases or file based transaction systems (mail, news) - mainly the
users of fsync().

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ZFS with Linux: An Open Plea

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 I meant that the central requirement on the design and implementation of
 audio subsystems is an (ideally guaranteed) bounded maximum of
 latencies; and that's exactly the major point where I heard that there
 are problems with ALSA driver components in userspace.  You were talking
 about throughput of storage systems, for which latencies of the software
 part of the stack do not play such a central role.  Therefore your
 comparison appeared off the mark to me.

Unfortunatelle Latency is critical for a number of critical applications
like databases or file based transaction systems (mail, news) - mainly the
users of fsync().

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ZFS with Linux: An Open Plea

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 Unfortunatelle Latency is critical for a number of critical applications
 like databases or file based transaction systems (mail, news) - mainly the
 users of fsync().
 
 Whether you mix audio in userspace or kernel does not impact latency -
 you still need to schedule the application playing audio every N
 milliseconds or there will be dropouts.  I don't see where audio
 mixing issue has any relevance to this thread.

Well, I was not talking about Audio - I was saying that there are a class of
applications which need low latency on commits (fsync or rename).

And for the audio mixer, the problem is that you have multiple reschedules
and data ping pong if you do user mode mixing - i guess.

Anyway.. not important. I still think filesystem servers can be a good
thing. And I really hope we will find some interesting numbers on ZFS
advantages...

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> A development process like this is likely to exclude smart people from wanting
> to contribute to Linux and folks should be conscious about this issues.

Nobody is excluded, you can always have a next iteration.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 A development process like this is likely to exclude smart people from wanting
 to contribute to Linux and folks should be conscious about this issues.

Nobody is excluded, you can always have a next iteration.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: If not readdir() then what?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Otherwise, the client would have to cache _all_ previous READDIR results
> since the last opendir()/rewinddir() in order to be able to do its own
> loop detection and that will obviously never scale for large directories
> or for directories that change frequently...

Unless you have a COW style filesystem with versioning (think oracle tables)
you will have to invalidate cookies often or do copies - on client or
server. And I am not sure whats worse (for apps)... disappearing/missing
files or duplicates.

Gruss
bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: If not readdir() then what?

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 Otherwise, the client would have to cache _all_ previous READDIR results
 since the last opendir()/rewinddir() in order to be able to do its own
 loop detection and that will obviously never scale for large directories
 or for directories that change frequently...

Unless you have a COW style filesystem with versioning (think oracle tables)
you will have to invalidate cookies often or do copies - on client or
server. And I am not sure whats worse (for apps)... disappearing/missing
files or duplicates.

Gruss
bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

yes --help (was: [PATCH] Sanitize filesystem NLS handling)

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> 2) Output of "yes --help" from the same terminal

Question: what do you expect?

#> yes --version
#yes (GNU coreutils) 5.2.1
#Written by David MacKenzie.
#
#Copyright (C) 2004 Free Software Foundation, Inc.
#This is free software; see the source for copying conditions.  There is NO
#warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

yes --help (was: [PATCH] Sanitize filesystem NLS handling)

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 2) Output of yes --help from the same terminal

Question: what do you expect?

# yes --version
#yes (GNU coreutils) 5.2.1
#Written by David MacKenzie.
#
#Copyright (C) 2004 Free Software Foundation, Inc.
#This is free software; see the source for copying conditions.  There is NO
#warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Greetings
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange ethN numbering problem.

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> However, when the system comes up and attempt to do an ifconfig, the 
> 'ethN' numbers
> have changed to a some what intermengled seriese starting with eth6... 
> eth10.

maybe a system startup script is renaming them (in order to give them well
known numbers)? 

What kind of distribution is that? is this a new problem? Have a look in
/etc/mactab.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange ethN numbering problem.

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 However, when the system comes up and attempt to do an ifconfig, the 
 'ethN' numbers
 have changed to a some what intermengled seriese starting with eth6... 
 eth10.

maybe a system startup script is renaming them (in order to give them well
known numbers)? 

What kind of distribution is that? is this a new problem? Have a look in
/etc/mactab.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to detect multi-core and/or HT-enabled CPUs in 2.4.x and 2.6.x kernels

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> once your program (and many others) have such a check, then the next
> step will be pressure on the kernel code to "fake" the old situation
> when there is a processor where  no longer
> holds. It's basically a road to madness :-(

I agree that for HPC sizing a benchmark with various levels of parallelity
are better. The question is, if the code in question only is for inventory
reasons. In that case I would do something like x sockets, y cores and z cm
threads.

Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to detect multi-core and/or HT-enabled CPUs in 2.4.x and 2.6.x kernels

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 once your program (and many others) have such a check, then the next
 step will be pressure on the kernel code to fake the old situation
 when there is a processor where vague criteria of the day no longer
 holds. It's basically a road to madness :-(

I agree that for HPC sizing a benchmark with various levels of parallelity
are better. The question is, if the code in question only is for inventory
reasons. In that case I would do something like x sockets, y cores and z cm
threads.

Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Processes with hidden PID files in /proc

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I've Googled on this enough to find out that these are Linux threads,
> that "ps -m" will show them, that "ls -a /proc" will show /proc/.PPID,
> etc, but I'm still wondering what exact sequence of system calls will
> create a process like this?

clone(2) can be used to create a thread in a new thread group. If that
thread forks, the resulting child has the (invisible) thread group as parent
pid.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: server don't accept ip-connections from linux

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> i check the packets with an analyser and make some test. if i disable ecn 
> with "echo 0x0 > /proc/sys/net/ipv4/tcp_ecn" it works, with ecn enabled, it 
> don't work.

this is a problem on the remote site (old firewall software), nothing we
(linux kernel) can do about it. You might want to inform the owner of the
server about that.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: server don't accept ip-connections from linux

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 i check the packets with an analyser and make some test. if i disable ecn 
 with echo 0x0  /proc/sys/net/ipv4/tcp_ecn it works, with ecn enabled, it 
 don't work.

this is a problem on the remote site (old firewall software), nothing we
(linux kernel) can do about it. You might want to inform the owner of the
server about that.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Processes with hidden PID files in /proc

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 I've Googled on this enough to find out that these are Linux threads,
 that ps -m will show them, that ls -a /proc will show /proc/.PPID,
 etc, but I'm still wondering what exact sequence of system calls will
 create a process like this?

clone(2) can be used to create a thread in a new thread group. If that
thread forks, the resulting child has the (invisible) thread group as parent
pid.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SCSI init discussion/SAN problem (not interesting)

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Was this post just not interesting enough, or is it the lack of access to 
> hardware
> to test this on that prevented it from being picked up by someone?

see google, for example: http://christophe.varoqui.free.fr/multipath.html

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SCSI init discussion/SAN problem (not interesting)

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 Was this post just not interesting enough, or is it the lack of access to 
 hardware
 to test this on that prevented it from being picked up by someone?

see google, for example: http://christophe.varoqui.free.fr/multipath.html

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GFS, what's remaining

[Bernd Eckenfels]

On Mon, Sep 05, 2005 at 04:16:31PM +0200, Lars Marowsky-Bree wrote:
> That is the whole point why OCFS exists ;-)

The whole point of the orcacle cluster filesystem as it was described in old
papers was about pfiles, control files and software, because you can easyly
use direct block access (with ASM) for tablespaces.

> No. Beyond the table spaces, there's also ORACLE_HOME; a cluster
> benefits in several aspects from a general-purpose SAN-backed CFS.

Yes, I dont dispute the usefullness of OCFS for ORA_HOME (beside I think a
replicated filesystem makes more sense), I am just nor sure if anybody sane
would use it for tablespaces.

I guess I have to correct the artile in my german it blog :) (if somebody
can name productive customers).

Gruss
Bernd
-- 
http://itblog.eckenfels.net/archives/54-Cluster-Filesysteme.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

On Sun, Sep 04, 2005 at 09:45:31AM +0100, Alan Cox wrote:
> Non GPL modules are required not to be derivative works (a term of law).
> The EXPORT_SYMBOL information is merely advisory to help seperate
> symbols. In many cases its purely historical as to whether a symbol is
> marked _GPL or not.

Yes, I agree, I was just not talking about licensing/legal issues, but only
about the visible technical reasons and restrictions.

So I dont think I am confused... thanks for follow up, Alan.

Gruss
Bernd
-- 
  (OO) -- [EMAIL PROTECTED] --
 ( .. )[EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o   1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+49721151516129
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

On Sun, Sep 04, 2005 at 09:45:31AM +0100, Alan Cox wrote:
 Non GPL modules are required not to be derivative works (a term of law).
 The EXPORT_SYMBOL information is merely advisory to help seperate
 symbols. In many cases its purely historical as to whether a symbol is
 marked _GPL or not.

Yes, I agree, I was just not talking about licensing/legal issues, but only
about the visible technical reasons and restrictions.

So I dont think I am confused... thanks for follow up, Alan.

Gruss
Bernd
-- 
  (OO) -- [EMAIL PROTECTED] --
 ( .. )[EMAIL PROTECTED],linux.de,debian.org}  http://www.eckes.org/
  o--o   1024D/E383CD7E  [EMAIL PROTECTED]  v:+497211603874  f:+49721151516129
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GFS, what's remaining

[Bernd Eckenfels]

On Mon, Sep 05, 2005 at 04:16:31PM +0200, Lars Marowsky-Bree wrote:
 That is the whole point why OCFS exists ;-)

The whole point of the orcacle cluster filesystem as it was described in old
papers was about pfiles, control files and software, because you can easyly
use direct block access (with ASM) for tablespaces.

 No. Beyond the table spaces, there's also ORACLE_HOME; a cluster
 benefits in several aspects from a general-purpose SAN-backed CFS.

Yes, I dont dispute the usefullness of OCFS for ORA_HOME (beside I think a
replicated filesystem makes more sense), I am just nor sure if anybody sane
would use it for tablespaces.

I guess I have to correct the artile in my german it blog :) (if somebody
can name productive customers).

Gruss
Bernd
-- 
http://itblog.eckenfels.net/archives/54-Cluster-Filesysteme.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>> The Linux kernel allows binary drivers, you just have to live with a limited
>> number of exported symbols and that the kernel is tainted. Which basically
>> means nobody sane can help you with corrupted kernel data structures.
> 
> You appear to be confused. The exported symbols are part of a GPL
> product. The only question of relevance is whether the item is a derived
> work in law or not. 

I dont understand that? Can you point out where I am confused?

Loading a non-GPL (tagged) module leads in tainting the kernel (which basically
is a flag for developers to be alerted while debugging), is that right?

Non GPL Modules are also restrited in the number of symbols they can use,
this is to make it harder to derive work from the Linux Kernel with a ABI
interface.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GFS, what's remaining

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> for ocfs we have tons of production customers running many terabyte
> databases on a cfs. why ? because dealing with the raw disk froma number
> of nodes sucks. because nfs is pretty broken for a lot of stuff, there
> is no consistency across nodes when each machine nfs mounts a server
> partition. yes nfs can be used for things but cfs's are very useful for
> many things nfs just can't do. want a list ? 

Oh thats interesting, I never thought about putting data files (tablespaces)
in a clustered file system. Does that mean you can run supported RAC on
shared ocfs2 files and anybody is using that? Do you see this go away with
ASM?

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GFS, what's remaining

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 for ocfs we have tons of production customers running many terabyte
 databases on a cfs. why ? because dealing with the raw disk froma number
 of nodes sucks. because nfs is pretty broken for a lot of stuff, there
 is no consistency across nodes when each machine nfs mounts a server
 partition. yes nfs can be used for things but cfs's are very useful for
 many things nfs just can't do. want a list ? 

Oh thats interesting, I never thought about putting data files (tablespaces)
in a clustered file system. Does that mean you can run supported RAC on
shared ocfs2 files and anybody is using that? Do you see this go away with
ASM?

Greetings
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 The Linux kernel allows binary drivers, you just have to live with a limited
 number of exported symbols and that the kernel is tainted. Which basically
 means nobody sane can help you with corrupted kernel data structures.
 
 You appear to be confused. The exported symbols are part of a GPL
 product. The only question of relevance is whether the item is a derived
 work in law or not. 

I dont understand that? Can you point out where I am confused?

Loading a non-GPL (tagged) module leads in tainting the kernel (which basically
is a flag for developers to be alerted while debugging), is that right?

Non GPL Modules are also restrited in the number of symbols they can use,
this is to make it harder to derive work from the Linux Kernel with a ABI
interface.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I disagree with the language and the characterization that our 
> proprietary user application code is "tainted."

The kernel is tainted if you install non-open source modules. You are not
allowed to circumvent this mechanism if you want to ship binary only
modules.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I mean, nvidia people also use propietary code in the kernel (probably
> violating the GPL anyway) and don't do such things.

The Linux kernel allows binary drivers, you just have to live with a limited
number of exported symbols and that the kernel is tainted. Which basically
means nobody sane can help you with corrupted kernel data structures.

Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 I mean, nvidia people also use propietary code in the kernel (probably
 violating the GPL anyway) and don't do such things.

The Linux kernel allows binary drivers, you just have to live with a limited
number of exported symbols and that the kernel is tainted. Which basically
means nobody sane can help you with corrupted kernel data structures.

Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] DSFS Network Forensic File System for Linux Patches

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 I disagree with the language and the characterization that our 
 proprietary user application code is tainted.

The kernel is tainted if you install non-open source modules. You are not
allowed to circumvent this mechanism if you want to ship binary only
modules.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Power consumption HZ100, HZ250, HZ1000: new numbers

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> No, I'm saying that 99% users enable ACPI and cpufreq. ACPI is needed
> on new machines, and cpufreq is usefull to keep your desktop cold,
> too.

And with the recent ongoing packing of CPU cores into racks, it is even more
so important for Servers.

Gruss
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Power consumption HZ100, HZ250, HZ1000: new numbers

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 No, I'm saying that 99% users enable ACPI and cpufreq. ACPI is needed
 on new machines, and cpufreq is usefull to keep your desktop cold,
 too.

And with the recent ongoing packing of CPU cores into racks, it is even more
so important for Servers.

Gruss
Bernd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/