Re: [31/37] Large blocksize support: Core piece

On Wed, 20 Jun 2007, Bob Picco wrote: > > + if (size > (PAGE_SIZE << MAX_ORDER) || size < 512 || > > + !is_power_of_2(size)) > I think this should be: > if (size > (MAX_ORDER_NR_PAGES << PAGE_SHIFT) ... > or > if (size > (PAGE_SIZE <<

[RFC][PATCH 10/10] Online defrag command

- The defrag command. Usage is as follows: o Put the multiple files closer together. # e4defrag -r directory-name o Defrag for free space fragmentation. # e4defrag -f file-name o Defrag for a single file. # e4defrag file-name o Defrag for all files on ext4. # e4defrag devic

[RFC][PATCH 9/10] Fix bugs in multi-block allocation and locality-group

- Move lg_list to s_locality_dirty in ext4_lg_sync_single_group() to flush all of dirty inodes. - Fix ext4_mb_new_blocks() to return err value when defrag failed. Signed-off-by: Takashi Sato <[EMAIL PROTECTED]> Signed-off-by: Akira Fujita <[EMAIL PROTECTED]> --- diff -X Online-Defrag_linux-2.6.1

[RFC][PATCH 8/10] Release reserved block

- Release reserved blocks if defrag failed. Signed-off-by: Takashi Sato <[EMAIL PROTECTED]> Signed-off-by: Akira Fujita <[EMAIL PROTECTED]> --- diff -X Online-Defrag_linux-2.6.19-rc6-git/Documentation/dontdiff -upNr Online-Defrag_linux-2.6.19-rc6-git-BLOCK_RELEASE/fs/ext4/extents.c Online-Defrag

[RFC][PATCH 7/10] Reserve freed blocks

- Reserve the free blocks in the target area, not to be used by other process. Signed-off-by: Takashi Sato <[EMAIL PROTECTED]> Signed-off-by: Akira Fujita <[EMAIL PROTECTED]> --- diff -X Online-Defrag_linux-2.6.19-rc6-git/Documentation/dontdiff -upNr Online-Defrag_linux-2.6.19-rc6-git-RESERVE_B

[RFC][PATCH 6/10] Move files from target block group to other block group

- To make contiguous free blocks, move files from the target block group to other block group. Signed-off-by: Takashi Sato <[EMAIL PROTECTED]> Signed-off-by: Akira Fujita <[EMAIL PROTECTED]> --- diff -X Online-Defrag_linux-2.6.19-rc6-git/Documentation/dontdiff -upNr Online-Defrag_linux-2.6.19-

[RFC][PATCH 5/10] Get all extents information of specified inode number

- Get all extents information of specified inode number to calculate the combination of extents which should be moved to other block group. Signed-off-by: Takashi Sato <[EMAIL PROTECTED]> Signed-off-by: Akira Fujita <[EMAIL PROTECTED]> --- diff -X Online-Defrag_linux-2.6.19-rc6-git/Documentation

[RFC][PATCH 4/10] Get free blocks distribution of the target block group

- Get free blocks distribution of the target block group to know how many free blocks it has. Signed-off-by: Takashi Sato <[EMAIL PROTECTED]> Signed-off-by: Akira Fujita <[EMAIL PROTECTED]> --- diff -X Online-Defrag_linux-2.6.19-rc6-git/Documentation/dontdiff -upNr Online-Defrag_linux-2.6.19-rc

[RFC][PATCH 2/10] Move the file data to the new blocks

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]> Signed

[RFC][PATCH 3/10] Get block group information

- Get s_blocks_per_group and s_inodes_per_group of target filesystem. Signed-off-by: Takashi Sato <[EMAIL PROTECTED]> Signed-off-by: Akira Fujita <[EMAIL PROTECTED]> --- diff -X Online-Defrag_linux-2.6.19-rc6-git/Documentation/dontdiff -upNr linux-2.6.19-rc6-test1/fs/ext4/balloc.c Online-Defrag_

[RFC][PATCH 1/10] Allocate new contiguous blocks

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

[RFC][PATCH 0/10] ext4 online defrag (ver 0.5)

Hi all, I have updated my online defrag patchset for addition of a new function. This function is defragmentation for free space. If filesytem has insufficient contiguous free blocks, defrag tries to move other files to make sufficient space and reallocates the contiguous blocks for the target fil

Re: [BUG?]Set XIP mount option on ext2 bypass check.

I mount an ext2 fs , then remount it with xip option set. I get message below when do write operation in the fs. kernel BUG at fs/ext2/xip.c:21! invalid opcode: [#1] SMP last sysfs file: /class/net/eth0/carrier Modules linked in: ext2 autofs4 hidp rfcomm l2cap bluetooth sunrpc ipv6

Re: [31/37] Large blocksize support: Core piece

Christoph Lameter wrote:[Wed Jun 20 2007, 02:29:38PM EDT] > Provide an alternate definition for the page_cache_xxx(mapping, ...) > functions that can determine the current page size from the mapping > and generate the appropriate shifts, sizes and mask for the page cache > operations. Chang

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

* Karel Zak ([EMAIL PROTECTED]) wrote: > On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote: > > > > ... or, alternatively, add a subfield to the first field (which would > > entail escaping whatever separator we choose): > > > > /dev/md6 /export ext3 rw,data=ordered 0 0 > > /dev/m

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

H. Peter Anvin wrote: Chuck Lever wrote: The advantage is that it doesn't have strong user space dependencies on its format like /proc/mounts does. If you have NFS mount points, you will see that it includes a great deal of additional information about each mount. OK, I see now: device raidte

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

Chuck Lever wrote: > The advantage is that it doesn't have strong user space dependencies on > its format like /proc/mounts does. > > If you have NFS mount points, you will see that it includes a great deal > of additional information about each mount. OK, I see now: device raidtest:/export mount

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

On 20 Jun 2007, H. Peter Anvin verbalised: > Right now it is actually impossible to conclusively determine a > filesystem-relative path in the presence of bind (and possibly move) > mounts. This is highly desirable to be able to do in contexts that > involve non-Linux (or not-the-current-instance

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

H. Peter Anvin wrote: Chuck Lever wrote: To support NFS client performance statistics, I recently added /proc/self/mountstats. That might be a place to add details about --move and --bind mounts without changing the format of /proc/mounts. I just looked at /proc/self/mountstats; it seems to h

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

Dr. David Alan Gilbert wrote: > > What happens with the (sick) case of spaces in directory names? > Also is it really nicely defined that there is no way to put a space > in an option in any of the filesystems? I suppose someone > particularly sick could have a device node in a directory with a

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

Chuck Lever wrote: > To support NFS client performance statistics, I recently added > /proc/self/mountstats. That might be a place to add details about > --move and --bind mounts without changing the format of /proc/mounts. I just looked at /proc/self/mountstats; it seems to have no more informat

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

Karel Zak wrote: > > Yeah. How about include propagation trees to this file? > > mountpoint + ID + relative path + type + options + propagation-flag + > {peer,master}-mount-id > > / 0xa917800 / ext3 rw PRIVATE > /mnt 0xa917100 / ext3 rw SHARED peer:0xa917100 > /tmp 0xa917f00 /1 ext3 rw SLA

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

Al Viro wrote: On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote: ... or, alternatively, add a subfield to the first field (which would entail escaping whatever separator we choose): /dev/md6 /export ext3 rw,data=ordered 0 0 /dev/md6:/users/foo /home/foo ext3 rw,data=ordered 0 0 /d

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

On Wed, Jun 20, 2007 at 10:03:43PM +0100, Al Viro wrote: > On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote: > > ... or, alternatively, add a subfield to the first field (which would > > entail escaping whatever separator we choose): > > > > /dev/md6 /export ext3 rw,data=ordered 0 0

Re: [36/37] Large blocksize support for ext2

On Jun 20, 2007 14:27 -0700, Christoph Lameter wrote: > > > Hmmm... Actually there is nothing additional to be done after the earlier > > > cleanup of the macros. So just modify copyright. > > > > It is NOT possible to have 64kB blocksize on ext2/3/4 without some small > > changes to the director

[BUG?]Set XIP mount option on ext2 bypass check.

hi, all. xip mount option can be set on ext2 fs by using remount, even though the fs is used with a block device that does not support the direct_access block device operation or fs block size is not equal to PAGE_SIZE. Is this the expected behaviour ? Thanks in advance - Best Regards

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

Karel Zak wrote: > On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote: >> We could add a field to /proc/mounts to add this information: >> >> /dev/md6 /export ext3 rw,data=ordered 0 0 / >> /dev/md6 /home/foo ext3 rw,data=ordered 0 0 /users/foo >> /dev/md6 /home/bar ext3 rw,data=ordered

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote: > > We could add a field to /proc/mounts to add this information: > > /dev/md6 /export ext3 rw,data=ordered 0 0 / > /dev/md6 /home/foo ext3 rw,data=ordered 0 0 /users/foo > /dev/md6 /home/bar ext3 rw,data=ordered 0 0 /users/bar I p

Re: [34/37] Large blocksize support in ramfs

On Wed, 20 Jun 2007, Andreas Dilger wrote: > On Jun 20, 2007 11:29 -0700, [EMAIL PROTECTED] wrote: > > If you apply this patch and then you can f.e. try this: > > > > mount -tramfs -o10 none /media > > > @@ -164,10 +165,15 @@ static int ramfs_fill_super(struct super > > + if (options && *

Re: [36/37] Large blocksize support for ext2

On Wed, 20 Jun 2007, Andreas Dilger wrote: > On Jun 20, 2007 11:29 -0700, [EMAIL PROTECTED] wrote: > > This adds support for a block size of up to 64k on any platform. > > It enables the mounting filesystems that have a larger blocksize > > than the page size. > > Might have been good to CC the

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

Al Viro wrote: > On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote: >> ... or, alternatively, add a subfield to the first field (which would >> entail escaping whatever separator we choose): >> >> /dev/md6 /export ext3 rw,data=ordered 0 0 >> /dev/md6:/users/foo /home/foo ext3 rw,data=o

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

On Wed, Jun 20, 2007 at 01:57:33PM -0700, H. Peter Anvin wrote: > ... or, alternatively, add a subfield to the first field (which would > entail escaping whatever separator we choose): > > /dev/md6 /export ext3 rw,data=ordered 0 0 > /dev/md6:/users/foo /home/foo ext3 rw,data=ordered 0 0 > /dev/md6

Adding subroot information to /proc/mounts, or obtaining that through other means

Right now it is actually impossible to conclusively determine a filesystem-relative path in the presence of bind (and possibly move) mounts. This is highly desirable to be able to do in contexts that involve non-Linux (or not-the-current-instance-of-Linux) accesses to the filesystem, e.g. other fi

Re: [36/37] Large blocksize support for ext2

On Jun 20, 2007 11:29 -0700, [EMAIL PROTECTED] wrote: > This adds support for a block size of up to 64k on any platform. > It enables the mounting filesystems that have a larger blocksize > than the page size. Might have been good to CC the ext2/3/4 maintainers here? I definitely have been waiti

Re: [34/37] Large blocksize support in ramfs

On Jun 20, 2007 11:29 -0700, [EMAIL PROTECTED] wrote: > If you apply this patch and then you can f.e. try this: > > mount -tramfs -o10 none /media > @@ -164,10 +165,15 @@ static int ramfs_fill_super(struct super > + if (options && *options) > + order = simple_strtoul(option

[06/37] Use page_cache_xxx in mm/rmap.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/rmap.c |8 1 file changed, 4 insertions(+), 4 deletions(-) Index: linux-2.6.22-rc4-mm2/mm/rmap.c === --- linux-2.6.22-rc4-mm2.orig/mm/rmap.c 2007-06-14 10:35:4

[13/37] Use page_cache_xxx in mm/fadvise.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/fadvise.c |8 1 file changed, 4 insertions(+), 4 deletions(-) Index: vps/mm/fadvise.c === --- vps.orig/mm/fadvise.c 2007-06-04 17:57:25.0 -0700 +

[15/37] Use page_cache_xxx functions in fs/ext2

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/ext2/dir.c | 40 +++- 1 file changed, 23 insertions(+), 17 deletions(-) Index: linux-2.6.22-rc4-mm2/fs/ext2/dir.c === --- linux-2.6.22

[12/37] Use page_cache_xxx in mm/mpage.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/mpage.c | 28 1 file changed, 16 insertions(+), 12 deletions(-) Index: vps/fs/mpage.c === --- vps.orig/fs/mpage.c 2007-06-11 22:33:07.000

[08/37] Use page_cache_xxx in mm/migrate.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/migrate.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: vps/mm/migrate.c === --- vps.orig/mm/migrate.c 2007-06-11 15:56:37.0 -0700 +++ vps/m

[20/37] Fix PAGE SIZE assumption in miscellaneous places.

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- kernel/container.c |4 ++-- kernel/futex.c |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) Index: vps/kernel/futex.c === --- vps.orig/kernel/futex.c 20

[18/37] Use page_cache_xxx in fs/reiserfs

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/reiserfs/bitmap.c |7 ++- fs/reiserfs/file.c|5 +++-- fs/reiserfs/inode.c | 37 ++--- fs/reiserfs/ioctl.c |2 +- fs/reiserfs/stree.c |

[25/37] compound pages: vmstat support

Add support for compound pages so that inc_ and dec_xxx will increment the ZVCs by the number of pages of the compound page. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- include/linux/vmstat.h |5 ++--- mm/vmstat.c| 18 +- 2 files changed, 15 i

[23/37] compound pages: PageHead/PageTail instead of PageCompound

This patch enhances the handling of compound pages in the VM. It may also be important also for the antifrag patches that need to manage a set of higher order free pages and also for other uses of compound pages. For now it simplifies accounting for SLUB pages but the groundwork here is important

[21/37] Use page_cache_xxx in drivers/block/loop.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- drivers/block/loop.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) Index: linux-2.6.22-rc4-mm2/drivers/block/loop.c === --- linux-2.6.22-rc4-mm2.orig/d

[31/37] Large blocksize support: Core piece

Provide an alternate definition for the page_cache_xxx(mapping, ...) functions that can determine the current page size from the mapping and generate the appropriate shifts, sizes and mask for the page cache operations. Change the basic functions that allocate pages for the page cache to be able to

[34/37] Large blocksize support in ramfs

The simplest file system to use for larg blocksize support is ramfs. Add a mount parameter that specifies the page order of the pages that ramfs should use. Note that ramfs does not use the lower layers (buffer I/O etc) so this case is useful for initial testing of changes to large buffer size sup

[30/37] Add VM_BUG_ONs to check for correct page order

Before we start allowing different page orders we better get checkpoints in at various places in the VM. Checkpoints will help debugging whenever a wrong order page shows up in a mapping. This will be helpful for converting new filesystems to utilize larger pages. Signed-off-by: Christoph Lameter

[33/37] Large blocksize: Compound page zeroing and flushing

We may now have to zero and flush higher order pages. Implement clear_mapping_page and flush_mapping_page to do that job. Replace the flushing and clearing at some key locations for the pagecache. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/libfs.c |4 ++-- inclu

[37/37] Reiserfs: Fix up for mapping_set_gfp_mask

mapping_set_gfp_mask only works on order 0 page cache operations. Reiserfs can use 8k pages (order 1). Replace the mapping_set_gfp_mask with mapping_setup to make this work properly. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/reiserfs/xattr.c |3 ++- 1 file changed, 2 insert

[32/37] Readahead changes to support large blocksize.

Fix up readhead for large I/O operations. Only calculate the readahead until the 2M boundary then fall back to one page. Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> === --- i

[35/37] Large blocksize support in XFS

From: David Chinner <[EMAIL PROTECTED]> The only thing that needs to change to enable Large Block I/O is to remove the check for a too large blocksize ;-) Signed-off-by: Dave Chinner <[EMAIL PROTECTED]> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/xfs/xfs_mount.c | 13 -

[36/37] Large blocksize support for ext2

This adds support for a block size of up to 64k on any platform. It enables the mounting filesystems that have a larger blocksize than the page size. F.e. the following is possible on x86_64 and i386 that have only a 4k page size. mke2fs -b 16384 /dev/hdd2 mount /dev/hdd2 /media ls -l /me

[28/37] compound pages: Allow freeing of compound pages via pagevec

Allow the freeing of compound pages via pagevec. In release_pages() we currently special case for compound pages in order to be sure to always decrement the page count of the head page and not the tail page. However that redirection to the head page is only necessary for tail pages. So use PageTai

[29/37] Large blocksize support: Fix up reclaim counters

We now have to reclaim compound pages of arbitrary order. Adjust the counting in vmscan.c to could the number of base pages. Also change the active and inactive accounting to do the same. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- include/linux/mm_inline.h | 41

[27/37] compound pages: Allow use of get_page_unless_zero with compound pages

This will be needed by targeted slab reclaim in order to ensure that a compound page allocated by SLUB will not go away under us. It also may be needed if Mel starts to implement defragmentation. The moving of compound pages may require the establishment of a reference before the use of page migra

[26/37] compound pages: Use new compound vmstat functions in SLUB

Use the new dec/inc functions to simplify SLUB's accounting of pages. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/slub.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) Index: linux-2.6.22-rc4-mm2/mm/slub.c ==

[24/37] compound pages: Add new support functions

compound_pages(page)-> Determines base pages of a compound page compound_shift(page)-> Determine the page shift of a compound page compound_size(page) -> Determine the size of a compound page Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- include/linux/mm.h | 15 +++

[22/37] Use page_cache_xxx in drivers/block/rd.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- drivers/block/rd.c |8 1 file changed, 4 insertions(+), 4 deletions(-) Index: vps/drivers/block/rd.c === --- vps.orig/drivers/block/rd.c 2007-06-14 21:49:09.0

[17/37] Use page_cache_xxx in fs/ext4

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/ext4/dir.c |3 ++- fs/ext4/inode.c | 34 +- fs/ext4/writeback.c | 35 +++ 3 files changed, 38 insertions(+), 34 deletions(-) Index: linux-2.6.22-rc4-mm2/f

[16/37] Use page_cache_xxx in fs/ext3

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/ext3/dir.c |3 ++- fs/ext3/inode.c | 36 ++-- 2 files changed, 20 insertions(+), 19 deletions(-) Index: linux-2.6.22-rc4-mm2/fs/ext3/dir.c =

[19/37] Use page_cache_xxx for fs/xfs

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/xfs/linux-2.6/xfs_aops.c | 55 +++- fs/xfs/linux-2.6/xfs_lrw.c |4 +-- 2 files changed, 31 insertions(+), 28 deletions(-) Index: linux-2.6.22-rc4-mm2/fs/xfs/linux-2.6/xfs_aops.c ===

[05/37] Use page_cache_xxx in mm/truncate.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/truncate.c | 35 ++- 1 file changed, 18 insertions(+), 17 deletions(-) Index: vps/mm/truncate.c === --- vps.orig/mm/truncate.c 2007-0

[11/37] Use page_cache_xxx in fs/buffer.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/buffer.c | 99 +--- 1 file changed, 56 insertions(+), 43 deletions(-) Index: vps/fs/buffer.c === --- vps.orig/fs/b

[09/37] Use page_cache_xxx in fs/libfs.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/libfs.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) Index: vps/fs/libfs.c === --- vps.orig/fs/libfs.c 2007-06-11 21:39:09.0 -0700 ++

[10/37] Use page_cache_xxx in fs/sync.

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/sync.c |8 1 file changed, 4 insertions(+), 4 deletions(-) Index: vps/fs/sync.c === --- vps.orig/fs/sync.c 2007-06-04 17:57:25.0 -0700 +++ vps/fs/sync

[14/37] Use page_cache_xxx in fs/splice.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- fs/splice.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) Index: vps/fs/splice.c === --- vps.orig/fs/splice.c2007-06-09 22:18:02.00

[07/37] Use page_cache_xxx in mm/filemap_xip.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/filemap_xip.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) Index: vps/mm/filemap_xip.c === --- vps.orig/mm/filemap_xip.c 2007-06

[02/37] Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user

Simplify page cache zeroing of segments of pages through 3 functions zero_user_segments(page, start1, end1, start2, end2) Zeros two segments of the page. It takes the position where to start and end the zeroing which avoids length calculations. zero_user_segment(page, start, end)

[00/37] Large Blocksize Support V4

V3->V4 - It is possible to transparently make filesystems support larger blocksizes by simply allowing larger blocksizes in set_blocksize. Remove all special modifications for mmap etc from the filesystems. This now makes 3 disk based filesystems that can use larger blocks (reiser, ext2, xf

[03/37] Use page_cache_xxx function in mm/filemap.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/filemap.c | 76 +-- 1 file changed, 38 insertions(+), 38 deletions(-) Index: vps/mm/filemap.c === --- vps.orig/mm/

[01/37] Define functions for page cache handling

We use the macros PAGE_CACHE_SIZE PAGE_CACHE_SHIFT PAGE_CACHE_MASK and PAGE_CACHE_ALIGN in various places in the kernel. Many times common operations like calculating the offset or the index are coded using shifts and adds. This patch provides inline function to get the calculations accomplished in

[04/37] Use page_cache_xxx in mm/page-writeback.c

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/page-writeback.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Index: vps/mm/page-writeback.c === --- vps.orig/mm/page-writeback.c2007-06-07 17:01:

Re: paid work: vfat symlinks, attributes and special files

> If you are willing to develop requested changes, > let me know please, I'll wait till 19th of January for answers > and then I'll post a message to the list who will do it > (if somebody is found). So it seems nobody is interested. Never mind, I give up. Thank you anyway :) Tomas M - To unsub

Re: [RFC PATCH 4/4] Directory listing support for union mounted directories.

On Wed, 2007-06-20 at 18:02 +0100, Christoph Hellwig wrote: > On Wed, Jun 20, 2007 at 10:22:28AM -0400, Trond Myklebust wrote: > > No it shouldn't. The struct file contains other stateful information > > from the open() call (such as authentication info) that needs to be > > passed into readdir. >

Re: Versioning file system

Bryan Henderson wrote: The directory is quite visible with a standard 'ls -a'. Instead, they simply mark it as a separate volume/filesystem: i.e. the fsid differs when you call stat(). The whole thing ends up acting rather like our bind mounts. Hmm. So it breaks user space quite a bit. By bre

Re: Versioning file system

Bryan Henderson wrote: >> The directory is quite visible with a standard 'ls -a'. Instead, >> they simply mark it as a separate volume/filesystem: i.e. the fsid >> differs when you call stat(). The whole thing ends up acting rather like >> our bind mounts. > > Hmm. So it breaks user space quite a

Re: Versioning file system

>The directory is quite visible with a standard 'ls -a'. Instead, >they simply mark it as a separate volume/filesystem: i.e. the fsid >differs when you call stat(). The whole thing ends up acting rather like >our bind mounts. Hmm. So it breaks user space quite a bit. By break, I mean uses that

Re: [RFC PATCH 4/4] Directory listing support for union mounted directories.

On Wed, Jun 20, 2007 at 10:22:28AM -0400, Trond Myklebust wrote: > No it shouldn't. The struct file contains other stateful information > from the open() call (such as authentication info) that needs to be > passed into readdir. Which is exactly that problem this tries to solve. Once you have uni

Re: [RFC PATCH 4/4] Directory listing support for union mounted directories.

On Wed, 2007-06-20 at 13:09 +0100, Christoph Hellwig wrote: > On Wed, Jun 20, 2007 at 11:24:18AM +0530, Bharata B Rao wrote: > > From: Bharata B Rao <[EMAIL PROTECTED]> > > Subject: Directory listing support for union mounted directories. > > > > Modifies readdir()/getdents() to support union moun

Re: [RFC PATCH 4/4] Directory listing support for union mounted directories.

On Wed, Jun 20, 2007 at 11:24:18AM +0530, Bharata B Rao wrote: > From: Bharata B Rao <[EMAIL PROTECTED]> > Subject: Directory listing support for union mounted directories. > > Modifies readdir()/getdents() to support union mounted directories. > > This patch adds support to readdir()/getdents()

Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS

On Mittwoch, 20. Juni 2007, Vladislav Bolkhovitin wrote: > Philipp Matthias Hahn wrote: > I would also suggest one more feature: support for block level > de-duplication. I mean: > So, seems ever for file based de-duplication some support from the FS, > including some kind of ability for di

Re: [RFC PATCH 1/4] Union mount documentation.

On 6/20/07, Jan Blunck <[EMAIL PROTECTED]> wrote: On Wed, 20 Jun 2007 11:21:57 +0530, Bharata B Rao wrote: Well done. I like your approach much more than the simple chaining of dentries. When I told you about the idea of maintaining a list of objects I always though about one big structure for

Re: [RFC PATCH 3/4] Lookup changes to support union mount.

On 6/20/07, Jan Blunck <[EMAIL PROTECTED]> wrote: On Wed, 20 Jun 2007 11:23:26 +0530, Bharata B Rao wrote: > +/* > + * Looks for the given @name in dcache by walking through all the layers > + * of the union stack, starting from the top. > + * FIXME: If we don't find the dentry in a upper layer,

Re: [RFC PATCH 2/4] Mount changes to support union mount.

(replying from a different ID as you didn't copy me on reply) On 6/20/07, Jan Blunck <[EMAIL PROTECTED]> wrote: On Wed, 20 Jun 2007 11:22:41 +0530, Bharata B Rao wrote: > +/* > + * When propagating mount events to peer group, this is called under > + * vfsmount_lock. Hence using GFP_ATOMIC for

Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS

Philipp Matthias Hahn wrote: I would also suggest one more feature: support for block level de-duplication. I mean: ... That would be very usable feature, which in most cases would allow to shrink occupied disk space on 50-90%. Have you references for this number? In my experience one gets

Re: Versioning file system

On Tue, 2007-06-19 at 20:12 +0100, Jack Stone wrote: > H. Peter Anvin wrote: > > Chris Snook wrote: > >> I pointed out NetApp's .snapshot directories because that's a method > >> that uses legal path character, but doesn't break anything. With this > >> method, userspace tools will have to be taug

Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS

[EMAIL PROTECTED] wrote: > 3. De-de-duplicate blocks on disk, i.e. copy them on write > > I suppose that de-duplication itself would be done by some user space > process that would scan files, determine blocks with the same data and > then de-duplicate them by using syscall or IOCTL (2). > > Th

Re: [RFC PATCH 1/4] Union mount documentation.

On Wed, 20 Jun 2007 11:21:57 +0530, Bharata B Rao wrote: > +4. Union stack: building and traversal > +-- +Union stack needs to be built > from two places: during an explicit union +mount (or mount propagation) > and during the lookup of a directory that +appears

Re: Versioning file system

On Mittwoch, 20. Juni 2007, H. Peter Anvin wrote: > Alan Cox wrote: > > POSIX is very > > clear about what is acceptable as magic in a pathname, and the unix spec > > even more so. The NetApp approach recognizes two important things > > > > 1. Old version access is the oddity not the norm > > 2.