On Thu, 11 Jan 2007 08:43:36 +0530
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
> > The s/lock_page_slow/lock_page_blocking/ got lost. I redid it.
>
> I thought the lock_page_blocking was an alternative you had suggested
> to the __lock_page vs lock_page_async discussion which got resolved la
On Wed, Jan 10, 2007 at 05:08:29PM -0800, Andrew Morton wrote:
> On Wed, 10 Jan 2007 11:14:19 +0530
> Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jan 04, 2007 at 09:02:42AM -0800, Andrew Morton wrote:
> > > On Thu, 4 Jan 2007 10:26:21 +0530
> > > Suparna Bhattacharya <[EMAIL PROT
On Wed, 10 Jan 2007 11:14:19 +0530
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 04, 2007 at 09:02:42AM -0800, Andrew Morton wrote:
> > On Thu, 4 Jan 2007 10:26:21 +0530
> > Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew
Josef Sipek wrote:
On Wed, Jan 10, 2007 at 05:12:15PM +0100, Jan Kara wrote:
I see :). To me it just sounds as if you want to do remount-read-only
for source filesystems, which is operation we support perfectly fine,
and after that create union mount. But I agree you cannot do quite that
sin
On Wed, Jan 10, 2007 at 05:12:15PM +0100, Jan Kara wrote:
> I see :). To me it just sounds as if you want to do remount-read-only
> for source filesystems, which is operation we support perfectly fine,
> and after that create union mount. But I agree you cannot do quite that
> since you need to h
Christoph Hellwig wrote:
>
>> return -ENOMEM;
>> +/* set to high value to try and avoid collisions with loop below */
>> +inode->i_ino = 0x;
>> +insert_inode_hash(inode);
>
> This is odd. Can't we just add some constant base to the loop below?
>
I thought the sa
> In message <[EMAIL PROTECTED]>, Jan Kara writes:
> > > In message <[EMAIL PROTECTED]>, Jan Kara writes:
> [...]
> > > Jan, all of it is duable: we can downgrade the f/s to readonly, grab
> > > various
> > > locks, search through various lists looking for open fd's and such, then
> > > decide if
On Mon, Jan 08, 2007 at 03:47:17PM -0500, Jeff Layton wrote:
> This converts pipefs to use the new scheme. Here we're calling iunique to get
> a unique i_ino value for the new inode, and then hashing it afterward. We
> call iunique with a max_reserved value of 1 to avoid collision with the root
> i
On Mon, Jan 08, 2007 at 03:47:13PM -0500, Jeff Layton wrote:
> This changes the superblock creation routines that call new_inode to take
> steps
> to avoid later collisions with other inodes that get created. I took the
> approach here of not hashing things unless is was strictly necessary, though
On Mon, Jan 08, 2007 at 03:47:07PM -0500, Jeff Layton wrote:
> When a 32-bit program that was not compiled with large file offsets does a
> stat and gets a st_ino value back that won't fit in the 32 bit field, glibc
> (correctly) generates an EOVERFLOW error. We can't do anything about fs's
> with
Jeff Layton wrote:
> Resending this set of patches to the list per Al Viro's request. I've gotten
> no comments so far, so I'll presume that denotes consent and just ask Andrew
> to merge them if I don't hear anything after this ;-).
>
> --[snip]-
>
> Since Joern mentioned that he thought
Erez Zadok wrote:
I didn't know about those patches, but yes, they do sound useful. I'm
curious who needed such functionality before and why. If someone can point
me to those patches, we can look into using them for Unionfs. Thanks.
I asked for it years ago, You can probably guess why :)
In message <[EMAIL PROTECTED]>, Jan Kara writes:
> > In message <[EMAIL PROTECTED]>, Jan Kara writes:
[...]
> > Jan, all of it is duable: we can downgrade the f/s to readonly, grab various
> > locks, search through various lists looking for open fd's and such, then
> > decide if to allow the mount
Other people are of the opinion that the invention of the symbolic link
was a huge mistake.
I guess I haven't heard that one. What is the argument that we were
better off without symbolic links?
Numerous security bugs in tar (extracting a specially crafted archive with
symlinks could overwri
On Wed, Jan 10, 2007 at 09:38:11AM -0800, Bryan Henderson wrote:
> >Other people are of the opinion that the invention of the symbolic link
> >was a huge mistake.
>
> I guess I haven't heard that one. What is the argument that we were
> better off without symbolic links?
I suppose http://www.cs
>Other people are of the opinion that the invention of the symbolic link
>was a huge mistake.
I guess I haven't heard that one. What is the argument that we were
better off without symbolic links?
--
Bryan Henderson San Jose California
IBM Almaden Research Center
>I did cp -rl his-tree my-tree (which completed
>quickly), edited the two files that needed to be patched, then did
>diff -urp his-tree my-tree, which also completed quickly, as diff knows
>that if two files have the same inode, they don't need to be opened.
>... download one tree from kernel.org,
> In message <[EMAIL PROTECTED]>, Jan Kara writes:
> > > In message <[EMAIL PROTECTED]>, Andrew Morton writes:
> > > > On Sun, 7 Jan 2007 23:12:53 -0500
> > > > "Josef 'Jeff' Sipek" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > +Modifying a Unionfs branch directly, while the union is mounted, is
>
Nicolas Williams wrote:
> On Thu, Jan 04, 2007 at 12:04:14PM +0200, Benny Halevy wrote:
>> I agree that the way the client implements its cache is out of the protocol
>> scope. But how do you interpret "correct behavior" in section 4.2.1?
>> "Clients MUST use filehandle comparisons only to improve
As a usage scenario, compile-tested only.
Replace fs/eventpoll.c with this code and see,
how your kernel crashes. Or works.
:)
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
asmlinkage long
On Wed, Jan 10, 2007 at 06:56:40AM -0500, Jeff Garzik ([EMAIL PROTECTED]) wrote:
> >It was there, but Andrew dropped it somewhere about take25 :)
>
> Probably because it was a moving target with a high rate of change,
> requiring time that Andrew did not have just to keep in sync and fix
> build
The two patches look good to me.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Evgeniy Polyakov wrote:
On Wed, Jan 10, 2007 at 06:11:26AM -0500, Jeff Garzik ([EMAIL PROTECTED]) wrote:
Once the rate of change slows, Andrew should IMO definitely pick this up.
There are _tons_ of ideas to implement with kevent - so if we want, rate
will not slow down. As you can see, from t
On Wed, Jan 10, 2007 at 06:11:26AM -0500, Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Once the rate of change slows, Andrew should IMO definitely pick this up.
There are _tons_ of ideas to implement with kevent - so if we want, rate
will not slow down. As you can see, from take26 I only send new
feat
Evgeniy Polyakov wrote:
Generic event handling mechanism.
Kevent is a generic subsytem which allows to handle event notifications.
It supports both level and edge triggered events. It is similar to
poll/epoll in some cases, but it is more scalable, it is faster and
allows to work with essentiall
Kevent based AIO (aio_sendfile()).
aio_sendfile() contains of two major parts: AIO state machine and page
processing code. The former is just a small subsystem, which allows to
queue callback for theirs invocation in process' context on behalf of
pool of kernel threads. It allows to queue cach
Generic event handling mechanism.
Kevent is a generic subsytem which allows to handle event notifications.
It supports both level and edge triggered events. It is similar to
poll/epoll in some cases, but it is more scalable, it is faster and
allows to work with essentially eny kind of events.
Ev
Description.
diff --git a/Documentation/kevent.txt b/Documentation/kevent.txt
new file mode 100644
index 000..325204f
--- /dev/null
+++ b/Documentation/kevent.txt
@@ -0,0 +1,259 @@
+Description.
+
+int kevent_init(struct kevent_ring *ring, unsigned int ring_size,
+ unsigned int flags)
28 matches
Mail list logo
