Hi,
On Sun, 31 Dec 2000, Alexander Viro wrote:
> Reread the original thread. GFP_BUFFER protects us from buffer cache
> allocations triggering pageouts. It has nothing to the deadlock scenario
> that would come from grabbing ->i_sem on pageout.
I don't want to grab i_sem. It was a very, very
Hi,
On Sun, 31 Dec 2000, Alexander Viro wrote:
Reread the original thread. GFP_BUFFER protects us from buffer cache
allocations triggering pageouts. It has nothing to the deadlock scenario
that would come from grabbing -i_sem on pageout.
I don't want to grab i_sem. It was a very, very early
Hi,
On Mon, 1 Jan 2001, Alexander Viro wrote:
But... But with AFFS you _have_ exclusion between block-allocation and
truncate(). It has no sparse files, so pageout will never allocate
anything. I.e. all allocations come from write(2). And both write(2) and
truncate(2) hold i_sem.
Problem
Hi,
On Sun, 31 Dec 2000, Linus Torvalds wrote:
> cached_allocation = NULL;
>
> repeat:
> spin_lock();
> result = try_to_find_existing();
> if (!result) {
> if (!cached_allocation) {
>
Hi,
On Sun, 31 Dec 2000, Linus Torvalds wrote:
> Let me repeat myself one more time:
>
> I do not believe that "get_block()" is as big of a problem as people make
> it out to be.
The real problem is that get_block() doesn't scale and it's very hard to
do. A recursive per inode-semaphore
Hi,
On Sat, 30 Dec 2000, Linus Torvalds wrote:
> In fact, in a properly designed filesystem just a bit of low-level caching
> would easily make the average "get_block()" be very fast indeed. The fact
> that right now ext2 has not been optimized for this is _not_ a reason to
> design the VFS
Hi,
On Sat, 30 Dec 2000, Linus Torvalds wrote:
In fact, in a properly designed filesystem just a bit of low-level caching
would easily make the average "get_block()" be very fast indeed. The fact
that right now ext2 has not been optimized for this is _not_ a reason to
design the VFS layer
Hi,
On Sun, 31 Dec 2000, Linus Torvalds wrote:
Let me repeat myself one more time:
I do not believe that "get_block()" is as big of a problem as people make
it out to be.
The real problem is that get_block() doesn't scale and it's very hard to
do. A recursive per inode-semaphore might
Hi,
On Sun, 31 Dec 2000, Linus Torvalds wrote:
cached_allocation = NULL;
repeat:
spin_lock();
result = try_to_find_existing();
if (!result) {
if (!cached_allocation) {
Hi,
On Sun, 31 Dec 2000, Andrea Arcangeli wrote:
> > estimate than just the data blocks it should not be hard to add an
> > extra callback to the filesystem.
>
> Yes, I was thinking at this callback too. Such a callback is nearly the only
> support we need from the filesystem to provide
Hi,
On Sun, 31 Dec 2000, Andrea Arcangeli wrote:
estimate than just the data blocks it should not be hard to add an
extra callback to the filesystem.
Yes, I was thinking at this callback too. Such a callback is nearly the only
support we need from the filesystem to provide allocate on
Hi,
On Mon, 18 Dec 2000, Bernardo Innocenti wrote:
> [1.] One line summary of the problem:
> mounting affs over loop hangs in syscall (x86 only?)
affs plays some games with the suberblock lock, I have a patch that plays
even worse games, but it works. I hope to finish a major cleanup of affs
Hi,
On Mon, 18 Dec 2000, Bernardo Innocenti wrote:
[1.] One line summary of the problem:
mounting affs over loop hangs in syscall (x86 only?)
affs plays some games with the suberblock lock, I have a patch that plays
even worse games, but it works. I hope to finish a major cleanup of affs
Hi,
On Tue, 17 Oct 2000, Andries Brouwer wrote:
> But you see that one would need a new name as well,
> otherwise the value associated with BLKSSZGET would
> depend on the kernel version, and one would need
> version checks anyway.
We do rename structures too, and this would be similiar. I'm
Hi,
> - BLKSSZGET added in common.h
Why don't we give BLKSSZGET a new number and make the old one obsolete? I
don't think it's used anywhere, as its result is pretty useless in
userspace (and even if it's used somewhere, they have to copy the define
anyway). This way we don't need that version
Hi,
> Concerning fdisk, luckily you are mistaken - its source says
>
> #if defined(BLKSSZGET) && defined(HAVE_blkpg_h)
>
> so that it will not use the broken BLKSSZGET of 2.2.
??? BLKSSZGET has exactly the same ioctl number in 2.2 and 2.4, so if I
compile fdisk under 2.4 and try to use it
Hi,
I noticed that behaviour of BLKSSZGET changed between 2.2 and 2.4. One of
the users will be fdisk, as soon as it is compiled with 2.4 kernel
headers, but then fdisk will be no longer usable under 2.2!
My question now is, wouldn't it be better to use a new ioctl (like
BLKHSSZGET) and keep the
Hi,
I noticed that behaviour of BLKSSZGET changed between 2.2 and 2.4. One of
the users will be fdisk, as soon as it is compiled with 2.4 kernel
headers, but then fdisk will be no longer usable under 2.2!
My question now is, wouldn't it be better to use a new ioctl (like
BLKHSSZGET) and keep the
Hi,
Concerning fdisk, luckily you are mistaken - its source says
#if defined(BLKSSZGET) defined(HAVE_blkpg_h)
so that it will not use the broken BLKSSZGET of 2.2.
??? BLKSSZGET has exactly the same ioctl number in 2.2 and 2.4, so if I
compile fdisk under 2.4 and try to use it under 2.2,
Hi,
- BLKSSZGET added in common.h
Why don't we give BLKSSZGET a new number and make the old one obsolete? I
don't think it's used anywhere, as its result is pretty useless in
userspace (and even if it's used somewhere, they have to copy the define
anyway). This way we don't need that version
Hi,
On Sun, 15 Oct 2000, Andi Kleen wrote:
> You can just use the coded out variant (x<>(sizeof(x)*8-n)))
> gcc is clever enough to turn it into an rotate when the CPU supports it.
Hmm, I just tried it and two things one should take care of here. 1. x
must be unsigned of course and 2. only
Hi,
On Fri, 13 Oct 2000, Richard Henderson wrote:
> Either that or adjust how we do atomic operations. I can do
> 64-bit atomic widgetry, but not with the code as written.
It's probably more something for 2.5, but what about adding a lock
argument to the atomic operations, then sparc could
Hi,
On Fri, 13 Oct 2000, Richard Henderson wrote:
Either that or adjust how we do atomic operations. I can do
64-bit atomic widgetry, but not with the code as written.
It's probably more something for 2.5, but what about adding a lock
argument to the atomic operations, then sparc could use
Hi,
> How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
> __builtin_return_address() yields garbage. Does anybody have a generic
> solution to this problem, other than "compile with frame pointers"? Or is
> it fixed in newer versions of gcc?
Are you sure? I just I
Hi,
How? If you compile with egcs-2.91.66 without frame pointers on ix86 then
__builtin_return_address() yields garbage. Does anybody have a generic
solution to this problem, other than "compile with frame pointers"? Or is
it fixed in newer versions of gcc?
Are you sure? I just I tried
Hi,
On Wed, 11 Oct 2000, Alan Cox wrote:
> > http://www.osopinion.com/Opinions/MontyManley/MontyManley15.html
> >
> > good article, several unfortunate truths within.
>
> Really, must be a wrong URL you posted then 8)
>
> The average Linux kernel hacker right now is late 20's to early 30's
Hi,
On Wed, 11 Oct 2000, Alan Cox wrote:
http://www.osopinion.com/Opinions/MontyManley/MontyManley15.html
good article, several unfortunate truths within.
Really, must be a wrong URL you posted then 8)
The average Linux kernel hacker right now is late 20's to early 30's with
a
Hi,
> The m68k port which has a interrupt stack solves the problem by
> loading current into a global register variable on all kernel entries.
Not all m68k cpus have an interrupt stack and it can be turned off, so we
don't use it.
bye, Roman
-
To unsubscribe from this list: send the line
Hi,
The m68k port which has a interrupt stack solves the problem by
loading current into a global register variable on all kernel entries.
Not all m68k cpus have an interrupt stack and it can be turned off, so we
don't use it.
bye, Roman
-
To unsubscribe from this list: send the line
Hi,
A few bss changes (to remove zero initialization) in test9 were not
completly correct. Init data must be initialized if you want that it gets
into the init section (it's also mentioned in the gcc documentation).
The following patch fixes what I was able to find with grep and also adds
a note
Hi,
A few bss changes (to remove zero initialization) in test9 were not
completly correct. Init data must be initialized if you want that it gets
into the init section (it's also mentioned in the gcc documentation).
The following patch fixes what I was able to find with grep and also adds
a note
Hi,
On Mon, 2 Oct 2000, Andrea Arcangeli wrote:
> > When that is done, please don't call __sti() directly and use some macro
> > that can be overridden by the architectures.
>
> What do you have in mind while making this suggestion? The irq highlevel layer
> is pretty much architectural
Hi,
On Sun, 1 Oct 2000, Andrea Arcangeli wrote:
> Comments?
When that is done, please don't call __sti() directly and use some macro
that can be overridden by the architectures.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hi,
On Mon, 2 Oct 2000, Andries Brouwer wrote:
> These days I have as background activity the construction
> of the corresponding patch for 2.4. Maybe we can start 2.5
> without these arrays and with large device numbers.
I started something like this a few months ago, I was at the point to
Hi,
On Mon, 2 Oct 2000, Andries Brouwer wrote:
These days I have as background activity the construction
of the corresponding patch for 2.4. Maybe we can start 2.5
without these arrays and with large device numbers.
I started something like this a few months ago, I was at the point to boot
Hi,
On Sun, 1 Oct 2000, Andrea Arcangeli wrote:
Comments?
When that is done, please don't call __sti() directly and use some macro
that can be overridden by the architectures.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hi,
On Mon, 2 Oct 2000, Andrea Arcangeli wrote:
When that is done, please don't call __sti() directly and use some macro
that can be overridden by the architectures.
What do you have in mind while making this suggestion? The irq highlevel layer
is pretty much architectural indipendent.
Hi,
On Mon, 4 Sep 2000, Alan Cox wrote:
> Then they need more competant admins. It isnt _hard_ to transproxy outgoing
> smtp traffic via a spamtrapper that checks for valid src/destination and
> headers.
You get into a dangerous field here. If you start arguing like this, how
do you explain to
Hi,
On Mon, 4 Sep 2000, Alan Cox wrote:
Then they need more competant admins. It isnt _hard_ to transproxy outgoing
smtp traffic via a spamtrapper that checks for valid src/destination and
headers.
You get into a dangerous field here. If you start arguing like this, how
do you explain to a
Hi,
On Thu, 31 Aug 2000, Alexander Viro wrote:
> Go ahead, write it. IMNSHO it's going to be much more complicated and
> race-prone, but code talks. If you will manage to write it in clear and
> race-free way - fine. Frankly, I don't believe that it's doable.
It will be insofar more
Hi,
> > - get dentry foo
> > - get dentry baz
>
> How? OK, you've found block of baz. You know the name, all right.
Links are chained together and all point back to the original, so if you
remove the original, you have quite something to do with lots of links.
> Now
> you've got to do the
Hi,
On Wed, 30 Aug 2000, Alexander Viro wrote:
> c) ->i_sem on pageout? When?
For 2.2.16:
filemap_write_page() <- filemap_swapout() <- try_to_swap_out() <- ... <-
swap_out() <- do_try_to_free_pages() <- kswapd()
filemap_write_page() takes i_sem and calls do_write_page(). What did I
Hi,
(Sorry for the previous empty mail, I was a bit too fast with sending and
couldn't stop it completly.)
On Wed, 30 Aug 2000, Alexander Viro wrote:
I concentrate on the most interesting part:
> As for AFFS directory format - fine, please describe the data
> manipulations required by
-
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/
-
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/
Hi,
On Wed, 30 Aug 2000, Alexander Viro wrote:
c) -i_sem on pageout? When?
For 2.2.16:
filemap_write_page() - filemap_swapout() - try_to_swap_out() - ... -
swap_out() - do_try_to_free_pages() - kswapd()
filemap_write_page() takes i_sem and calls do_write_page(). What did I
miss?
Hi,
- get dentry foo
- get dentry baz
How? OK, you've found block of baz. You know the name, all right.
Links are chained together and all point back to the original, so if you
remove the original, you have quite something to do with lots of links.
Now
you've got to do the full
Hi,
> Show me these removed locks. The only polite explanation I see is
> that you have serious reading comprehension problems. Let me say it once
> more, hopefully that will sink in:
>
> Your repeated claims of VFS becoming more multi-threaded in ways
> that are not transparent to
Hi,
> It sounds to me like different FSes have different needs. Maybe the best
> approach is to have two or three fs APIs, according to the needs of the
> fs.
No, having several fs API is a maintainance nightmare, I think that's
something everyone agrees on. What is needed is to modify the API
Hi,
Tony Mantler wrote:
> For those of you who would rather not have read through this entire email,
> here's the condensed version: VFS is inherintly a wrong-level API, QNX does
> it much better. Flame on. :)
VFS isn't really wrong, the problem is that it moved from an almost
single threaded
Hi,
> Yes? And it will become simpler if you will put each and every locking
> scheme into the API?
No, I didn't say that. I want the API to be less restrictive and make
the job for the fs a bit easier. IMO the current API is inconsistent
and/or incomplete and I'm still trying to find out what
Hi,
Tony Mantler wrote:
For those of you who would rather not have read through this entire email,
here's the condensed version: VFS is inherintly a wrong-level API, QNX does
it much better. Flame on. :)
VFS isn't really wrong, the problem is that it moved from an almost
single threaded API
Hi,
> > hfs. For example reading from a file might require a read from a btree
> > file (extent file), with what another file write can be busy with (e.g.
> > reordering the btree nodes).
>
> And?
The point is: the thing I like about Linux is its simple interfaces, it's
the basic idea of unix
Hi,
> Darnit, documentation on filesystem locking is there for purpose. First
> folks complain about its absence, then they don't bother to read the
> bloody thing once it is there. Furrfu...
It's great that it's there, but still doesn't tell you everything.
> Said that, handling of indirect
Hi,
Here is a patch for anyone who needs to access HFS on e.g. an MO drive.
It's only for 2.2.16, but I was able to do that as part of my job as we
need that functionality. Anyway, I've read also a bit through HFS+ spec
and IMO basically most of the current hfs needs to rewritten for 2.4,
e.g.
1001 - 1055 of 1055 matches
Mail list logo
