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
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
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
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 26908.
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
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.
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, 0xa192,
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
be
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
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 some regression
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 @@
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 against
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 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 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:
prev-rec_len
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
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 a
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 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,
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 feature of
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
21 matches
Mail list logo
