headers
akpm | 1 Mar 2008 01:04

+ jbd2-fix-possible-journal-overflow-issues.patch added to -mm tree


The patch titled
     jbd2: fix possible journal overflow issues
has been added to the -mm tree.  Its filename is
     jbd2-fix-possible-journal-overflow-issues.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** 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 what to do about this

The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/

------------------------------------------------------
Subject: jbd2: fix possible journal overflow issues
From: Josef Bacik <jbacik <at> redhat.com>

There are several cases where the running transaction can get buffers added to
its BJ_Metadata list which it never dirtied, which makes its t_nr_buffers
counter end up larger than its t_outstanding_credits counter.

This will cause issues when starting new transactions as while we are logging
buffers we decrement t_outstanding_buffers, so when t_outstanding_buffers goes
negative, we will report that we need less space in the journal than we
(Continue reading)

Permalink | Reply | 0 comments |
headers
akpm | 1 Mar 2008 01:04

+ jbd-fix-the-way-the-b_modified-flag-is-cleared.patch added to -mm tree


The patch titled
     jbd: fix the way the b_modified flag is cleared
has been added to the -mm tree.  Its filename is
     jbd-fix-the-way-the-b_modified-flag-is-cleared.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** 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 what to do about this

The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/

------------------------------------------------------
Subject: jbd: fix the way the b_modified flag is cleared
From: Josef Bacik <jbacik <at> redhat.com>

Currently at the start of a journal commit we loop through all of the buffers
on the committing transaction and clear the b_modified flag (the flag that is
set when a transaction modifies the buffer) under the j_list_lock.

The problem is that everywhere else this flag is modified only under the jbd
lock buffer flag, so it will race with a running transaction who could
potentially set it, and have it unset by the committing transaction.
(Continue reading)

Permalink | Reply | 0 comments |
headers
akpm | 1 Mar 2008 01:04

+ jbd2-fix-the-way-the-b_modified-flag-is-cleared.patch added to -mm tree


The patch titled
     jbd2: fix the way the b_modified flag is cleared
has been added to the -mm tree.  Its filename is
     jbd2-fix-the-way-the-b_modified-flag-is-cleared.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** 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 what to do about this

The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/

------------------------------------------------------
Subject: jbd2: fix the way the b_modified flag is cleared
From: Josef Bacik <jbacik <at> redhat.com>

Currently at the start of a journal commit we loop through all of the buffers
on the committing transaction and clear the b_modified flag (the flag that is
set when a transaction modifies the buffer) under the j_list_lock.

The problem is that everywhere else this flag is modified only under the jbd2
lock buffer flag, so it will race with a running transaction who could
potentially set it, and have it unset by the committing transaction.
(Continue reading)

Permalink | Reply | 0 comments |
headers
akpm | 1 Mar 2008 01:04

+ jbd-fix-possible-journal-overflow-issues.patch added to -mm tree


The patch titled
     jbd: fix possible journal overflow issues
has been added to the -mm tree.  Its filename is
     jbd-fix-possible-journal-overflow-issues.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** 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 what to do about this

The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/

------------------------------------------------------
Subject: jbd: fix possible journal overflow issues
From: Josef Bacik <jbacik <at> redhat.com>

There are several cases where the running transaction can get buffers added to
its BJ_Metadata list which it never dirtied, which makes its t_nr_buffers
counter end up larger than its t_outstanding_credits counter.

This will cause issues when starting new transactions as while we are logging
buffers we decrement t_outstanding_buffers, so when t_outstanding_buffers goes
negative, we will report that we need less space in the journal than we
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aneesh Kumar K.V | 1 Mar 2008 18:30
Picon
Gravatar

Re: [RFC][PATCH] ext4: Convert uninitialized extent to initialized extent in case of file system full

On Fri, Feb 29, 2008 at 11:21:42AM -0800, Andreas Dilger wrote:
> On Feb 29, 2008  16:39 +0530, Aneesh Kumar K.V wrote:
> > > One simple solution is submit bio directly to zero out the blocks on
> > > disk, and wait for that to finish before clear the uninitialized bit. On
> > > a 4K block size case, the max size of an uninitialized extents is 128MB,
> > > and since the blocks are all contigous on disk, a single IO could done
> > > the job, the latency should not be a too big issue. After all when a
> > > filesystem is full, it's already performs slowly.
> > 
> > This is the change that i have now. Yet to run the full test on that.
> > But seems to be working for simple tests.
> > 
> > diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> > index d315cc1..26396e2 100644
> > --- a/fs/ext4/extents.c
> > +++ b/fs/ext4/extents.c
> >  <at>  <at>  -2136,6 +2136,55  <at>  <at>  void ext4_ext_release(struct super_block *sb)
> >  #endif
> >  }
> >  
> > +static void bi_complete(struct bio *bio, int error)
> > +{
> > +	complete((struct completion*)bio->bi_private);
> > +}
> 
> Note that the completion event can be called multiple times if there are
> block device errors...  Our similar completion code in Lustre is like:
> 
> static int dio_complete_routine(struct bio *bio, unsigned int done, int error)
> {
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jose R. Santos | 2 Mar 2008 04:24
Picon
Favicon

Re: What's cooking in e2fsprogs.git (topics)

On Fri, 29 Feb 2008 10:43:33 -0500
Theodore Tso <tytso <at> MIT.EDU> wrote:
> Although I've checked to make sure that each of these topic branches
> passes "make check" on their own, the combined pu branch is failing
> due to what appears to be unfortunate interactions between js/flex-bg
> and js/uninit.  This *may* be because I botched the merge, which got
> tricky when I merged in js/uninit into the pu branch which already had
> js/flex-bg.  If someone could take a look at the misc/mke2fs.c changes
> in "git show bffaaf74", I'd much appreciate it.

The misc/mke2fs.c changes look sane to me.

> * js/flex-bg (Wed Feb 13 20:47:50 2008 -0600) 1 commit
>  - e2fsprogs: New bitmap and inode table allocation for FLEX_BG v2
> 
> 	I've noticed that this patch is slightly different from what
> 	Jose sent in for the e2fsprogs-interim branch, so I'm a little
> 	concerned about which is the latest, or whether the
> 	differences are intentional.  Jose, if you have time, could
> 	you take a look at commits cb676995 and 8072fe6 and perhaps comment?

There where slight differences in misc/mke2fs.c that required making a
different patch for the e2fsprogs-interim branch.  The patches are
functionally the same.

-JRS
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Sandeen | 2 Mar 2008 17:46
Picon
Favicon
Gravatar

blkid -w is ignored... fix the code or the manpage? :)

