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: 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: 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: 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: 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: [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: 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: 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(&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: 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: [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:
> 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: 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: [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/

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: 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: 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: 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]

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: [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: 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: RTC Timezone

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> My RTC clock is set to the local timezone. However, when I boot linux using 
> the -b option, to stop by a shell before the bootscripts begin, the clock is 
> exaclty two hours ahead.

The problem is that the clock is correct, but the timezone of your system is
not set yet. You can fix this by running the clock in UTC or not stop the boot
process that early.

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: a 15 GB file on tmpfs

[Bernd Eckenfels]

On Fri, Jul 22, 2005 at 01:00:18PM +0200, Stefan Smietanowski wrote:
> > You cant have 16GB of Memory with 32bit CPUs.
> PAE
> CONFIG_HIGMEM64G
> Supports a 36bit address space, which Xeons do support.

Yes right, I was just not aware recent hardware (still) supports that. I
mean even mit 2MB modules most of them are specified only to 8GB. I would
consider buying such a system quite foolish. All of the HP servers with 12GB
and more seem to support EM64T. Do you know vendors who ship non-EM64T
servers with more than 16GB?

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: a 15 GB file on tmpfs

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> The machine we plan to buy is a HP Proliant Xeon machine and I want to run a 
> 32 bit linux kernel on it (the xeon we want doesn't have the 64-bit stuff 
> yet)

You cant have 16GB of Memory with 32bit CPUs.

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: Swap partition vs swap file

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> So are you saying that if I create a swap partition it's best to use dd to
> zero it out before mkswap?

Nope I did not. However I dont know of any other shell tool which can do it
that easyly.

> As far as portable, we're talking about linux, portability is not an issue
> in this case. 

Portability across Filesystems.

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: Swap partition vs swap file

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> You misunderstood entirely what I said.

There is no portable/documented way to grow a file without having the file
system null its content. However why is that a problem, you dont create
those files very often. Besides it is better for the OS to be able to asume
that a page with zeros in it is equal to the page on fresh swap.

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: Swap partition vs swap file

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I guess/hope dd always makes it contiguously.

No, it is creating files by appending just like any other file write. One
could think about a call to create unfragmented files however since this is
not always working best is to create those files young or defragment them
before usage.

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: ia64 git pull

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Why? Because I'm still using the stupid "get all objects" thing when I
> pull.

one could do a symlink/hardlink parallel tree for a specific snapshot with
GIT tools, and then only poll that with git-unaware copy tools.

I guess this would make sense for the most common kernel development lines.

Another improvement would be to add a "secondary storage fetch" script, so
the git tools can, if they cant find a object by hash just query an external
pool. In combination with the above this will allow users to compare progress.

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: Why Ext2/3 needs immutable attribute?

[Bernd Eckenfels]

On Sun, Apr 17, 2005 at 07:48:50PM -0400, Xin Zhao wrote:
> any kernel level protection, including
> SELinux, could be disabled after the kernel is compromised. Am I
> missing some points here?

No, Immutable bit is an application of capabilities (or securelevel), you
are right.

If the kernel is compromised, the kernel is compromised. However immutable
bit can make it hard to circumvent kernel's protetion, even for root
attackers

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: Why Ext2/3 needs immutable attribute?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Yes. I know,  with immutable,  even root cannot modify sensitive
> files. What I am curious is if an intruder has root access, he may
> have many ways to turn off the immutable protection and modify files. 

If you secure your system correctly (i.e make /dev/*mem imutable, disalow
module loading, restrict io... (and I admit it is quite complicated to find
all holes and secure it correctly without additional ptches like SELinux))
then even root cant gt arround immutable or append only (without rebooting).

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: Why Ext2/3 needs immutable attribute?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Why not simply unset the write bit for all three groups of users? 
> That seems to be enough to prevent file modification.

# touch test
# chmod a-w test
# echo test > test
# cat test
test

Because this does not protect against writes from root and it does not
protect against root setting the flags again.

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: More performance for the TCP stack by using additional hardware chip on NIC

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> maybe one day you would be able to offload your firewall and policy
> router too :)

There are quite a few filtering NICs out there.

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: [PATCH encrypted swsusp 1/3] core functionality

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> The dmcrypt swap can only be unlocked by the user with a passphrase,
> which is analogous to how you unlock your ssh private key stored
> on the disk using a passphrase.

We talk about the unlocked system getting hacked. However I am not why the
hacker would head for the swap if he can as well read the ram.

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 encrypted swsusp 1/3] core functionality

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> The ssh keys are *encrypted* in the swap when dmcrypt is used.
> When the swap runs over dmcrypt all writes including those from
> swsusp are encrypted.

The problem is that after an resume the running system has access to the
swap, because the key is recoverd. And the left over hybernation data in the
swap can be read by the running kernel because the swap key is restored.
This is not an attack against a notebook in hybernaion, but an attack
against a running system with non-wiped bybernation leftovers - not critical
to me but an possible point of interest.

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: more git updates..

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> (I repeat the xxx in the leaf name - easier to code.)

It is a bit OT, but just a note: there are file systems (hash functions) out
there who dont like a lot of files named the same way. For example NTFS with
the 8.3 short names.

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: more git updates..

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Ralph wrote:
>> Watch out for when xargs invokes do_something more than once and the `<'
>> is parsed by a different one than the `>'.
> It will take a pretty long list to do that.  It seems that
> GNU xargs on top of a Linux kernel has a 128 KByte ARG_MAX.
> In the old days, with 4 KByte ARG_MAX limits, this would have
> bitten us pretty quickly.

Nevertheless I  think it is more parser friendly to have single records for
diffs.

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: Aligning file system data

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> How likely is it that I can actually align stuff to 31.5KiB on the
> physical disk, i.e. have each block be a track?

It is not that easy to allign on tracks, even on raw partition. Some disks
have different length of tracks (of course because the inner cylinders are
shorter), some show a totally different geometry than they have internally,
and the disks are happyly remapping.

With raid and lvm the situation get worse.

Why do you want to do thoe micro optimizations?

With a filesystem in between you have virtuelly no way to allign larger
files for streaming.

Let the buffer cache and prefetch do, what they are intended for and feel
happy.

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: [CHECKER] crash after fsync causing serious FS corruptions (ext2, 2.6.11)

[Bernd Eckenfels]

Hello Ted,

In article <[EMAIL PROTECTED]> you wrote:
> Should we fix it today?  Given that we have ext3, I'd probably answer
> no.  It's a known property of ext2; we've lived with it for over ten
> years, and to add this would just slow down ext2 (which gets used
> often as benchmark standard to aspire to), and make the ext2 codebase
> more complicated.

I am not too deep into FS design, however I have heared from some admins of
a pretty busy server, that the allocation method of placinf file content
close to the directories cause a lot of fragmentation there. So I wonder if
an simple change in allocation policy could lower the problems with the
fragmentation and (especially) lower the chance of blocks beeing reused too
often.

I might be able to get  the patch, however I am not sure if it will solves
or lowers the problem the checker group found.

The performance impact of such a changed allocation policy is, however on
the given system positive (due to decreased fragmentation).

BTW: I was not directly involved here in the decision process which FS to
use, however I am sure it is both related to performance and recoverability.
Because all recent (journalling) filesystems XFS, Reiser and ext3 very often
failed with big data loss in that environment, whereas ext2 could most often
be recovered very well. So from my point of you ext2 should not be
desupported.
 
Greetings
Bernd

PS: i have a before/after screenshot of the filesystem in this german
article. It is a pop3 server:
http://itblog.eckenfels.net/archives/8-Fragmentierung.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: Devices/Partitions over 2TB

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> You have to ignore the partition table contents for ending cylinder.

Why use MSDOS partition tables at all? What about LVM or GUID Partitions?

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: [MC] [CHECKER] Do ext2, jfs and reiserfs respect mount -o sync/dirsync option?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> 3. I open a file w/o O_SYNC, issue a bunch of writes, then call
> ioctl(FIOASYNC) to set the fd sync, then issure a second set of writes.
> Only the second set of writes are synchronous?

I also am curious if one can open a file, write to it, close it, open it and
do fsync()/fdatasync() on it?

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: Huge unreliability - does Linux have something to do with it?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I halted the machine correctly yesterday night. I never dropped the
> box in 3 years. Am I just being unlucky? Or could the fact that I am
> using Linux on the box affect the reliability in some ways on that
> particular hardware (Dell Inspiron 8100)? I run Linux on 3 other
> computers and never had single problems with them.

There are a lot of possible problems with your actual hardware. Like
Interrupt handling, power control, dma, ... Those are seldom but possible.
Notebooks tend to require some special handling.

> Could a hardware failure look like bad sectors to fsck?

A failure of the bus or a former sporadic error can cause defective fs, but
normally you have a read error in fsck no structure error.

Are you using hdparm? is the system perhaps overheating or overclocked?

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: Drive performance bottleneck

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>  Below is an oprofile (truncated) of (the same) dd running on /dev/sdb.

do  you also have the oprofile of the sg_dd handy?

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] "biological parent" pid

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I am not aware of concepts in Linux or other unices that apply to this
> case.

Normal process accounting.

If you want to keep the pid of the bio-parent, you also need to keep the
start-time to make it unique. Better would be to have a all-time-unqiue
process handle. But I think it is better to not have that field, but use
audit logs. That is especially needed if you want to track chains, because
it doesnt help you to know the bio parent if you have no idea what that was.

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: [Bug 4081] New: OpenOffice crashes while starting due to a threading error

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> stat64("/dev/dri/card14", 0xbff9c8bc)   = -1 ENOENT (No such file or 
> directory)

> What is at fault? Certainly oo shouldn't just seg-fault, but should the
> permissions on /dev/dri/card* be crw-rw or crw-rw-rw-?

it is not a permission thing, it tells you, that you have not card14 - and i
dont know the dri interface but it looks unlikely that there ever will be
one .)

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: Linux and system area networks

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> We seem to have come full circle.  My original question was about
> providing a better way for sockets applications to take advantage of
> SAN hardware.  W2K Datacenter introduces "Winsock Direct," which will
> bypass the protocol stack when appropriate.  The Infiniband people are
> working on a "Sockets Direct" standard, which is a similar idea.  No
> one seems to care about this for Linux.

Well, there is some work done by the zero-copy folks and the sendfile()
function. Realy much more than a mmaped network socket is not needed.

Besides it looks like SAN will go all the way in the IP Direction sooner or
later anyway :)

There are some interesting Features like accessing MS SQL 7.0 Server via VIA
architecture interfaces over SAN, I am not sure o how open VIA is.

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: harddisk support

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> How can I access more than 16 harddisks?
Create the Device File with:

cd /dev ; MAKEDEV sdq
-or-
cd /dev ; mknod sdq b 65 0
mknod sdq1 b 65 1
...
-
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 display proxy arp addresses using "ip neigh" from iproute2

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> 47.129.82.116 *   *   MPeth0

the asteriks simply show you, that the new linuix kernel will not be able to
remeber any mac address for a proxy arp entry. It will always respond with the
device' own MAC address. Can't find a way to display it with ip, "ip neigh
show nud all" will not show them, too.

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: missing sysrq

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> However, if I go to /proc/sys/kernel/sysrq does not exist.

It is a compile time option, so the person who compiled your kernel left it
out.

> vm.freepages = 383 766 1149

tat feature is removed in recent VM Systems.

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: light weight user level semaphores

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>   So FS_create() starts out by allocating the backing store for the
>   semaphore. This can basically be done in user space, although the
>   kernel does need to get involved for the second part of it, which
>   is to (a) allocate a kernel "backing store" thing that contains the
>   waiters and the wait-queues for other processes and (b) fill in the
>   opaque 128-bit area with the initial count AND the magic to make it
>   fly. More on the magic later.

>   So the second part of FS_create needs a new system call.

How will the clean up of the kernelstore work?

> - The user must _not_ be able to fool the kernel into using a completely
>   non-existing semaphore.

In that case the access to kernel level is protected by a very secure
combination of secure hash and magic number checking. But anyway there is a
small chance to get to some kernel memory unauthorized. Do you know if this is
the first (known) interface which has a more practical approach to kernel data
structure security?

If we want to be a bit more strict, we can have a pre-allocated pool of
semaphores and the kernel pointer check can add the kernelk address of the
semaphore region into account. It's faster than the checksum probably and more
secure in protecting the rest of the kernel memory. Spoofing access to other
semaphores would be still possible (but can be protected by a smaller hash).

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: ARP responses broken!

[Bernd Eckenfels]

> but why would you want it to reply for the IP of the other interface even if
> it was NOT on the same subnet?

Because Linux is always answering to all its local IP addresses, regardless
of the Network interface. Even if you tun off the IP Forwarding.

This is by Designs, there are situation where this is good and there are
situations where it is not so good. But it's an old tradition.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  eckes@irc  +497257930613  BE5-RIPE
(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: ARP responses broken!

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> The second one is the valid one, but both interfaces seem to answer to the
> broadcasted packet with their own ARP addresses.

it is because the kernel does not know if both interfaces are on one subnet,
or not. The easisets thing to solve this is t use the MAC moduleof netfilter
and deny the incoming requests/responsnes based on the ip.

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: fsck, raid reconstruction & bad bad 2.4.3

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Is this a pathological case because of the way fsck does business, or does the RAID 
>re-sync affect any disk-bound process that severely?

i gues the seeks are the problem. fsck will quite heavyly reposition, so does
the rebuild, most likely on different ends of the disk.

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: fsck, raid reconstruction & bad bad 2.4.3

[Bernd Eckenfels]

In article <01041521302600.15046@tabby> you wrote:
>>a) stop rebuild until fsck is fixed

> And let fsck read bad data because the raid doesn't yet recognize the correct
> one

a degraded raid will not deliver broken data. and even if it does, one more
reason not to check a degraded raid.

> There is nothing to fix in fsck. It should NOT know about the low level
> block storage devices. If it does, then fsck for EACH filesystem will
> have to know about ALL different raid hardware/software implementations.

fsck does not neet to be changed, yoi can have a shell script loop and check
the raid state before caling the fsck.

>>b) wait with fsck until rebuild is fixed

> Depends on your definition of "fixed"

fixed as in rebuild, thats what we where tlking about, no?

. The most I can see to fix is
> reduce the amount of continued update in favor of updating those blocks
> being read (by fsck or anything else). This really ought to be a runtime
> configuration option. If it is set to 0, then no automatic repair would
> be done.

yes would be a nice feature if rebuild can be made to only to io which is
required by the kernel anyway. since fsck will reach a lot of meta data this
is a fairly good start for a slow rebuild.

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: fsck, raid reconstruction & bad bad 2.4.3

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>>(There is no config file to disable/alter this .. no work-around that I
>>know of ..)

> You can't be serious.  Go sit down and think about what's going on.

Well, there are two potential solutions:

a) stop rebuild until fsck is fixed
b) wait with fsck until rebuild is fixed

Both of them are valid. The first one is valid in a scenario where you want to
decrease downtimes in favor of insecure operation/or multiple redundancy

The second one is good if you prefer data consitency over small down times. It
might actually speed up the bootup process, one has to measure this.

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: [BUG] tmpfs and loop

[Bernd Eckenfels]

In article <01041321112600.23961@oscar> you wrote:
> oscar% sudo mount /tmp/disk /snap -oloop -text2
> ioctl: LOOP_SET_FD: Invalid argument

are you sure you have a working loop device? Try to verify it in a non tmpfs
filesystem.

> stat64("/dev/loop0", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
> open("/dev/loop0", O_RDONLY|O_LARGEFILE) = 3
> ioctl(3, 0x4c03, 0xb7fc)= -1 ENXIO (No such device or address)

otherwise try this by hand with losetup.

> close(3)= 0
> open("/tmp/disk", O_RDWR|O_LARGEFILE)   = 3
> open("/dev/loop0", O_RDWR|O_LARGEFILE)  = 4
> mlockall(MCL_CURRENT|MCL_FUTURE)= 0
> ioctl(4, 0x4c00, 0x3)   = -1 EINVAL (Invalid argument)
> write(2, "ioctl: LOOP_SET_FD: Invalid argu"..., 37ioctl: LOOP_SET_FD: Invalid 
>argument

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: race condition on looking up inodes

[Bernd Eckenfels]

In article <000201c0c0a4$eb5c7b10$321ea8c0@saturn> you wrote:
>rename("/usr/hybrid/cfg/data","/usr/mytemp/data1"); /*for process 1*/
>  rename("/usr/mytemp/data1","/usr/test");/* for process 2*/

Rename syscall is expected to be atomic on unixoid systems. And I dont know of
a case where a problem is, besides if you use some network file system, where
nobody can realy gurantee anything (well kidding, but it is harder than on a
local one).

The second rename may see the result of the first rename or the original state
before the first rename. It will not see any half-state or locked nodes.

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: pivot_root & linuxrc problem

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Aha.. so that's it.  I've never been able to get /linuxrc to execute
> automagically.  I wonder why /linuxrc executes on Art's system, but
> not on mine.  I can call it whatever I want and it doesn't run unless
> I explicitly start it with init=whatever.

linuxrc is executed iff:

CONFIG_BLK_DEV_INITRD is defined
you actually have a initrd mounted
/dev/console can be found and opened
a executable "/linuxrc" is in the ramdisk

Note: initramdisks need to be set up and prepared by your boot loader or with
the right structure on your boot media. You also need to have a filesystem on
the initrd which the kernel can detect without modules. But kernel does not
need to be able to read from the boot device since the image is read by
bootloader (e.g. boot-prom or 16bit bios).

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: kernel 2.4.2 network performances

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Yesterday I discovered that the load I can throw out to network seems to
> depend on other activities running on machine. I was able to get
> throughput of 33M/s with ATM when machine was idle, while I compiled
> kernel at same time, the throughput was 135M/s.

- which protocol/application you have used for this
- how do you have measured throughput (try wristwatch!)

I could think that applications can profit from increased context switches
count, especially if there is a handshake network protocol going on. But it
could also be some hardware problems.

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: Alert on LAN for Linux?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Alert on LAN makes the system up from power management type sleep when
> there are packets to be processed.  Why you would ever have sleep mode on
> a server is beyond me.

Most professional UPS with Network Management Cards can go a sever to sleep
mode if the power gets down and they will
awake the Server with a "Wake-on-Lan" signal if power is back.

Afaik Wake-On-Lan is a Mainboard/Bios Feature and will work with any OS which
can put the System into the right Sleep mode.

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: Status of posix-ACL's

[Bernd Eckenfels]

In article  you wrote:
> What are the biggest problems? (i know that many userland-tools must be
> changed for this).

AFAIK there is no Support in User Land Programs required. You just have
additional tools for managing the ACLs . The main problem with ACLs are the
storage of the additional info in the file system. This is a hard job if you
want to have it for all/most file systems. Remy had a working Version for
ext2, but it never got very public.. dunno why.

NTs ACLs are somewhat messy cause they require too much scanning.

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: ide / usb problem

[Bernd Eckenfels]

In article <20010225060326.K127@pervalidus> you wrote:
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }

I think I saw that with broken Drives, too.

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: reiserfs: still problems with tail conversion

[Bernd Eckenfels]

In article <87861.983061717@tiny> you wrote:
> Exactly.  The tail conversion code depends heavily on the page up to date
> bit being set right.  It is more than possible that I've screwed up
> something there, and the code thinks a page is valid when it really isn't.

I have seen null byte corruptions in syslog files with ext2 in various
kernels. So perhaps it is a general VFS problem?

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] Near-constant time directory index for Ext2

[Bernd Eckenfels]

In article <01022100361408.18944@gimli> you wrote:
> But actually, rm is not problem, it's open and create.  To do a
> create you have to make sure the file doesn't already exist, and
> without an index you have to scan on average half the directory file. 

Unless you use a File System which is better for that, like Reiser-FS. Of
course a even better solution is to distribute those files in hashed subdirs.

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: ip_conntrack error under 2.4.1-ac18

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Feb 18 23:05:50 rhino kernel: ip_conntrack: maximum limit of 8184 entries exceed
> ed

> while running nessus, with 100 simultaneous connections set, against a
> company machine.  This is the first time I've observed this error.

It is not an error, you just used up all entries in the Conenction Track
Table. You can increase the number of entries or reduce the number of
concurrent Connections. You may also be able to use normal connect() scan
methods, AFAIK the timing out of the connections is better with this.

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: Kernel executation from ROM

[Bernd Eckenfels]

In article <01e701c09a2a$21e789a0$bba6b3d0@Toshiba> you wrote:
> I see . The biggest negative point of running kernel from ROM is that ROM
> speed is slow :(

Well, normally you use the ROM only as a "boot device". You copy the Kernel
into RAM and run it. Ram is not more expensive than ROM :)

What is your Reason for keeping the Kernel in ROM? Security? Do you have a
special limited Device? In that case you might want to look at the embedded
Linux Versions which run without MMU. Those might even have a decent ROM
Performance (compared to RAM).

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: reiserfs min size (was: [2.4.1] mkreiserfs on loopdevice freezes kernel)

[Bernd Eckenfels]

On Wed, Jan 31, 2001 at 11:15:56PM +, James Sutherland wrote:
> > dd if=/dev/zero of=/var/loop.img count=32768 size=4096
> 
> That just creates a 128Mb file of zeros... This sounds a bit small. Why
> "size=4096"??

because i am too tired to calculate. mkreiserfs wants 32768 (32*1024) blocks
with a size of 4k. I created the smallest possible image to test reiserfs.

> > Yes, I wonder if it is a Error in mkreiserfs to require 128MB.
> 
> Have you tried using a smaller blocksize to mkreiserfs?

Sure I have.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  eckes@irc  +497257930613  BE5-RIPE
(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]
Please read the FAQ at http://www.tux.org/lkml/

reiserfs min size (was: [2.4.1] mkreiserfs on loopdevice freezes kernel)

[Bernd Eckenfels]

On Wed, Jan 31, 2001 at 09:24:39AM +, James Sutherland wrote:
> 32 megaBLOCK?? How big is it in Mbytes?

Blocksize is 4k, mkreiserfs in my version is telling me it can not generate
partitions smaller than 32M but it is not true, i have to do

dd if=/dev/zero of=/var/loop.img count=32768 size=4096

> You do know reiserfs defaults to
> building a 32 Mbyte journal on the device, I take it?

Yes, I wonder if it is a Error in mkreiserfs to require 128MB.

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  eckes@irc  +497257930613  BE5-RIPE
(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]
Please read the FAQ at http://www.tux.org/lkml/

[2.4.1] mkreiserfs on loopdevice freezes kernel

[Bernd Eckenfels]

Hello,

if I run mkreiserfs on a 32megablocks /dev/loop0 it will lock up while
generating the journaling information. Sometimes at 20% sometimes at 60%.
Since mkreiserfs is not using the kernel module i guess this is a loop
device problem in 2.4.1 kernels.

There is no dmesg message at the lookup. mkreiserfs is in state 'D'. The
system issomewhat useable (X) but some programs just lock in syscalls (no su
or login possible).

If I run losetup -d /dev/loop0 on that device i will get a message that it
is busy, but the program will not return enymore. It is in 'D' also.

This is an unecncrypted loop device on a ext2 filesystem on a AIC-7861. Loop
is autoloaded as a module.

Wanted to try reiserfs with some verbose debugging for some time. Well,
perhaps md is my friend...

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  eckes@irc  +497257930613  BE5-RIPE
(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]
Please read the FAQ at http://www.tux.org/lkml/

Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> On Tue, Jan 30, 2001 at 02:17:57PM -0800, David S. Miller wrote:

> 8.5MB/sec sounds like half-duplex 100baseT.

> No; I'm 100% its  FD; HD gives 40k/sec TCP because of collisions and
> such like.

> Positive you are running at full duplex all the way to the
> netapp, and if so how many switches sit between you and this
> netapp?

> It's FD all the way (we hardwire everything to 100-FD and never trust
> auto-negotiate); I see no errors or such like anywhere.

> There are ...  ... 3 switches between four switches in
> between, mostly linked via GE. I'm not sure if latency might be an
> issue here, is it was critical I can imagine 10 km of glass might be
> a problem but it's not _that_ far...

>   --cw

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



> ---
>Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
>  Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
>Fragen zum Gateway -> [EMAIL PROTECTED]
> ---
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Request: increase in PCI bus limit

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I guess the cleanest solution would be to allow variable setting of the
> maximum number of PCI busses in the config file, similar to the
> CONFIG_UNIX98_PTY_COUNT setting, so that "exotic" users with 32+ PCI
> busses can boost the standard value according to their needs, without
> having to increase kernel size for the normal users.

May even decrease the kernel for systems < 4 busses.

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

Re: Request: increase in PCI bus limit

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> 256, in later 2.4.* kernel releases?  That would allow this customer to
> work with an unpatched kernel, at the cost of an additional 3.5 kB of
> variables in the kernel.

Don't think this is fairly common. So especially since I consider that kind of
hardware (what is it) to require finetuning ("enterprise kernel") anyway,
there is no real gain out of it, as long as the structure is not dynamically.

Is that some kind of file server or masspar system? Intel?

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