On Sep 15, 2007 21:22 -0400, Theodore Ts'o wrote:
> The problem with this is that it's fragile; you could potentially have
> an inode that happens to have as its first block something which looks
> like the extent magic number, and if the second block passes the extent
> validity checks, e2fsck wi
JBD2 naming cleanup
From: Mingming Cao <[EMAIL PROTECTED]>
change micros name from JBD_XXX to JBD2_XXX in JBD2/Ext4
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
fs/ext4/extents.c |2 +-
fs/ext4/super.c |2 +-
fs/jbd2/commit.c |2 +-
fs/jbd2/journal.
ext2fs_dblist_iterate breaks its iteration loop if callback's return value
has set DBLIST_ABORT bit.
If ext2fs_dblist_iterate is called by ext2fs_dblist_dir_iterate,
the callback is db_dir_proc->ext2fs_process_dir_block, which returns BLOCK_ABORT
if something goes wrong.
BLOCK_ABORT is defined as
Convert kmalloc to kzalloc() and get rid of the memset().
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
fs/ext3/xattr.c |3 +--
fs/ext4/xattr.c |3 +--
fs/jbd/journal.c |3 +--
fs/jbd/transaction.c |2 +-
fs/jbd2/journal.c |3 +--
fs/jbd2/transactio
This is a note to let you know that we have just queued up the patch titled
Subject: ext34: ensure do_split leaves enough free space in both blocks
to the 2.6.22-stable tree. Its filename is
ext34-ensure-do_split-leaves-enough-free-space-in-both-blocks.patch
A git repo of this tree
Jose R. Santos wrote:
> On Fri, 21 Sep 2007 13:29:27 -0700
> Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
>> On Fri, 2007-09-21 at 09:06 -0500, Jose R. Santos wrote:
>>> From: Jose R. Santos <[EMAIL PROTECTED]>
>>>
>>> ext4: FLEX_BG Kernel support v2.
>>>
>>> @@ -702,13 +702,15 @@ static inline i
On Fri, 21 Sep 2007 13:29:27 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-09-21 at 09:06 -0500, Jose R. Santos wrote:
> > From: Jose R. Santos <[EMAIL PROTECTED]>
> >
> > ext4: FLEX_BG Kernel support v2.
> >
>
> > @@ -702,13 +702,15 @@ static inline int ext4_valid_inum(struc
On Fri, 2007-09-21 at 09:06 -0500, Jose R. Santos wrote:
> From: Jose R. Santos <[EMAIL PROTECTED]>
>
> ext4: FLEX_BG Kernel support v2.
>
> @@ -702,13 +702,15 @@ static inline int ext4_valid_inum(struct super_block
> *sb, unsigned long ino)
> #define EXT4_FEATURE_INCOMPAT_META_BG
The patch titled
ext4: FLEX_BG Kernel support
has been added to the -mm tree. Its filename is
ext4-flex_bg-kernel-support-v2.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
o
From: Jose R. Santos <[EMAIL PROTECTED]>
ext4: FLEX_BG Kernel support v2.
This feature relaxes check restrictions on where each block groups meta data is
located within the storage media. This allows for the allocation of bitmaps or
inode tables outside the block group boundaries in cases wher
> On Thu, Sep 20, 2007 at 06:19:04PM +0200, Jan Kara wrote:
> > if (EXT4_HAS_COMPAT_FEATURE(inode->i_sb, EXT4_FEATURE_COMPAT_DIR_INDEX) &&
> > ((EXT4_I(inode)->i_flags & EXT4_INDEX_FL) ||
> > ((inode->i_size >> sb->s_blocksize_bits) == 1))) {
> > error = ext4_dx_readdir(filp, diren
> On Sep 20, 2007 18:17 +0200, Jan Kara wrote:
> > With 64KB blocksize, a directory entry can have size 64KB which does not fit
> > into 16 bits we have for entry lenght. So we store 0x instead and
> > convert
> > value when read from / written to disk. The patch also converts some places
> >
On Fri, Sep 21, 2007 at 04:03:26PM +0530, Aneesh Kumar K.V wrote:
>
> I was looking at the patch queue and see patches with different formats.
> If we can standardize on what rest of the linux kernel follows it would
> be nice.
>
> First line should be
> : A single line description of the patch.
On Fri, Sep 21, 2007 at 11:02:58AM +0200, Andi Kleen wrote:
> I assume you mean sort by inode, because sort by htree key would
> be as bad as htrees.
>
> But wouldn't that break parallel readdir for a directory that just grows
> from <32/64K to over it? e.g. if the sort moves already read
> entr
Aneesh Kumar K.V wrote:
Hi all,
I was looking at the patch queue and see patches with different formats.
If we can standardize on what rest of the linux kernel follows it would
be nice.
I found this
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
-aneesh
-
To unsubscribe from
Hi all,
I was looking at the patch queue and see patches with different formats.
If we can standardize on what rest of the linux kernel follows it would
be nice.
First line should be
: A single line description of the patch.
This appear in the subject line of the mail that results from differe
The patch titled
Introduce ext4_find_next_bit
has been added to the -mm tree. Its filename is
introduce-ext4_find_next_bit.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out
Balbir Singh wrote:
Aneesh Kumar K.V wrote:
Also add generic_find_next_le_bit
This gets used by the ext4 multi block allocator patches.
Looks like it's a straight forward on Little Endian Architectures.
I see something for powerpc, what about other architectures?
All include/asm-/bitops.
Balbir Singh wrote:
Aneesh,
The subject is a bit confusing, I presume you mean sparse warnings
yes. I will send an updated patch. The group descriptor bg_flags -> le16
conversion
should actually go with the uninitialized block group patch.
-aneesh.
-
To unsubscribe from this list: send
Theodore Tso <[EMAIL PROTECTED]> writes:
>
> Certainly one of the things that we could consider is for small
> directories to do an in-memory sort of all of the directory entries at
> opendir() time, and keeping that list until it is closed. We can't do
> this for really big directories, but we c
20 matches
Mail list logo
