Hi Frans!
Let's see whether I can explain this (I'm not a guru...)
On 11 Nov 2007, at 11:06, Frans Pop wrote:
I'm not sure whether this is a bug or expected behavior.
Suppose I create a "looped" bind mount situation as follows.
# mkdir test
# touch test/foo
# mkdir bindtest
# touch
Hi Frans!
Let's see whether I can explain this (I'm not a guru...)
On 11 Nov 2007, at 11:06, Frans Pop wrote:
I'm not sure whether this is a bug or expected behavior.
Suppose I create a looped bind mount situation as follows.
# mkdir test
# touch test/foo
# mkdir bindtest
# touch
Hi Zoltan!
On 26 Jun 2007, at 16:37, Zoltán HUBERT wrote:
If your vendor don't want to support you anymore, try
getting the source.
I was asking for a stable kernel, like 2.4, 2.2, 2.0 were
before. 2.6 is not. It's a great kernel, better than that
of MacOS X, I never said you were doing a
Hi Zoltan!
On 26 Jun 2007, at 16:37, Zoltán HUBERT wrote:
If your vendor don't want to support you anymore, try
getting the source.
I was asking for a stable kernel, like 2.4, 2.2, 2.0 were
before. 2.6 is not. It's a great kernel, better than that
of MacOS X, I never said you were doing a
Hi!
On 7 May 2007, at 20:27, OGAWA Hirofumi wrote:
Roland Kuhn <[EMAIL PROTECTED]> writes:
PATH_MAX specifically counts _bytes_ not characters, so UTF-8 does
not matter. ISTR that PATH_MAX was 256 at some point, but I just
quickly grepped /usr/include and found various mention of 40
Hi Andrey!
On 7 May 2007, at 19:51, Andrey Borzenkov wrote:
This was posted in one of Russian forums. It was not possible to
archive
(under Linux, using tar) vfat directory where files had long
Russian names
(really long - over 150 - 170 characters) - tar returned stat
failure. When
Hi Andrey!
On 7 May 2007, at 19:51, Andrey Borzenkov wrote:
This was posted in one of Russian forums. It was not possible to
archive
(under Linux, using tar) vfat directory where files had long
Russian names
(really long - over 150 - 170 characters) - tar returned stat
failure. When
Hi!
On 7 May 2007, at 20:27, OGAWA Hirofumi wrote:
Roland Kuhn [EMAIL PROTECTED] writes:
PATH_MAX specifically counts _bytes_ not characters, so UTF-8 does
not matter. ISTR that PATH_MAX was 256 at some point, but I just
quickly grepped /usr/include and found various mention of 4096, so
Hi Jens!
On 25 Apr 2007, at 12:18, Jens Axboe wrote:
On Wed, Apr 25 2007, Brad Campbell wrote:
Jens Axboe wrote:
It looks to be extremely rare. Aliases are extremely rare, front
merges
are rare. And you need both to happen with the details you
outlined. But
it's a large user base, and
Hi Jens!
On 25 Apr 2007, at 12:18, Jens Axboe wrote:
On Wed, Apr 25 2007, Brad Campbell wrote:
Jens Axboe wrote:
It looks to be extremely rare. Aliases are extremely rare, front
merges
are rare. And you need both to happen with the details you
outlined. But
it's a large user base, and
Hi Jens!
On 24 Apr 2007, at 14:32, Jens Axboe wrote:
On Tue, Apr 24 2007, Roland Kuhn wrote:
Hi Jens!
[I made a typo in the Cc: list so that lkml is only included as of
now. Actually I copied the typo from you ;-) ]
Well no, you started the typo, I merely propagated it and forgot to
fix
Hi Jens!
[I made a typo in the Cc: list so that lkml is only included as of
now. Actually I copied the typo from you ;-) ]
On 24 Apr 2007, at 11:40, Jens Axboe wrote:
On Tue, Apr 24 2007, Jens Axboe wrote:
On Tue, Apr 24 2007, Roland Kuhn wrote:
Hi Jens!
On 24 Apr 2007, at 11:18, Jens
Hi Jens!
[I made a typo in the Cc: list so that lkml is only included as of
now. Actually I copied the typo from you ;-) ]
On 24 Apr 2007, at 11:40, Jens Axboe wrote:
On Tue, Apr 24 2007, Jens Axboe wrote:
On Tue, Apr 24 2007, Roland Kuhn wrote:
Hi Jens!
On 24 Apr 2007, at 11:18, Jens
Hi Jens!
On 24 Apr 2007, at 14:32, Jens Axboe wrote:
On Tue, Apr 24 2007, Roland Kuhn wrote:
Hi Jens!
[I made a typo in the Cc: list so that lkml is only included as of
now. Actually I copied the typo from you ;-) ]
Well no, you started the typo, I merely propagated it and forgot to
fix
Hi!
On 7 Apr 2007, at 08:58, JanuGerman wrote:
1) I have just a file path with me, an absolute path, but no
dentry, no inode, no vfsmount object, which function i can call to
get a "file" object associated with the absoulte file path. I have
surfed arround the source code especially
Hi!
On 7 Apr 2007, at 08:58, JanuGerman wrote:
1) I have just a file path with me, an absolute path, but no
dentry, no inode, no vfsmount object, which function i can call to
get a file object associated with the absoulte file path. I have
surfed arround the source code especially
Hi Andi!
On 6 Mar 2007, at 15:45, Andi Kleen wrote:
Let me see... You throw code like that and expect someone to actually
understand it in one year, and be able to correct a bug ?
To be honest I don't expect any bugs in this function.
Please add something, an URL or even better a nice
Hi Andi!
On 6 Mar 2007, at 15:45, Andi Kleen wrote:
rant
Let me see... You throw code like that and expect someone to actually
understand it in one year, and be able to correct a bug ?
To be honest I don't expect any bugs in this function.
/rant
Please add something, an URL or even better
Hi Guillaume!
On 2 Feb 2007, at 14:48, Guillaume Chazarain wrote:
2007/2/2, Roland Kuhn <[EMAIL PROTECTED]>:
That's a bug, right?
No, if you want something like: (echo toto; date; echo titi) > file
to work in your shell, you'll be happy to have the seek position
shared in the
Hi Philippe!
On 2 Feb 2007, at 00:15, Philippe Troin wrote:
Denis Vlasenko <[EMAIL PROTECTED]> writes:
What share the same file descriptor? MC and programs started from it?
All the processes started from your shell share at least fds 0, 1
and 2.
I thought after exec() fds atre either
Hi Philippe!
On 2 Feb 2007, at 00:15, Philippe Troin wrote:
Denis Vlasenko [EMAIL PROTECTED] writes:
What share the same file descriptor? MC and programs started from it?
All the processes started from your shell share at least fds 0, 1
and 2.
I thought after exec() fds atre either
Hi Guillaume!
On 2 Feb 2007, at 14:48, Guillaume Chazarain wrote:
2007/2/2, Roland Kuhn [EMAIL PROTECTED]:
That's a bug, right?
No, if you want something like: (echo toto; date; echo titi) file
to work in your shell, you'll be happy to have the seek position
shared in the processes
Hi Jan!
On 21 Jan 2007, at 22:12, Jan Engelhardt wrote:
How fast is your Ethernet port? 100Mbps or 95.37Mbps?
Same lie like with harddrives. It's around 80, not 100.
But it depends on how you look at it. 80 for Layer3, possibly
a little more for Layer2/1.
Nope, I get consistently 12e6
Hi Jan!
On 21 Jan 2007, at 22:12, Jan Engelhardt wrote:
How fast is your Ethernet port? 100Mbps or 95.37Mbps?
Same lie like with harddrives. It's around 80, not 100.
But it depends on how you look at it. 80 for Layer3, possibly
a little more for Layer2/1.
Nope, I get consistently 12e6
Hi Ranko!
On Apr 4, 2005, at 4:36 PM, Ranko Zivojnovic wrote:
(please do CC replies as I am still not on the list)
As I am kind of pressured to resolve this issue, I've set up a test
environment using VMWare in order to reproduce the problem and
(un)fortunately the attempt was successful.
I have
Hi Ranko!
On Apr 4, 2005, at 4:36 PM, Ranko Zivojnovic wrote:
(please do CC replies as I am still not on the list)
As I am kind of pressured to resolve this issue, I've set up a test
environment using VMWare in order to reproduce the problem and
(un)fortunately the attempt was successful.
I have
Hi Clemens!
On Feb 17, 2005, at 9:09 AM, Clemens Schwaighofer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/17/2005 04:55 PM, Roland Kuhn wrote:
That said, it would of course be possible to improve the internal
workflow of our emperor penguin if he used subversion
Hi Clemens!
On Feb 17, 2005, at 9:09 AM, Clemens Schwaighofer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/17/2005 04:55 PM, Roland Kuhn wrote:
That said, it would of course be possible to improve the internal
workflow of our emperor penguin if he used subversion
Hi Clemens!
On Feb 17, 2005, at 1:11 AM, Clemens Schwaighofer wrote:
first. what kind of advantages does bk have over other svn? Seriously.
If Apache can use it, and gcc might use it (again two very large
projects), what makes linux so differetnt that it can't.
And I don't want _anything_ from
Hi Clemens!
On Feb 17, 2005, at 1:11 AM, Clemens Schwaighofer wrote:
first. what kind of advantages does bk have over other svn? Seriously.
If Apache can use it, and gcc might use it (again two very large
projects), what makes linux so differetnt that it can't.
And I don't want _anything_ from
Hi folks!
After seeing the Oops below (and rebooting), I looked into /proc/ksyms
(because ksymoops complained about mismatches), and I could not find
system_call, do_page_fault, etc. Shouldn't they be there? When doing
ksymoops with /proc/ksyms I found recursive calling of do_brk, which
for sure
Hi folks!
After seeing the Oops below (and rebooting), I looked into /proc/ksyms
(because ksymoops complained about mismatches), and I could not find
system_call, do_page_fault, etc. Shouldn't they be there? When doing
ksymoops with /proc/ksyms I found recursive calling of do_brk, which
for sure
On Sun, 3 Jun 2001, Trond Myklebust wrote:
> Are /home and /compass on the same mount point on the client though?
> If not, then they won't share the same port.
>
> IOW: they will only share the same port if you have '/' as the NFS
> mountpoint.
When I mount via nfs each mount gets its own
On Sun, 3 Jun 2001, Trond Myklebust wrote:
Are /home and /compass on the same mount point on the client though?
If not, then they won't share the same port.
IOW: they will only share the same port if you have '/' as the NFS
mountpoint.
When I mount via nfs each mount gets its own local
On 1 Jun 2001, Trond Myklebust wrote:
> > (port-unreachable) goes out to the server. This is annoying
> > since it blocks all access to that directory. The request in
> > question is sent and received at port 772.
>
> > I'm using kernel 2.4.4.
>
> You probably have set
On 1 Jun 2001, Trond Myklebust wrote:
(port-unreachable) goes out to the server. This is annoying
since it blocks all access to that directory. The request in
question is sent and received at port 772.
I'm using kernel 2.4.4.
You probably have set ipchains or
Hi folks!
When I lstat64 a directory on an nfs mount the answer to GETATTR is
received by the network interface but dropped (not seen by the client)
afterwards. Only 50musec after the receive of the answer an
icmp-destination-unreachable (port-unreachable) goes out to the server.
This is
Hi folks!
When a process tries to lstat64 a file on nfs and the reply is not
received it gets blocked forever. Should it be that way?
Please help,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Hi folks!
When a process tries to lstat64 a file on nfs and the reply is not
received it gets blocked forever. Should it be that way?
Please help,
Roland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Hi folks!
When I lstat64 a directory on an nfs mount the answer to GETATTR is
received by the network interface but dropped (not seen by the client)
afterwards. Only 50musec after the receive of the answer an
icmp-destination-unreachable (port-unreachable) goes out to the server.
This is
Hi folks!
All of a sudden I experienced at least two Oopses looking like the
attached one, which is from process X (the other was bash, but the message
had nearly scrolled away). Since I can't find this exact code sequence in
arch/i386/entry.S (it appeared exactly the same in the bash Oops) I am
Hi folks!
All of a sudden I experienced at least two Oopses looking like the
attached one, which is from process X (the other was bash, but the message
had nearly scrolled away). Since I can't find this exact code sequence in
arch/i386/entry.S (it appeared exactly the same in the bash Oops) I am
42 matches
Mail list logo
