+ ext4-copy-i_flags-to-inode-flags-on-write.patch added to -mm tree

2007-04-20 Thread akpm
The patch titled ext4: copy i_flags to inode flags on write has been added to the -mm tree. Its filename is ext4-copy-i_flags-to-inode-flags-on-write.patch *** Remember to use Documentation/SubmitChecklist when testing your code *** See

+ ext3-copy-i_flags-to-inode-flags-on-write.patch added to -mm tree

2007-04-20 Thread akpm
The patch titled ext3: copy i_flags to inode flags on write has been added to the -mm tree. Its filename is ext3-copy-i_flags-to-inode-flags-on-write.patch *** Remember to use Documentation/SubmitChecklist when testing your code *** See

Re: [PATCH] Copy i_flags to ext3 inode flags on write (version 2)

2007-04-20 Thread Andrew Morton
On Tue, 17 Apr 2007 12:38:55 +0200 Jan Kara [EMAIL PROTECTED] wrote: attached is a second version of a patch that stores inode flags such as S_IMMUTABLE, S_APPEND, etc. from i_flags to EXT3_I(inode)-i_flags when inode is written to disk. The same thing is done on GETFLAGS ioctl. Quota

Re: [PATCH] e2fsprogs - e2fsck pass1c does extra work if root dir has shared blocks

2007-04-20 Thread Theodore Tso
On Tue, Apr 10, 2007 at 03:39:56PM -0700, Jim Garlick wrote: Another small bug I think: if the root directory contains shared blocks, e2fsck pass1c search_dirent_proc() will be looking for one more containing directory than it will ever find, and thus loses an opportunity to terminate

Re: [PATCH] e2fsprogs: Offsets of EAs in inode need not be sorted

2007-04-20 Thread Kalpak Shah
On Fri, 2007-04-20 at 08:38 -0400, Theodore Tso wrote: On Thu, Apr 19, 2007 at 05:35:36PM +0530, Kalpak Shah wrote: Hi, This patch removes a code snippet from check_ea_in_inode() in pass1 which checks if the EA values in the inode are sorted or not. The comments in fs/ext*/xattr.c

Re: Interface for the new fallocate() system call

2007-04-20 Thread Jakub Jelinek
On Fri, Apr 20, 2007 at 07:21:46PM +0530, Amit K. Arora wrote: Ok. In this case we may have to consider following things: 1) Obviously, for this glibc will have to call fallocate() syscall with different arguments on s390, than other archs. I think this should be doable and should not be an

Re: [PATCH] e2fsprogs: Offsets of EAs in inode need not be sorted

2007-04-20 Thread Theodore Tso
On Thu, Apr 19, 2007 at 05:35:36PM +0530, Kalpak Shah wrote: Hi, This patch removes a code snippet from check_ea_in_inode() in pass1 which checks if the EA values in the inode are sorted or not. The comments in fs/ext*/xattr.c state that the EA values in the external EA block are sorted but

Re: Interface for the new fallocate() system call

2007-04-20 Thread Amit K. Arora
On Wed, Apr 18, 2007 at 07:06:00AM -0600, Andreas Dilger wrote: On Apr 17, 2007 18:25 +0530, Amit K. Arora wrote: On Fri, Mar 30, 2007 at 02:14:17AM -0500, Jakub Jelinek wrote: Wouldn't int fallocate(loff_t offset, loff_t len, int fd, int mode) work on both s390 and ppc/arm? glibc

[PATCH] fix ext2 allocator overflows above 31 bit blocks

2007-04-20 Thread Eric Sandeen
If ext3 can do 16T, ext2 probably should be able to as well. There are still int block containers in the block allocation path that need to be fixed up. Perhaps ext2 should get the ext2_fsblk_t/ext2_grpblk_t treatment as ext3 did, for clarity... Signed-off-by: Eric Sandeen [EMAIL PROTECTED]

Re: [PATCH] e2fsprogs: Offsets of EAs in inode need not be sorted

2007-04-20 Thread Kalpak Shah
On Fri, 2007-04-20 at 10:10 -0400, Theodore Tso wrote: On Fri, Apr 20, 2007 at 06:35:41PM +0530, Kalpak Shah wrote: I saw this problem when I was running a script which created a random number of EAs for a file of random sizes. If you mount the image I have given, all the EAs are

Re: [PATCH] fix up lazy_bg bitmap initialization at mkfs time

2007-04-20 Thread Andreas Dilger
On Apr 20, 2007 09:57 -0500, Eric Sandeen wrote: Anyway, how about something like this for calculating journal size in the face of lazy_bg. I know the last group may be smaller... but I figure this is just a heuristic anyway. Signed-off-by: Eric Sandeen [EMAIL PROTECTED] Index:

Re: [PATCH] Check for error returned by kthread_create on creating journal thread

2007-04-20 Thread Andrew Morton
On Mon, 16 Apr 2007 11:41:14 +0400 Pavel Emelianov [EMAIL PROTECTED] wrote: If the thread failed to create the subsequent wait_event will hang forever. This is likely to happen if kernel hits max_threads limit. Will be critical for virtualization systems that limit the number of tasks

Re: [PATCH] fix ext2 allocator overflows above 31 bit blocks

2007-04-20 Thread Andreas Dilger
On Apr 20, 2007 12:10 -0500, Eric Sandeen wrote: If ext3 can do 16T, ext2 probably should be able to as well. There are still int block containers in the block allocation path that need to be fixed up. Yeah, but who wants to do 16TB e2fsck on every boot? I think there needs to be some limits

Re: [PATCH] fix ext2 allocator overflows above 31 bit blocks

2007-04-20 Thread Eric Sandeen
Andreas Dilger wrote: On Apr 20, 2007 12:10 -0500, Eric Sandeen wrote: If ext3 can do 16T, ext2 probably should be able to as well. There are still int block containers in the block allocation path that need to be fixed up. Yeah, but who wants to do 16TB e2fsck on every boot? I think there

Re: [PATCH] fix ext2 allocator overflows above 31 bit blocks

2007-04-20 Thread Eric Sandeen
Mingming Cao wrote: On Fri, 2007-04-20 at 18:14 -0500, Eric Sandeen wrote: It's a bug, today. They are fixed in mm tree, as part of the patches which backports ext3 block reservation code to ext2. filesystem block numbers are all ext2_fsblk_t type(i.e. unsigned long)(see ext2_new_blocks()).