On Fri, Jan 05 2007, Suparna Bhattacharya 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 Morton wrote:
> > > > On Thu, 28 De
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 Morton wrote:
> > > On Thu, 28 Dec 2006 13:53:08 +0530
> > > Suparna Bhattacharya <[EMAIL PROT
As glibc POSIX AIO switches over completely to using native AIO it needs
basic AIO support for various file types - including sockets, pipes etc.
Since userland will no longer be simulating asynchronous behaviour
with threads, it expects the underlying implementation to be asynchronous.
Which is s
Suparna Bhattacharya wrote:
On Thu, Jan 04, 2007 at 05:50:11PM +1100, Nick Piggin wrote:
OK, but I think that after IO submission, you do not run sync_page to
unplug the block device, like the normal IO path would (via lock_page,
before the explicit plug patches).
In the buffered AIO case,
This fixes a bug found by the fsfuzzer tool.
http://projects.info-pull.com/mokb/MOKB-15-11-2006.html
A NULL was not an acceptable error condition expected
by any of the gfs2_lookupi callers.
--
Russell Cattelan <[EMAIL PROTECTED]>
Change gfs2_lookupi to either return an inode or an error.
None o
On Thu, Jan 04, 2007 at 07:47:34PM -0500, Shaya Potter wrote:
> yes, you're writing a stackable file system (the cs.sunysb gives that
> away) and have run a lookup_one_len() on a nfs mounted file system and
> that means nd is null.
>
> Erez's group is trying to fix that situation so the intents ca
yes, you're writing a stackable file system (the cs.sunysb gives that
away) and have run a lookup_one_len() on a nfs mounted file system and
that means nd is null.
Erez's group is trying to fix that situation so the intents can be
passed correctly.
On Thu, 2007-01-04 at 19:00 -0500, Chaitanya Pat
generic_write_checks() are done in the submission path, not
repeated during
retries, so such types of checks are not intended to run in the aio
thread.
Ah, I see, I was missing the short-cut which avoids re-running parts
of the write path if we're in a retry.
if (!is_sync_kiocb(io
Hello everyone,
In the function nfs_lookup in nfs/dir.c , the following line (line # 926):
error = nfs_reval_fsid(nd->mnt, dir, &fhandle, &fattr);
uses `nd' without having checked if it is NULL.
Is this correct?
This is in kernel version 2.6.19.1
Can someone check this ?
Thanks,
Chaitanya
Hi!
> > > High probability is all you have. Cosmic radiation hitting your
> > > computer will more likly cause problems, than colliding 64bit inode
> > > numbers ;)
> >
> > Some of us have machines designed to cope with cosmic rays, and would be
> > unimpressed with a decrease in reliability.
>
On 1/4/07, Dave Kleikamp <[EMAIL PROTECTED]> wrote:
On Thu, 2007-01-04 at 12:34 +0100, Jens Nie wrote:
> I think i found a bug in the ext3 filesystem. It deals with
> dereferencing symlinks. I have installed a fresh openSUSE 10.2 on an
> ext3 filesystem.
No, it seems to be a bug in the coreutil
On Tue 2007-01-02 16:18:40, Kent Overstreet wrote:
> >> Any details?
> >
> >Well, one path I tried I couldn't help but post a blog
> >entry about
> >for my friends. I'm not sure it's the direction I'll
> >take with linux-
> >kernel, but the fundamentals are there: the api should
> >be the
> >s
On Thu, 2007-01-04 at 12:34 +0100, Jens Nie wrote:
> Hello List.
>
> I think i found a bug in the ext3 filesystem. It deals with
> dereferencing symlinks. I have installed a fresh openSUSE 10.2 on an
> ext3 filesystem.
> After that i wanted to include some selfmade LaTeX-classes by creating
> a
Bryan Henderson wrote:
"Clients MUST use filehandle comparisons only to improve
performance, not for correct behavior. All clients need to
be prepared for situations in which it cannot be determined
whether two filehandles denote the same object and in such
cases, avoid making invalid assumptions
>>> "Clients MUST use filehandle comparisons only to improve
>>> performance, not for correct behavior. All clients need to
>>> be prepared for situations in which it cannot be determined
>>> whether two filehandles denote the same object and in such
>>> cases, avoid making invalid assumptions whic
On Thu, Jan 04, 2007 at 12:34:16PM +0100, Jens Nie wrote:
>
> I think i found a bug in the ext3 filesystem. It deals with
> dereferencing symlinks. I have installed a fresh openSUSE 10.2 on an
> ext3 filesystem.
> After that i wanted to include some selfmade LaTeX-classes by creating
> a symlink
On Thu, Jan 04 2007, Andrew Morton wrote:
> > Please let know how you want this fixed up.
> >
> > >From what I can tell the comments in the unplug patches seem to say that
> > it needs more work and testing, so perhaps a separate fixup patch may be
> > a better idea rather than make the fsaio patch
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 Morton wrote:
> > On Thu, 28 Dec 2006 13:53:08 +0530
> > Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
> >
> > > This patchset implements changes to make filesyst
Hi all,
While there are still some issues the number of patches is hard
to manage so I'm consolidating again.
Known issues
Quoted strings in the master map are not yet handled.
This may be delayed unlil the first bug fix release following
the initial release.
There will always be b
Mikulas Patocka writes:
> > > BTW. How does ReiserFS find that a given inode number (or object ID in
> > > ReiserFS terminology) is free before assigning it to new file/directory?
> >
> > reiserfs v3 has an extent map of free object identifiers in
> > super-block.
>
> Inode free space can h
Hello List.
I think i found a bug in the ext3 filesystem. It deals with
dereferencing symlinks. I have installed a fresh openSUSE 10.2 on an
ext3 filesystem.
After that i wanted to include some selfmade LaTeX-classes by creating
a symlink within /usr/share/texmf/tex/latex to the directory
conta
On Thu, Jan 04, 2007 at 05:50:11PM +1100, Nick Piggin wrote:
> Suparna Bhattacharya wrote:
> >On Thu, Jan 04, 2007 at 04:51:58PM +1100, Nick Piggin wrote:
>
> >>So long as AIO threads do the same, there would be no problem (plugging
> >>is optional, of course).
> >
> >
> >Yup, the AIO threads run
On Thu, 2007-01-04 at 12:04 +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 performance, not
> for correct beh
Trond Myklebust wrote:
> On Wed, 2007-01-03 at 14:35 +0200, Benny Halevy wrote:
>> I sincerely expect you or anybody else for this matter to try to provide
>> feedback and object to the protocol specification in case they disagree
>> with it (or think it's ambiguous or self contradicting) rather t
listio support through a system call(lio_submit)
This builds on the infrastructure provided by Sebastien's AIO
completion signal notification and listio patches to provide listio
support via a new system call.
long lio_submit(aio_context_t ctx_id, int mode, long nr,
struct iocb __
AIO completion signal notification
The current 2.6 kernel does not support notification of user space via
an RT signal upon an asynchronous IO completion. The POSIX specification
states that when an AIO request completes, a signal can be delivered to
the application as noti
Make good_sigevent() non-static
Move good_sigevent() from posix-timers.c to signal.c where it belongs,
and make it non-static so that it can be used by other subsystems.
From: Sébastien Dugué <[EMAIL PROTECTED]>
Move good_sigevent() from posix-timers.c to signal.c where
Fix the double inclusion of linux/uio.h in linux/aio.h
From: Sébastien Dugué <[EMAIL PROTECTED]>
Fix the double inclusion of linux/uio.h in linux/aio.h
Signed-off-by: Sébastien Dugué <[EMAIL PROTECTED]>
Signed-off-by: Bharata B Rao <[EMAIL PROTECTED]>
---
include/linux/aio.h |1 -
1 f
compat_sys_io_submit() cleanup
Cleanup compat_sys_io_submit by duplicating some of the native syscall
logic in the compat layer and directly calling io_submit_one() instead
of fooling the syscall into thinking it is called from a native 64-bit
caller.
This eliminates:
- t
Hi
Here is a repost of Sebastien's AIO completion signal notification v4
patches along with the syscall based listio support patch. The goal
of this patchset is to improve the POSIX AIO support in the kernel.
While the 1st 4 patches provide the AIO completion signal notification
suppo
On Wed, 2007-01-03 at 14:35 +0200, Benny Halevy wrote:
> I sincerely expect you or anybody else for this matter to try to provide
> feedback and object to the protocol specification in case they disagree
> with it (or think it's ambiguous or self contradicting) rather than ignoring
> it and impleme
31 matches
Mail list logo