the blkid manpage says:

	-w	<writecachefile>  Write  the  device  cache  to
		writecachefile instead of writing it to the default
		cache file /etc/blkid.tab. If you don’t want to save
		the cache to the default file,  specify  /dev/null.
		If  not specified it will be the same file as that
		given by the -c option.

and yet, since:

http://thunk.org/hg/e2fsprogs/?rev/ad62cded89a8 (I think...)

(2003...) it has been completely ignored.

I have a bug on this, from before my time at Red Hat,
https://bugzilla.redhat.com/show_bug.cgi?id=200191  Bugzilla Bug 200191:
blkid does not rewrite blkid.tab as documented in the man page.
...filed in 2006.

It'd be easy enough to fix, although this might be a library API change,
at least if we want to make blkid_get_cache() symmetric with
blkid_put_cache(), each taking a filename...

But it's been broken so long, with (few) complaints, is the
functionality worth resurrecting, or should I just submit a patch to
remove the -w option?  :)

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Dilger | 2 Mar 2008 19:51
Picon

Re: [RFC][PATCH] ext4: Convert uninitialized extent to initialized extent in case of file system full

On Mar 01, 2008  23:00 +0530, Aneesh Kumar K.V wrote:
> +/* FIXME!! we need to try to merge to left or right after zerout  */
> +static int ext4_ext_zeroout(struct inode *inode, struct ext4_extent *ex)
> +{
> +		done = 0;
> +		while(done < len) {
> +			ret = bio_add_page(bio, ZERO_PAGE(0), blocksize, 0);

Don't we need to set the page offset here?  

> Converting it to an API like above doesn't help much. How about 
> 
> int bio_zero_blocks(struct block_device *bdev, sector_t start, unsigned
> long bytes);
> 
> Here it implies that we would like to wait for zero out to finish.
> 
> Since we don't have another user now i didn't add the helper. But that
> should be easy.

Yes, this is probably fine too, though at that point you don't need to
have "bio" in the name since it is an internal implementation detail.

> > A related optimization is to determine the size of the remaining split
> > extents.  I propose that if either of the remaining extents are < 7
> > blocks long (or whatever, possibly 15 blocks to get a nice 64kB write) we
> > should just zero out those blocks and create a single initialized extent.
> > This would avoid the "write every alternate block" problem that could
> > grow the number of extents dramatically.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bas van Schaik | 2 Mar 2008 20:08
Picon

Re: e2fsck dies with error "this should never happen!!!"

Theodore Tso wrote:
> On Fri, Feb 22, 2008 at 08:31:13PM +0100, Bas van Schaik wrote:
>   
>>> Yeah, it could be quite big, given that you have a 3TB filesystem.  That's
>>> why I suggested the "or given me login access to the system", although
>>> understand there could be all sorts of privacy and security issues
>>> involved with that request.
>>>       
>> The dump is not ready yet...
>>
>> Whatever we will do, it will have to wait for a week and a half. For now I
>> really appreciate all the help.
>>     
> Ok, when you get back, I should also have a patch for you that will
> allow the "XXX should never happen" message to display more
> information, so if the dump is too big for us to move over the
> network, I'll have another way of doing some remote debugging.
>   
Last night I returned from my holiday trip, so I'm available again. The
e2image dump completed somewhere during my absence and has grown to 1.6
gigabytes (bzip2), too large to actually publish if you ask me. I think
it is okay to provide you access to the system, please contact me
(preferably using a GPG-encrypted message) so we can agree on the
details. Of course it would be great if you can send a patch which will
make e2fsck more verbose.

  -- Bas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 5 comments |
headers
Kalpak Shah | 2 Mar 2008 21:39
Picon

[PATCH] Tool to report free space fragmentation

Hi,

e2freefrag is a simple tool to report free space fragmentation on
ext2/3/4 filesystems. It a simple tool which goes through the block
bitmap reporting sizes of free chunks. By default chunksize of 1MB is
used, but a different chunksize can be given using a -c option.

It also reports the min/max/avg size of free chunks and a histogram of
all free chunks.

Here is the output of e2freefrag:
[kalpak <at> garfield e2fsprogs-1.40.7]# e2freefrag -c 1024 /dev/sda3
Device: /dev/sda3
Blocksize: 4096 bytes

Total blocks: 2560359
Free blocks: 603234 (23.6%)

Total chunks: 10002
Free chunks: 2074 (20.7%)

Min free chunk: 4 KB 
Max free chunk: 98276 KB
Avg. free chunk: 1952 KB

HISTOGRAM OF FREE CHUNK SIZES:
          Range         Free chunks
    4K...    8K- :         326
    8K...   16K- :         186
   16K...   32K- :         124
(Continue reading)

Permalink | Reply | 2 comments |

Gmane