> +
> + jbd_unlock_bh_state(bh);
> }
>
> /**
> @@ -1245,6 +1307,11 @@ int journal_forget (handle_t *handle, struct
> buffer_head
> *bh)
>*/
> jh->b_modified = 0;
>
> + /*
> + * drop one of our write access credits
> + */
> + jh->b_nr_access--;
> +
> if (jh->b_transaction == handle->h_transaction) {
> J_ASSERT_JH(jh, !jh->b_frozen_data);
>
> diff --git a/include/linux/journal-head.h b/include/linux/journal-head.h
> index 8a62d1e..160f1d1 100644
> --- a/include/linux/journal-head.h
> +++ b/include/linux/journal-head.h
> @@ -39,6 +39,13 @@ struct journal_head {
> unsigned b_modified;
>
> /*
> + * This is a counter of the number of things who have requested write
> + * access to this buffer by the current transaction
> + * [jbd_lock_bh_state()]
> + */
> + unsigned b_nr_access;
> +
> + /*
>* Copy of the buffer data frozen for writing to the log.
>* [jbd_lock_bh_state()]
>*/
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
r(bh) but I'm not completely
sure who can do this when we just do set_buffer_dirty(bh)... Anyway
before I check that it is indeed happening what I think is happening,
your fix is fine :).
You can add: Acked-by: Jan Kara <[EMAIL PROTECTED]>
> Signed-off-by: Neil Brown <[EMAIL P
/stddev): 390.6953/22.64
> execution time (avg/stddev): 22.9264/1.17
>
>
> Filesystem I/O throughput was improved.
>
> Thanks.
>
> Signed-off-by :Hisashi Hifumi <[EMAIL PROTECTED]>
Yes, the patch looks fine. You can add
Acked-by: Jan Kara &l
Hi,
this patch fixes lock inversion in ext4 direct IO path. The similar patch
has already been accepted for ext3. Mingming, will you put it into ext4
patch queue? Thanks.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE La
[] down_read+0x42/0x79
> [] ext4_get_blocks_wrap+0x21/0x108
> [] ext4_getblk+0x62/0x1c4
> [] ext4_find_entry+0x350/0x5b7
> [] ext4_unlink+0x6e/0x1a4
> [] vfs_unlink+0x49/0x89
> [] do_unlinkat+0x96/0x12c
> [] sys_unlink+0x10/0x12
> []
On Tue 05-02-08 13:59:05, Josef Bacik wrote:
> On Tuesday 05 February 2008 12:27:31 pm Jan Kara wrote:
> > Hello,
> >
> > Sorry for replying a bit late but I'm currently falling behind in
> > maling-list reading...
> >
> > > The way jbd tries to
n.
You've just removed accounting of t_outstanding_credits which has no
impact on the real number of free blocks in the journal stored in
j_free. Anyway, if you can reproduce t_outstanding_credits <
t_nr_buffers, then there's something fishy. Are you able to reproduce it
also with a
On Tue 05-02-08 21:57:03, Aneesh Kumar K.V wrote:
> On Tue, Feb 05, 2008 at 02:42:28PM +0100, Jan Kara wrote:
> > On Tue 05-02-08 17:53:42, Aneesh Kumar K.V wrote:
> > >
> > > How about the patch below. I did the below testing
> > > a) migrate a file
>
On Tue 05-02-08 17:53:42, Aneesh Kumar K.V wrote:
> On Mon, Feb 04, 2008 at 05:31:56PM +0100, Jan Kara wrote:
> > Hi,
> >
> > On Mon 04-02-08 15:42:28, Aneesh Kumar K.V wrote:
> > > This is with the new ext3 -> ext4 migrate code added. The recently added
>
On Mon 04-02-08 22:42:08, Aneesh Kumar K.V wrote:
> On Mon, Feb 04, 2008 at 05:31:56PM +0100, Jan Kara wrote:
> > Hi,
> >
> > On Mon 04-02-08 15:42:28, Aneesh Kumar K.V wrote:
> > > This is with the new ext3 -> ext4 migrate code added. The recently added
>
01, comm: rm Not tainted 2.6.24-rc8 #6
> [] show_trace_log_lvl+0x1a/0x2f
> [] show_trace+0x12/0x14
> [] dump_stack+0x6c/0x72
> [] print_circular_bug_tail+0x5f/0x68
> [] __lock_acquire+0x921/0xc1a
> [] lock_acquire+0x7a/0x94
> [] down_read+0x42/0x79
> [] ext4_get_bloc
Hi,
resending the patch just in case you've missed it.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
Commit block was intended to have several copies of the header. But
due to a bug it never h
to go...
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
We cannot start transaction in ext3_direct_IO() and just let it last during the
whole write because dio_get_page() acquires mmap_sem which ranks above
transaction start (e.g. because we have dependency chain
mmap_se
Hi Andrew,
here's the patch I wrote you about.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
Commit block was intended to have several copies of the header. But
due to a bug it never had them and actually, nobody
On Sat 26-01-08 22:02:07, Andrew Morton wrote:
> > On Wed, 23 Jan 2008 20:09:43 +0100 Jan Kara <[EMAIL PROTECTED]> wrote:
> >
> > Commit block is expected to have several copies of the header. Fix the
> > bug Andrew has spotted ages ago.
> >
>
> &quo
On Fri 25-01-08 03:50:04, Andreas Dilger wrote:
> On Jan 25, 2008 11:05 +0100, Jan Kara wrote:
> > For example ext2 on fsync() just sync's a single inode
> > (and has to use private_list to track metadata buffers associated with
> > the inode) while ext3 flushes the
thing to change and would make sence (we wouldn't have to reimplement
readahead in ext3 directory handling code as we do now). I've looked at
it once but then more urgent things came and ... you know it.
Honza
--
Jan Kara
hanks for explanation. So for JBD2 we don't need the patch
anymore. But for JBD it's still needed.
Honza
> On Wed, 2008-01-23 at 20:10 +0100, Jan Kara wrote:
> > On Wed 23-01-08 20:09:43, Jan Kara wrote:
&g
fail, we call
ext3_error() which remounts fs R/O or panics in most cases. Only if
errors=continue is set, we really get to committing the wrong bitmap
data. But I don't think this really is a problem - fsck has to be run
anyway and it rebuilds the bitmaps from scratch.
On Wed 23-01-08 20:09:43, Jan Kara wrote:
> Hi,
>
> the patch below fixes preparation of commit block in
> journal_write_commit_record(). Obviously the bug doesn't really matter
> since nobody reported it so far but let's cleanup the code... Andrew, could
> yo
up? Thanks.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
Commit block is expected to have several copies of the header. Fix the
bug Andrew has spotted ages ago.
Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
diff --git a/fs/jbd/commit.c b/fs/jbd/commit.c
index 610264b
On Mon 14-01-08 10:57:18, Theodore Tso wrote:
> On Wed, Jan 09, 2008 at 08:54:35PM +0100, Jan Kara wrote:
> >
> > Reading of bitmaps from image file could never work with more than one
> > group in a filesystem... Fix the loops so that we read appropriate number
> >
fsprogs
if someone decides to use it...
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
From: Andreas Dilger <[EMAIL PROTECTED]>
Make sure lost+found has always at least 2 disk blocks. This will provide at
least e
Hi Ted,
I've sent you the attached fix some time ago but it didn't seem to get
merged yet...
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
Subject: Fix reading of bitmaps from filesystem image
Reading
On Wed 09-01-08 23:54:28, Aneesh Kumar K.V wrote:
> On Wed, Jan 09, 2008 at 01:10:41PM +0100, Jan Kara wrote:
> > > With the multi block allocator when we don't have prealloc space we
> > > discard
> > > @@ -3790,7 +3782,9 @@ repeat:
> > >
> >
sb, group);
> + schedule_timeout(HZ);
> goto repeat;
> }
Hmm, wouldn't just schedule() be enough here? That would give a good
chance to other processes to proceed and we would avoid this artificial
wait of 1s which is quite ugly IMO.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
s actually my fix ;).
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
"Done!"
> > >
> > > #rm -rf $DEST_DIR $SRC1 $SRC2
> > >
> > > While running it, try to use "normally" the interactive programs, such as
> > > konqueror (the program should have to access files, such as cookies,
> > > cache
such as
> > konqueror (the program should have to access files, such as cookies, cache
> > and
> > so for konqueror). Then remount/tune the filesystem to use another data mode
> > for ext3.
> >
> > I didn't try with other journaling filesystems. I guess ext
.
Also if you don't apply a patch for 2-block lost+found from Andreas, you
need to disable the first test which would fail otherwise.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
64KB_test.tar.gz
...
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
From: Andreas Dilger <[EMAIL PROTECTED]>
Make sure lost+found has always at least 2 disk blocks. This will provide at
least elementary test that we have not screwed-up support for 64KB blocks since
the seco
hanks.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
Subject: Support for 64KB blocksize in ext2-4 directories.
When block size is 64KB, we have to take care that rec_len does not overflow.
Kernel stores 0x in case 0x1 should be store
Hi,
reading of bitmaps from a filesystem image seems to be busted. The patch
below fixes it for me.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
Subject: Fix reading of bitmaps from filesystem
Hi,
the patch below should fix an assertion failure in JBD checkpointing
code. The patch survived some fsstress and similar runs on my test machine
so it shouldn't be obviously wrong ;).
Honza
--
Jan Kara <[EMAIL P
Hi,
the patch below fixes a bug in ext2fs_unlink() I came across when testing
my changes to e2fsprogs for 64KB blocksize support... Please apply.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
Subject:
s already been written. So it
removes and because there are no other buffers there, it tries to free
the transaction as well which is a bug. It should also check that the
transaction is not currently running.
Now the question is how to properly check this. We should hold
j_state_lock for that but
On Wed 21-11-07 00:40:17, Coly Li wrote:
> Jan Kara wrote:
> >> diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> >> index 17b5df1..f838a72 100644
> >> --- a/fs/ext4/ialloc.c
> >> +++ b/fs/ext4/ialloc.c
> >> @@ -10,6 +10,8 @@
> >> *
bitmap_bh) != 0)
> + goto fail;
> + ires_ino = bit;
> + goto find;
> + }
> + /* we lost it */
> +
4 85 c0 7f 30 c7 44 24
> : EIP: [journal_put_journal_head+64/209] journal_put_journal_head+0x40/0xd1
> SS:ESP 0068:c2bf7e38
> : note: kswapd0[243] exited with preempt_count 2
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon 12-11-07 09:58:23, Theodore Tso wrote:
> On Mon, Nov 12, 2007 at 10:52:45AM +0100, Jan Kara wrote:
> > > Did you test this patch before submitting it?
> >
> > Argh, stupid me. I've just tested that I didn't break anything for normal
> > block size a
On Sat 10-11-07 19:37:03, Theodore Tso wrote:
> On Wed, Nov 07, 2007 at 05:09:39PM +0100, Jan Kara wrote:
>
> > Subject: Support for 64KB blocksize in ext2-4 directories.
> >
> > When block size is 64KB, we have to take care that rec_len does not
> > overflow.
&g
he cases where the filesystem simply does not
support the feature). I don't think it wouldn't be too complicated but I have
not the modification for rsync yet, so I can underestimate...
> On Thu, Nov 08, 2007 at 11:56:42AM +0100, Jan Kara wrote:
> > > Note by the way that since
On Wed 07-11-07 19:20:38, Theodore Tso wrote:
> On Wed, Nov 07, 2007 at 03:36:05PM +0100, Jan Kara wrote:
> > > What if more than one application wants to use this facility?
> >
> > That should be fine - let's see: Each application keeps somewhere a time
> &
On Tue 06-11-07 18:01:00, Al Viro wrote:
> On Tue, Nov 06, 2007 at 06:19:45PM +0100, Jan Kara wrote:
> > Implement recursive mtime (rtime) feature for ext3. The feature works as
> > follows: In each directory we keep a flag EXT3_RTIME_FL (modifiable by a
> > user)
> &
On Tue 06-11-07 14:40:12, Theodore Tso wrote:
> On Tue, Nov 06, 2007 at 06:19:45PM +0100, Jan Kara wrote:
> > Intended use case is that application which wants to watch any
> > modification in a subtree scans the subtree and sets flags for all
> > inodes there. Next time, it
Hello,
sorry for replying to myself but I've just found out that the patch I've
sent was and old version of the patch which had some problems. Attached is
a new version.
On Tue 06-11-07 12:31:42, Jan Kara wrote:
> it seems attached patch still did not get your attent
On Tue 06-11-07 10:04:47, H. Peter Anvin wrote:
> Arjan van de Ven wrote:
> >On Tue, 6 Nov 2007 18:19:45 +0100
> >Jan Kara <[EMAIL PROTECTED]> wrote:
> >
> >>Implement recursive mtime (rtime) feature for ext3. The feature works
> >>as follows: I
modified and rtimes properly updated and thus any application has an
effective way of finding new hardlinked files).
Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
diff -rupX /home/jack/.kerndiffexclude
linux-2.6.23-2-ext3_make_frags_unused/fs/ext3/ialloc.c
linux-2.6.23-3-ext3_recursive_mtime/
Make space reserved for fragments as unused as they were never implemented.
Remove also related initializations. We later use the space for recursive
mtime.
Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
diff -rupX /home/jack/.kerndiffexclude
linux-2.6.23-1-i_flags_atomicity/fs/ext3/ia
Hello,
the following patch makes more lightweight handling of
EXT3_I(inode)->i_flags possible.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
Implement atomic updates of EXT3_I(inode)->i_flags. So far
), please
contact me. Attached are sources of simple tools set_recmod, get_recmod
for testing the feature and also a patch implementing basic support of
the feature in e2fsprogs. Comments welcome.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
Wrote wrong mailing list address so I'm resending it to a correct one.
- Forwarded message from Jan Kara <[EMAIL PROTECTED]> -----
From: Jan Kara <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [PATCH] e2fsprogs: Handle rec_len correctly for 64KB b
6b86..d9493e3 100644
> --- a/include/linux/ext4_fs.h
> +++ b/include/linux/ext4_fs.h
> @@ -92,6 +92,13 @@ struct ext4_allocation_request {
> #define EXT4_GOOD_OLD_FIRST_INO 11
>
> /*
> + * Macro-instructions used to reserve inodes for directories
> + */
> +#defin
me if there are
any problems with the patch.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
Subject: Support for 64KB blocksize in ext2-4 directories.
When block size is 64KB, we have to take care that rec_len does n
x27;s not very likely you're going to hit it but we should fix it
anyway. Currently I don't have much idea how - probably we'd have to get
rid of the need to use i_mutex on quota files in quota_write but that's
also non-trivial.
4 (or nasty
things would happen if somebody actually try 64KB blocksize in ext3).
Thanks
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
---
With 64KB blocksize, a dire
rent output? ... maybe
when user wants to inspect /proc/mounts by himself.
> Signed-off-by: Aneesh Kumar K.V <[EMAIL PROTECTED]>
> Cc:
> Cc: Eric Sandeen <[EMAIL PROTECTED]>
> Cc: Jan Kara <[EMAIL PROTECTED]>
> Cc: Dave Jones <[EMAIL PROTECTED]>
> Cc: Chu
s for large block size in
e2fsprogs. I guess I should ping Ted about merging the patch once more.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe
t time,
it just needs to recurse in directories having rtime newer than the start
of the previous scan. There it can handle modifications and set the flag
again.
Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
diff -rupX /home/jack/.kerndiffexclude
linux-2.6.23-1-ext3_iflags_locking/fs/ext3/ialloc
ike atomic_read() and atomic_set()? It would be nice to
use them here - currently I just assign to the variable but I'm not sure if
this cannot result in some garbage on some strange architecture.
Honza
--
Jan Kara <[EMAI
On Thu 04-10-07 13:12:07, Andrew Morton wrote:
> On Mon, 01 Oct 2007 17:35:46 -0700
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > ext2: Avoid rec_len overflow with 64KB block size
> >
> > From: Jan Kara <[EMAIL PROTECTED]>
> >
> > With 6
.patch.
Sorry, for the delayed answer but I had some urgent bugs to fix...
Why did you drom ext3-support-large-blocksize-up-to-pagesize.patch? As far
as I understand your previous email (and also as I've checked against
2.6.23-rc8-mm2), the patch fixing rec_len overflow clashes only for ext2...
Hello,
> I am looking at ext4_max_size and was confused how the
> number upper_limit = 0x1ff7fffd000LL is arrived.
> The comment says the value is arrived looking at 4K.
> So i tried the below program.
>
> main()
> {
> unsigned long long upper_limit, meta_blocks;
> int bits = 12;
On Thu 04-10-07 13:12:07, Andrew Morton wrote:
> On Mon, 01 Oct 2007 17:35:46 -0700
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > ext2: Avoid rec_len overflow with 64KB block size
> >
> > From: Jan Kara <[EMAIL PROTECTED]>
> >
> > With 6
Hi,
attached patch implements support for 64KB blocksize in directories in
e2fsprogs. This patch complements the kernel patches for ext2-4 I've sent
yesterday. Ted, does the patch look fine?
Honza
--
Jan Kara <[EMAIL P
> On Tue, 25 Sep 2007 07:49:38 -0500
> "Jose R. Santos" <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 25 Sep 2007 13:50:46 +0200
> > Jan Kara <[EMAIL PROTECTED]> wrote:
> > > > Jan Kara wrote:
> > > > >>
> > > > >
won't be marked as with errors later (and user could happily
mount
it without any warning).
Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
diff -rupX /home/jack/.kerndiffexclude
linux-2.6.23-rc6-1-jbd_abort_fix/fs/jbd2/commit.c
linux-2.6.23-rc6-2-jbd2_abort_fix/fs/jbd2/commit.c
--- linux
Hi,
attached patch changes JBD commit code to properly record reason for
aborted journal (j_errno) and not just mark the journal as aborted. Andrew,
could you please queue the patch? Thanks.
Honza
--
Jan Kara <[EM
>
>
> Jan Kara wrote:
> >>
> >-#define create_jbd_proc_entry() do {} while (0)
> >-#define remove_jbd_proc_entry() do {} while (0)
> >+static ctl_table fs_table[] = {
> >+{
> >+.ctl_name = -1, /* Don't want it
ould you queue it up?
Honza
JBD debug code used old way of creating proc entries for jbd-debug file.
Change it to use sysctl instead.
Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
diff -rupX /home/jack/.kerndiffexclude linux-2.6.23-rc6/fs/jbd/journal.c
linux-2.
-off-by: Jan Kara <[EMAIL PROTECTED]>
diff -rupX /home/jack/.kerndiffexclude linux-2.6.23-rc6/fs/ext4/dir.c
linux-2.6.23-rc6-1-ext4_64k_blocksize/fs/ext4/dir.c
--- linux-2.6.23-rc6/fs/ext4/dir.c 2007-09-18 19:22:28.0 +0200
+++ linux-2.6.23-rc6-1-ext4_64k_blocksize/fs/ext4/dir.
-off-by: Jan Kara <[EMAIL PROTECTED]>
diff -rupX /home/jack/.kerndiffexclude linux-2.6.23-rc6/fs/ext3/dir.c
linux-2.6.23-rc6-1-ext3_64k_blocksize/fs/ext3/dir.c
--- linux-2.6.23-rc6/fs/ext3/dir.c 2007-09-18 19:22:28.0 +0200
+++ linux-2.6.23-rc6-1-ext3_64k_blocksize/fs/ext3/dir.
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.
Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
diff -rupX /home/jack/.kerndiffexclude linux-2.6.
Hi,
In the following series I'm sending patches to ext2, ext3 and ext4
solving possible overflow of rec_len when using 64KB blocksize. Minming,
would you add these to the patch queue? Thanks.
Honza
--
Jan Kara <[EMAIL P
> 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)
> 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 patc
k up a similar patch for ext2 / ext3.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
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
On Thu 20-09-07 11:14:40, Theodore Tso wrote:
> On Thu, Sep 20, 2007 at 04:58:39PM +0200, Jan Kara wrote:
> > Hmm, strange - I've just looked at my computer and dir_index is set
> > just for 5 directories in my tree.
>
> I looked at a tree that had object files, which
> On Thu, Sep 20, 2007 at 03:33:50PM +0200, Jan Kara wrote:
> > So for example deleting kernel tree on my computer takes ~14 seconds with
> > h-trees and less than 9 without them. Also doing 'cp -lr' of the kernel
> > tree takes 8 seconds with h-trees and 6.3s
re
rec_len? That would be IMHO more transparent than current approach (at
least it took me some time to understand what's going on with the
current patch when I was looking at the code)...
Honza
--
Jan Kara <[EMAIL PROTECTED]&
On Wed 19-09-07 14:24:50, Theodore Tso wrote:
> On Wed, Sep 19, 2007 at 05:07:15PM +0200, Jan Kara wrote:
> >
> > I was just wondering: Currently we start to build h-tree in a directory
> > already when the size of directory exceeds one block. But honestly, it does
>
e are safe). Any feeling
what is less hacky?
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SUSE Labs, CR
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [EMAIL PROT
down some
operations like deleting the whole directory, etc. So what is the reason
for starting building the tree so early? Just the simplicity of building it
when the directory is just one block large?
Honza
--
Jan Kara &l
> Submitter : Oliver Neukum <[EMAIL PROTECTED]>
> Caused-By : ?
> Handled-By : ?
> Status : unknown
I thought Shaggy asked Oliver about some details (and he did not
answer so far) so I'd assume Shaggy is handling this.
> I have a couple of failed test runs against 2.6.23-rc6 where the
> job timed out while running dbench over ext3. Both on powerpc,
> though both significantly different hardware setups. A failed
> run like this implies that the machine was still responsive to
> other processes but the dbench was
On Tue 04-09-07 12:01:53, Andreas Dilger wrote:
> On Sep 03, 2007 20:03 +0200, Jan Kara wrote:
> > I've finally got to writing up some proposal how could look system calls
> > allowing for online filesystem defragmentation and generally moving file
> > blocks around
t;
size_t len;
};
Function returns a number of extents stored. Note that the result of the
function is unreliable as the space can be already allocated by the time system
call returns.
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubsc
On Tue 21-08-07 11:43:12, Josef Bacik wrote:
> On Mon, Aug 20, 2007 at 05:20:21PM +0200, Jan Kara wrote:
> > OK, thanks. So record probably points to an already freed memory which has
> > been overwritten by garbage...
> >
> > > > Thanks for details. I
On Thu 16-08-07 12:37:45, Josef Bacik wrote:
> On Thu, Aug 16, 2007 at 06:08:35PM +0200, Jan Kara wrote:
> > > > > It is possible to panic the box by a race condition that exists in the
> > > > > journalling code where we do not take the j_revoke_lo
Hello,
> > > It is possible to panic the box by a race condition that exists in the
> > > journalling code where we do not take the j_revoke_lock when traversing
> > > the
> > > journal's revoked record list. This patch has been tested and we haven't
> > > seen
> > > the issue yet, its a rath
ing
transaction shouldn't see any further changes. So maybe the patch is
masking a different problem.
Do you have a way of reproducing the problem? Any stack trace
available?
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR La
On Thu 21-06-07 03:33:43, Andreas Dilger wrote:
> On Jun 20, 2007 14:56 +0200, Jan Kara wrote:
> > when ext2fs_block_iterate() is called on a fast symlink (and I assume
> > device inodes would be no different), then random things happen - the
> > problem is ext2fs_block_i
makes no sence to call this function on such inode) so garbage results but
maybe it would be nicer to handle it more gracefully. Attached patch should
do it.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
--- a/lib/
by the page lock - it can be even better that it's not
protected as it can trigger commit and all that would happen
unnecessarily under page lock...
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To
Resending the message as I've screwed up the mailing list address...
Honza
- Forwarded message from Jan Kara <[EMAIL PROTECTED]> -----
From: Jan Kara <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Andr
On Tue 29-05-07 14:10:52, Mingming Cao wrote:
> 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 proble
ease put it
into your patch queue... Thanks.
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
Fix a comment when ext2_release_file() is called.
Signed-off-by: Jan Kara <[EMAIL PROTECTED]>
diff -rupX /home/jack/.kerndiffexclude linux-2
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 ext2_discard_prealloc() is
> >
then also calling ext2_discard_prealloc() from ext2_release_file()
is suboptimal, isn't it?
Thanks for answer
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE CR Labs
-
To unsubscribe from this list: sen
> On Mon, 2007-05-21 at 12:38 +0200, Jan Kara wrote:
> > Yes. On the other hand I believe that some people would like to use
> > defragmentation but stay with ext3. For them conversion to extents is
> > no-go.
> > [...]
> > I've written a patch that
1 - 100 of 156 matches
Mail list logo
