Re: [PATCH] update ext4-nanosecond-patch comments

2007-05-29 Thread Kalpak Shah
On Tue, 2007-05-29 at 11:18 +0530, Aneesh Kumar K.V wrote: Also can we have a description of why s_{min, want}_extra_isize fields are added in the commit message ? The i_extra_isize for each inode should ideally be s_want_extra_isize after inode expansion. If expansion by s_want_extra_isize is

Re: [PATCH] update ext4-nanosecond-patch comments

2007-05-29 Thread Aneesh Kumar K.V
Kalpak Shah wrote: On Tue, 2007-05-29 at 11:18 +0530, Aneesh Kumar K.V wrote: Also can we have a description of why s_{min, want}_extra_isize fields are added in the commit message ? The i_extra_isize for each inode should ideally be s_want_extra_isize after inode expansion. If expansion by

ext3 and prefetching

2007-05-29 Thread Krzysztof Lichota
Hello everyone. Let me introduce myself to the list :) My name is Krzysztof Lichota, I am at the first year of PhD studies at the Warsaw University. This summer I will be working on Automatic boot and application start file prefetching project as part of Google Summer of Code. Part of this project

Re: [PATCH] update ext4-nanosecond-patch comments

2007-05-29 Thread Andreas Dilger
On May 29, 2007 13:48 +0530, Aneesh Kumar K.V wrote: Kalpak Shah wrote: On Tue, 2007-05-29 at 11:18 +0530, Aneesh Kumar K.V wrote: Also can we have a description of why s_{min, want}_extra_isize fields are added in the commit message ? The i_extra_isize for each inode should ideally be

Re: [PATCH] update ext4-nanosecond-patch comments

2007-05-29 Thread Aneesh Kumar K.V
Andreas Dilger wrote: On May 29, 2007 13:48 +0530, Aneesh Kumar K.V wrote: When the nanosecond timestamp extension was first proposed, the requirement from Ted and Stephen were that s_min_extra_isize was a requirement. Otherwise it would be possible to have a filesystem where the

Re: ext2_discard_prealloc() called on each iput?

2007-05-29 Thread Theodore Tso
On Tue, May 29, 2007 at 12:25:45PM +0200, Jan Kara wrote: Fix a comment when ext2_release_file() is called. Signed-off-by: Jan Kara [EMAIL PROTECTED] Acked-by: Theodore Ts'o [EMAIL PROTECTED] diff -rupX /home/jack/.kerndiffexclude linux-2.6.21/fs/ext2/file.c

Re: e2fsprogs coverity patch cid-33.diff

2007-05-29 Thread Eric Sandeen
Brian D. Behlendorf wrote: Lawrence Livermore National Labs recently ran the source code analysis tool Coverity over the e2fsprogs-1.39 source to see if it would identify any significant bugs. The analysis turned up 38 mostly minor issues which are enumerated here with patches. We went

- ext4-copy-i_flags-to-inode-flags-on-write.patch removed from -mm tree

2007-05-29 Thread akpm
The patch titled ext4: copy i_flags to inode flags on write has been removed from the -mm tree. Its filename was ext4-copy-i_flags-to-inode-flags-on-write.patch This patch was dropped because it was merged into mainline or a subsystem tree

Re: [patch 2/2] i_version update - ext4 part

2007-05-29 Thread Mingming Cao
On Fri, 2007-05-25 at 18:25 +0200, Jean noel Cordenner wrote: The patch is on top of the ext4 tree: http://repo.or.cz/w/ext4-patch-queue.git In this part, the i_version counter is stored into 2 32bit fields of the ext4_inode structure osd1.linux1.l_i_version and i_version_hi. I included

Re: e2fsprogs coverity patch cid-33.diff

2007-05-29 Thread Andreas Dilger
On May 29, 2007 13:49 -0500, Eric Sandeen wrote: Brian D. Behlendorf wrote: Lawrence Livermore National Labs recently ran the source code analysis tool Coverity over the e2fsprogs-1.39 source to see if it would identify any significant bugs. The analysis turned up 38 mostly minor issues

Re: ext2_discard_prealloc() called on each iput?

2007-05-29 Thread Mingming Cao
On Mon, 2007-05-28 at 18:04 +0200, Jan Kara wrote: On Wed 23-05-07 08:37:43, Theodore Tso wrote: On Tue, May 22, 2007 at 06:11:27PM +0200, Jan Kara wrote: while fixing some problems with preallocation in UDF, I had a look how ext2 solves similar problems. I found out that

[RESEND e2progs] get_backup_sb: Consider block size when searching for backups

2007-05-29 Thread Daniel Drake
I sent this in a few weeks ago, and it hasn't been applied to the hg tree. Any comments? Thanks. I've been investigating why e2fsck refuses to restore the backup superblock of a partition with a broken primary superblock. The partition in question has a block size of 4096, and mke2fs reports

Re: e2fsprogs coverity patch cid-33.diff

2007-05-29 Thread Theodore Tso
On Tue, May 29, 2007 at 03:56:44PM -0500, Eric Sandeen wrote: I still have it in my apply atop 1.39-WIP series, so it appears not to have made it into Ted's repo. I'm including the patch again for posterity. Thanks Andreas - near as I can tell, it never made it to the list. Yeah, I

Re: [patch 2/2] i_version update - ext4 part

2007-05-29 Thread Andreas Dilger
On May 29, 2007 12:44 -0700, Mingming Cao wrote: I am a little bit confused about the two patches. It appears in the ext4_expand_inode_extra_isize patch by Kalpak, there a new 64 bit i_fs_version field is added to ext4 inode structure for inode versioning support. read/store of this

Re: [RESEND e2progs] get_backup_sb: Consider block size when searching for backups

2007-05-29 Thread Andreas Dilger
On May 29, 2007 22:26 +0100, Daniel Drake wrote: The partition in question has a block size of 4096, and mke2fs reports that backup superblocks were created on blocks 32768, 98304, 163840, ... When running e2fsck, get_backup_sb starts by guessing a block size of 1024 and backup superblock

Re: [patch 0/2] i_version update

2007-05-29 Thread David Chinner
On Fri, May 25, 2007 at 06:25:31PM +0200, Jean noel Cordenner wrote: Hi, This is an update of the i_version patch. The i_version field is a 64bit counter that is set on every inode creation and that is incremented every time the inode data is modified (similarly to the ctime time-stamp).

Re: e2fsprogs coverity patch cid-33.diff

2007-05-29 Thread Eric Sandeen
Theodore Tso wrote: On Tue, May 29, 2007 at 03:56:44PM -0500, Eric Sandeen wrote: I still have it in my apply atop 1.39-WIP series, so it appears not to have made it into Ted's repo. I'm including the patch again for posterity. Thanks Andreas - near as I can tell, it never made it to the