On Mon, 2007-07-09 at 19:02 -0400, Theodore Tso wrote:
> On Mon, Jul 09, 2007 at 11:22:05PM +0530, Kalpak Shah wrote:
> > Yes even prev->rec_len cannot be beyond fs->blocksize. I do have the
> > corrupt filesystem image but it is a large one.
> >
> > This patch certainly works well and corrects t
When a new block bitmap is read from disk in read_block_bitmap()
there are a few bits that should ALWAYS be set. In particular, the
blocks given by ext4_blk_bitmap, ext4_inode_bitmap and ext4_inode_table.
Validate the block bitmap against these blocks.
Signed-off-by: Aneesh Kumar K.V <[EMAIL PROTE
On Fri, 2007-07-06 at 16:53 -0600, Andreas Dilger wrote:
> On Jul 06, 2007 09:51 -0400, J. Bruce Fields wrote:
> > The use of a mount option means the change attribute could be
> > inconsistent across mounts. If we really need this, wouldn't it make
> > more sense for it to be a persistent featur
On Mon, 2007-07-09 at 13:37 -0400, Theodore Ts'o wrote:
> Per our discussion on the call, I've moved the fallocate patches back up
> to the front of the queue, and rebased the syscall numbers to 2.6.22.
I updated the ext4 patch queue.
It seem there is conflict to apply delayed allocation patch, f
On Mon, 9 July 2007 17:02:20 -0500, Dave Kleikamp wrote:
>
> It's not a direct call to a static function. It is called as a
> super_ops method. I don't think the overhead is very significant, but
> it doesn't look like it could do any harm.
Ah, I missed that fact. Yep, looks fine to me.
Jörn
On Mon, 2007-07-09 at 22:00 +0200, Jörn Engel wrote:
> On Mon, 9 July 2007 22:01:48 +0400, Alexey Dobriyan wrote:
> >
> > Yes. Note that ext2_clear_inode() is referenced from ext2_sops, so even
> > empty, it leaves traces in resulting kernel.
>
> Is that your opinion or have you actually measured
Ext4 Developer Interlock Call: July 9, 2007 Meeting Minutes
Minutes can be accessed at:
http://ext4.wiki.kernel.org/index.php/Ext4_Developer%27s_Conference_Call
Attendees: Mingming Cao, Takashi Sato, Dave Kleikamp, Jose Santos,
Andreas Dilger, Amit Arora, Suparna Bhattacharya, Aneesh Veetil,
On Mon, Jul 09, 2007 at 01:17:33PM -0600, Andreas Dilger wrote:
> On Jul 09, 2007 14:29 -0400, Theodore Tso wrote:
> > On Mon, Jul 09, 2007 at 11:22:05PM +0530, Kalpak Shah wrote:
> > > Yes even prev->rec_len cannot be beyond fs->blocksize.
> >
> > Really? Even after this:
> >
> >
On Mon, 9 July 2007 22:01:48 +0400, Alexey Dobriyan wrote:
>
> Yes. Note that ext2_clear_inode() is referenced from ext2_sops, so even
> empty, it leaves traces in resulting kernel.
Is that your opinion or have you actually measured a difference?
I strongly suspect that compilers are smart enough
On Jul 09, 2007 14:29 -0400, Theodore Tso wrote:
> On Mon, Jul 09, 2007 at 11:22:05PM +0530, Kalpak Shah wrote:
> > Yes even prev->rec_len cannot be beyond fs->blocksize.
>
> Really? Even after this:
>
>prev->rec_len += dirent->rec_len;
> ^^
On Jul 09, 2007 23:54 +0530, Aneesh Kumar K.V wrote:
> When a new block bitmap is read from disk in read_block_bitmap()
> there are a few bits that should ALWAYS be set. In particular, the
> blocks given by ext4_blk_bitmap, ext4_inode_bitmap and ext4_inode_table.
> Validate the block bitmap agains
On Jul 09, 2007 22:52 +0530, Aneesh Kumar K.V wrote:
> Something like this ?. If yes i can send a patch with full changelog
>
>
> diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
> index 44c6254..b9a334c 100644
> --- a/fs/ext4/balloc.c
> +++ b/fs/ext4/balloc.c
> @@ -115,17 +115,50 @@ read_block_
On Mon, Jul 09, 2007 at 11:22:05PM +0530, Kalpak Shah wrote:
> On Mon, 2007-07-09 at 12:50 -0400, Theodore Tso wrote:
> > On Mon, Jul 09, 2007 at 03:02:02PM +0530, Kalpak Shah wrote:
> > > Hi Ted,
> > >
> > > Recently, one of our customers found this message in pass2 of e2fsck
> > > while doing s
When a new block bitmap is read from disk in read_block_bitmap()
there are a few bits that should ALWAYS be set. In particular, the
blocks given by ext4_blk_bitmap, ext4_inode_bitmap and ext4_inode_table.
Validate the block bitmap against these blocks.
Signed-off-by: Aneesh Kumar K.V <[EMAIL PROTE
On Mon, Jul 09, 2007 at 10:34:32AM +0200, Jörn Engel wrote:
> On Mon, 9 July 2007 08:11:22 +0400, Alexey Dobriyan wrote:
> >
> > If CONFIG_EXT2_FS_POSIX_ACL is not configured, ext2_clear_inode() will be
> > empty
> > function. However, there still will be call and immediate return which can
> >
On Mon, 2007-07-09 at 12:50 -0400, Theodore Tso wrote:
> On Mon, Jul 09, 2007 at 03:02:02PM +0530, Kalpak Shah wrote:
> > Hi Ted,
> >
> > Recently, one of our customers found this message in pass2 of e2fsck while
> > doing some regression testing:
> > "Entry '4, 0x695a, 0x81ff, 0x0040, 0x8320, 0x
Per our discussion on the call, I've moved the fallocate patches back up
to the front of the queue, and rebased the syscall numbers to 2.6.22.
So we're just waiting for Amit to make the minor on-disk format change
Andreas suggested before we push to Linus.
Andreas Dilger wrote:
During a discussion at OLS, I came up with a very simple way of validating
the ext2/3/4 block bitmaps at read time. Until such a time when we have
checksums for the bitmaps we can have a simple but quite robust mechanism
that is useful for ext2/3/4.
When a new block bitm
On Mon, Jul 09, 2007 at 03:02:02PM +0530, Kalpak Shah wrote:
> Hi Ted,
>
> Recently, one of our customers found this message in pass2 of e2fsck while
> doing some regression testing:
> "Entry '4, 0x695a, 0x81ff, 0x0040, 0x8320, 0xa192, 0x0021' in ??? (136554) has
> rec_len of 14200, should be 269
People may have noticed that e2fsprogs 1.40 and roughly a week later
e2fsprogs 1.40.1 have been released, while there hasn't been any
activity at http://thunk.org/hg/e2fsprogs. That's because right after
e2fsprogs 1.40, I have moved the e2fsprogs development activity over to
git. The public repos
Hi Ted,
Recently, one of our customers found this message in pass2 of e2fsck while
doing some regression testing:
"Entry '4, 0x695a, 0x81ff, 0x0040, 0x8320, 0xa192, 0x0021' in ??? (136554) has
rec_len of 14200, should be 26908."
Both the displayed rec_len and the "should be" value are bogus. The
On Mon, 9 July 2007 08:11:22 +0400, Alexey Dobriyan wrote:
>
> If CONFIG_EXT2_FS_POSIX_ACL is not configured, ext2_clear_inode() will be
> empty
> function. However, there still will be call and immediate return which can be
> avoided.
> [...]
> +#ifdef CONFIG_EXT2_FS_POSIX_ACL
> static void ext
22 matches
Mail list logo
