On Wed, Dec 27, 2006 at 09:08:56PM +0530, Suparna Bhattacharya wrote:
> (2) Most of these other applications need the ability to process both
> network events (epoll) and disk file AIO in the same loop. With POSIX AIO
> they could at least sort of do this using signals (yeah, and all
> ass
On Tue, Jan 02, 2007 at 03:56:09PM -0800, Zach Brown wrote:
> Sorry for the delay, I'm finally back from the holiday break :)
Welcome back !
>
> >(1) The filesystem AIO patchset, attempts to address one part of
> >the problem
> >which is to make regular file IO, (without O_DIRECT)
> >asynchr
> 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
syscall interface, and there should be no difference between sync and
async behav
Sorry for the delay, I'm finally back from the holiday break :)
(1) The filesystem AIO patchset, attempts to address one part of
the problem
which is to make regular file IO, (without O_DIRECT)
asynchronous (mainly
the case of reads of uncached or partially cached files, and
O_SYNC
On Wed, 3 Jan 2007, Trond Myklebust wrote:
On Sat, 2006-12-30 at 02:04 +0100, Mikulas Patocka wrote:
On Fri, 29 Dec 2006, Trond Myklebust wrote:
On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
Why don't you rip off the support for colliding inode number from the
kernel at all (i.e
On Sun, 2006-12-31 at 16:19 -0500, Halevy, Benny wrote:
> Even for NFSv3 (that doesn't have the unique_handles attribute I think
> that the linux nfs client can do a better job. If you'd have a filehandle
> cache that points at inodes you could maintain a many to one relationship
> from multiple
On Sun, 2006-12-31 at 16:25 -0500, Halevy, Benny wrote:
> Trond Myklebust wrote:
> >
> > On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote:
> > > Mikulas Patocka wrote:
> >
> > > >BTW. how does (or how should?) NFS client deal with cache coherency if
> > > >filehandles for the same file di
On Sun, 2006-12-31 at 16:19 -0500, Halevy, Benny wrote:
> Trond Myklebust wrote:
> >
> > On Thu, 2006-12-28 at 17:12 +0200, Benny Halevy wrote:
> >
> > > As an example, some file systems encode hint information into the
> > > filehandle
> > > and the hints may change over time, another example
On Sat, 2006-12-30 at 02:04 +0100, Mikulas Patocka wrote:
>
> On Fri, 29 Dec 2006, Trond Myklebust wrote:
>
> > On Thu, 2006-12-28 at 19:14 +0100, Mikulas Patocka wrote:
> >> Why don't you rip off the support for colliding inode number from the
> >> kernel at all (i.e. remove iget5_locked)?
> >>
On 12/28/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
[ I'm only subscribed to linux-fsdevel@ from above Cc list, please keep this
list in Cc: for AIO related stuff. ]
On Wed, Dec 27, 2006 at 04:25:30PM +, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
> (1) note that there is another prob
Certainly, but tar isn't going to remember all the inode numbers.
Even if you solve the storage requirements (not impossible) it would
have to do (4e9^2)/2=8e18 comparisons, which computers don't have
enough CPU power just yet.
It is remembering all inode numbers with nlink > 1 and many other to
> > Certainly, but tar isn't going to remember all the inode numbers.
> > Even if you solve the storage requirements (not impossible) it would
> > have to do (4e9^2)/2=8e18 comparisons, which computers don't have
> > enough CPU power just yet.
>
> It is remembering all inode numbers with nlink > 1
On Tue, 2 Jan 2007, Miklos Szeredi wrote:
It seems like the posix idea of unique doesn't
hold water for modern file systems
are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
and if so, why don't we fix *THAT* instead
Hmm, sometimes you can't fix
> > > >> It seems like the posix idea of unique doesn't
> > > >> hold water for modern file systems
> > > >
> > > > are you really sure?
> > >
> > > Well Jan's example was of Coda that uses 128-bit internal file ids.
> > >
> > > > and if so, why don't we fix *THAT* instead
> > >
> > > Hmm, so
Hi!
> > >> It seems like the posix idea of unique doesn't
> > >> hold water for modern file systems
> > >
> > > are you really sure?
> >
> > Well Jan's example was of Coda that uses 128-bit internal file ids.
> >
> > > and if so, why don't we fix *THAT* instead
> >
> > Hmm, sometimes you can
On Thu, Dec 28, 2006 at 08:48:30PM +0530, Suparna Bhattacharya wrote:
> Yes, we can do that -- how about aio_restarted() as an alternate name ?
Sounds fine to me.
> > Pluse possible naming updates discussed in the last mail. Also do we
> > really need to pass current->io_wait here? Isn't the wa
On Thu, Dec 28, 2006 at 08:17:17PM +0530, Suparna Bhattacharya wrote:
> I am really bad with names :( I tried using the _wq suffixes earlier and
> that seemed confusing to some, but if no one else objects I'm happy to use
> that. I thought aio_lock_page() might be misleading because it is
> synchr
17 matches
Mail list logo
