Kevent based AIO (aio_sendfile()/aio_sendfile_path()).
aio_sendfile()/aio_sendfile_path() 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
Description.
diff --git a/Documentation/kevent.txt b/Documentation/kevent.txt
new file mode 100644
index 000..87a1ba9
--- /dev/null
+++ b/Documentation/kevent.txt
@@ -0,0 +1,268 @@
+Description.
+
+int kevent_init(struct kevent_ring *ring, unsigned int ring_size,
+ unsigned int flags)
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
On Jan 16 2007 18:03, Jason Lunz wrote:
>yes. I'm using debian etch initramfs-tools. After the above mount
>sequence, the unionfs becomes root via:
>
> mkdir ${rootmnt}/cow ${rootmnt}/os
> mount -n -o move /cow ${rootmnt}/cow
> mount -n -o move /os ${rootmnt}/os
>
> mount -
On Tuesday, 16. January 2007 06:37, Nate Diller wrote:
> On 1/15/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > On Mon, Jan 15, 2007 at 05:54:50PM -0800, Nate Diller wrote:
> > > Convert code using iocb->ki_left to use the more generic iov_length()
> > > call.
> >
> > No way. We need to red
On Sat, Jan 13, 2007 at 01:48:04AM -0500, Josef Sipek wrote:
> > The root filesystem is a union of a ro squashfs and a rw tmpfs.
> > The initramfs sets it up something like this:
> >
> > mkdir /os
> > mount -r -t squashfs /dev/ram0 /os
> >
> > mkdir /cow
> > mount -t tmpfs -o mode=0755 tmpfs /cow
On Tue, Jan 16, 2007 at 12:21:34PM -0700, Andreas Dilger wrote:
> On Jan 16, 2007 21:03 +0900, [EMAIL PROTECTED] wrote:
> > 2. The new entry "goal" is added on ext4_ext_defrag_data structure
> >which is passed to existing ioctl(EXT4_IOC_DEFRAG)
> >as the argument. The kernel starts search
On Jan 16, 2007 21:03 +0900, [EMAIL PROTECTED] wrote:
> 1. Add new ioctl(EXT4_IOC_DEFRAG) which returns the first physical
>block number of the specified file. With this ioctl, a command
>gets the specified directory's.
Maybe I don't understand, but how is this different from the long-ti
On Tue, 2007-01-16 at 18:36 +0100, Peter Zijlstra wrote:
> buf, bytes);
> > @@ -1935,10 +1922,9 @@ generic_file_buffered_write(struct kiocb
> > cur_iov, iov_offset, bytes);
> > flush_dcache
This patch makes it so that simple_fill_super and get_sb_pseudo assign their
root inodes to be number 1. It also fixes up a couple of callers of
simple_fill_super that were passing in files arrays that had an index at
number 1, and adds a warning for any caller that sends in such an array.
It woul
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
inode. Since the inode is now hashed, we need to take care that we en
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 larger permanent inode numbers, but when we generate them on the fly,
Since there's been no further comment on these patches, I'm going to resend
them one more time and ask Andrew to commit these to -mm. Once they're in
place there, I'll start working on and sending out follow-on patches to
clean up the other filesystems and ensure that they properly hash their
inode
On Tuesday 16 January 2007 1:13 am, Nate Diller wrote:
> On 1/15/07, David Brownell <[EMAIL PROTECTED]> wrote:
> > What's needed is an async, non-sleeeping, interface ... with I/O
> > overlap. That's antithetical to using read()/write() calls, so
> > your proposed approach couldn't possibly work.
On Sat, 2007-01-13 at 04:25 +0100, Nick Piggin wrote:
> If prepare_write fails with AOP_TRUNCATED_PAGE, or if commit_write fails, then
> we may have failed the write operation despite prepare_write having
> instantiated blocks past i_size. Fix this, and consolidate the trimming into
> one place.
>
The defrag command. Usage is as follows:
o Put the multiple files closer together.
# e4defrag -r directory-name
o Defrag for a single file.
# e4defrag file-name
o Defrag for all files on ext4.
# e4defrag device-name
Signed-off-by: Takashi Sato <[EMAIL PROTECTED]>
---
/*
* e4defrag, ext4 fi
Move the blocks on the temporary inode to the original inode
by a page.
1. Read the file data from the old blocks to the page
2. Move the block on the temporary inode to the original inode
3. Write the file data on the page into the new blocks
Signed-off-by: Takashi Sato <[EMAIL PROTECTED]>
---
di
Search contiguous free blocks with Alex's mutil-block allocation
and allocate them for the temporary inode.
This patch applies on top of Alex's patches.
"[RFC] delayed allocation, mballoc, etc"
http://marc.theaimsgroup.com/?l=linux-ext4&m=116493228301966&w=2
Signed-off-by: Takashi Sato <[EMAIL PR
Hi
I have modified the online defrag patches to add new function which can
put the multiple files closer together. It is effective for
an application which reads many small files. Our goal is to reduce
OS booting time by putting the files, read during OS booting,
closer together.
Implementation
On Mon, Jan 15, 2007 at 09:44:27PM -0800, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> > The sendmsg and recvmsg socket operations take a kiocb pointer, but none of
> > the functions actually use it. There's really no need even theoretically,
> > it's really quite ugly having it there at all.
On 1/15/07, David Brownell <[EMAIL PROTECTED]> wrote:
On Monday 15 January 2007 5:54 pm, Nate Diller wrote:
> --- a/drivers/usb/gadget/inode.c 2007-01-12 14:42:29.0 -0800
> +++ b/drivers/usb/gadget/inode.c 2007-01-12 14:25:34.0 -0800
> @@ -559,35 +559,32 @@ static int ep
On 1/15/07, David Brownell <[EMAIL PROTECTED]> wrote:
On Monday 15 January 2007 5:54 pm, Nate Diller wrote:
> This removes the aio implementation from the usb gadget file system.
NAK. I see a deep mis-understanding here.
> Aside
> from making very creative (!) use of the aio retry path, it ca
On Monday 15 January 2007 8:25 pm, Nate Diller wrote:
> I don't think we should be waiting on sync I/O
> at the *top* of the call stack, like with wait_on_sync_kiocb(), I'd
> say the best place to wait is at the *bottom*, down in the I/O
> scheduler.
Erm ... *what* I/O scheduler? These I/O requ
23 matches
Mail list logo
