headers
Robin Dong | 1 Feb 2012 04:17
Picon

[PATCH] ext4: s_dirtyclusters_counter should tranform to unit of cluster before assigning to "dirty_clusters" in ext4_has_free_clusters()

From: Robin Dong <sanbai <at> taobao.com>

Creating 4-byte files until ENOSPC in a delay-allocation and bigalloc ext4 fs and then sync it, the dmseg
will report like:

	[  482.154538] EXT4-fs (sdb6): delayed block allocation failed for inode 1664 at logical offset 0 with max
blocks 1 with error -28
	[  482.154540] EXT4-fs (sdb6): This should not happen!! Data will be lost

The reason is ext4_has_free_clusters reporting wrong result. Actually, the unit of
sbi->s_dirtyclusters_counter is block, so we should tranform it to cluster for argument
"dirty_clusters", just like "free_clusters".

Cc: "Theodore Ts'o" <tytso <at> mit.edu>
Reported-by: Eric Sandeen <sandeen <at> redhat.com>
Signed-off-by: Robin Dong <sanbai <at> taobao.com>
---
 fs/ext4/balloc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
index f9e2cd8..8ff10c4 100644
--- a/fs/ext4/balloc.c
+++ b/fs/ext4/balloc.c
 <at>  <at>  -427,7 +427,7  <at>  <at>  static int ext4_has_free_clusters(struct ext4_sb_info *sbi,
 	if (free_clusters - (nclusters + root_clusters + dirty_clusters) <
 					EXT4_FREECLUSTERS_WATERMARK) {
 		free_clusters  = EXT4_C2B(sbi, percpu_counter_sum_positive(fcc));
-		dirty_clusters = percpu_counter_sum_positive(dcc);
+		dirty_clusters = EXT4_C2B(sbi, percpu_counter_sum_positive(dcc));
(Continue reading)

Permalink | Reply | 6 comments |
headers
Dave Chinner | 1 Feb 2012 04:57

Re: [RFC] Add new extent structure in ext4

On Mon, Jan 30, 2012 at 03:50:24PM -0700, Andreas Dilger wrote:
> On 2012-01-29, at 3:07 PM, Dave Chinner wrote:
> > yet all I see is people trying to make it something for big, bigger
> > and biggest. Bigalloc, new extent formats, no-journal mode,
> > dioread_nolock, COW snapshots, secure delete, etc. It's a list of
> > features that are somewhat incompatible with each other that are
> > useful to only a handful of vendors or companies. Most have no
> > relevance at all to the uses of the majority of ext4 users.
> 
> ???  This is quickly degrading into a mud slinging match.  You claim
> that "because ext4 is only relevant for desktops, it shouldn't try to
> scale or improve performance".  Should I similarly claim that "because
> XFS is only relevant to gigantic SMP systems with huge RAID arrays it
> shouldn't try to improve small file performance or be CPU efficient"?

You can if you want.....

But then I'll just point to Eric Whitney's latest results showing
XFS is generally slightly more CPU efficient that ext4, and performs
as well as ext4 on the small file workload he ran. :)

> Not at all.  The ext4 users and developers choose it because it meets
> their needs better than XFS for one reason or another, and we will

More likely is that most desktop users choose ext4 because it is the
default filesystem their distribution installs, not because they
know anything about it or any other linux filesystem....

> continue to improve it for everyone while we are interested to do so.
> The ext4 multi-block allocator was originally done for high-throughput
(Continue reading)

Permalink | Reply | 0 comments |
headers
Theodore Ts'o | 1 Feb 2012 05:46
Picon
Picon
Favicon
Gravatar

Ext4 developer's workshop website is now up


Hi there,

I've put together a quick website for the ext4 developer's workshop:

	https://sites.google.com/site/ext4workshop2012/

Please fill out the registration form on that site if you are planning
on attending.

Also, please note that the deadline for requesting an invite to the LSF
Workshop is coming up quickly: this coming Sunday (February 5th).  So
you should get your topic suggestions or request to attend to the LSF
program committee this week!

						- Ted
--
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
Permalink | Reply | 3 comments |
headers
Sainsburys Finance | 1 Feb 2012 07:30
Picon

LOAN OFFER............AT 3% INTEREST RATE

Attn,

We give out loans within the range of $5,000 and above with an interest rate of 3%. Our loans are well insured
for maximum security is our priority. Sainsburys Finance is a leading online provider of finance.

Lender's Name: Mr.Kester Switch
Tel Number:  +44 701 117 3877
Fax Number:  +44 871 503 5094
Lender's Email: sainsburysfinance <at> zing.vn

Interested applicants are advice to get back to us via email for our application
form.

Regards
Mrs Cherry Anderson
Sainsburys Finance.

--
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
Permalink | Reply | 0 comments |
headers
Tao Ma | 1 Feb 2012 08:26

Re: Delayed Extent Tree and Extent Lock Tree

Hi Allison,
On 02/01/2012 06:33 AM, Allison Henderson wrote:
> Hi Yongqiang,
> 
> I've have been working on an extent lock implementation that uses an
> rbtree to keep track of locked extents, and I think I will probably end
> up with a something similar to the tree that you've already set up for
> delayed extents.  So I wanted to send a note out to see what folks would
> think about the idea of merging the two solutions.
> 
> If we did this, the tree would get a little more complex in that it
> would have to keep track of more than just delayed extents. It would
> have to keep track of all extents and the processes that are waiting on
> them.  So I guess it would kind of turn into an extent status tree.  I
> also realize that some folks wanted to see range locks go into /lib as
> general purpose code so that other filesystems or kernel code could use
> it too, but the advantage to this approach would be one less tree for
> ext4 to keep track of.  Any thoughts?
We (Taobao) are very interested in this stuff and it should benefit
several of our workload(It is on our todo list for a long time). I guess
Yongqiang's solution is a little bit limited to the only delayed extent
case, and your new solution at least has 2 more benefits:
1. improve the direct i/o read/write
2. speed up the extent search since now we only cache one in
ei_cached_extent.

So please go ahead with your new solution. btw, do you have any timeline
for it? We are glad to provide any help if needed.

Thanks
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kazuya Mio | 1 Feb 2012 08:56
Picon

Re: [PATCH 2/2] ext3: Don't update ctime in ext3_splice_branch()

2012/01/31 2:52, Jan Kara wrote:
>   Thanks for the patches.  This is true for ordinary writes but not true
> when you write via mmap. We call file_update_time() during page fault so
> ctime won't be completely wrong but still we should update it after block
> is allocated during writeback to reflect that new block is allocated to
> the inode.

Should we update ctime whenever a block is allocated?
If so, ordinary write in ext4 with indirect block mapping has the same problem
due to the following patch, right?
http://marc.info/?l=linux-ext4&m=124505184027078&w=4

Regards,
Kazuya Mio
--
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
Permalink | Reply | 2 comments |
headers
Kazuya Mio | 1 Feb 2012 09:35
Picon

Re: [PATCH 0/2] ext3: Reduce calling ext3_mark_inode_dirty() for speedup

2012/01/31 5:36, Andreas Dilger wrote:
> Can you please run this same measurement on ext4 formatted and running
> with the default options?  I'd like to know if this is still a problem
> in ext4 or not.

I performed the same measurement on ext4 with the default options.
Here is its result:

    filesystem        time(sec)  call extX_mark_inode_dirty(times)
    ---
    ext3              220.5      50,338,104
    ext3 (patched)    196.3      25,169,658
    ext4 (*1)         190.3      28,465,799
    ext4 (*2)         201.5      27,963,473
    ext4 (default)    223.3      14,026,118

    *1 disable ext4-specific options (delalloc, extent, and so on)
    *2 disable only delalloc option

Regards,
Kazuya Mio
--
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
Permalink | Reply | 4 comments |
headers
Jan Kara | 1 Feb 2012 11:46
Picon

Re: [PATCH 2/2] ext3: Don't update ctime in ext3_splice_branch()

On Wed 01-02-12 16:56:17, Kazuya Mio wrote:
> 2012/01/31 2:52, Jan Kara wrote:
> >  Thanks for the patches.  This is true for ordinary writes but not true
> >when you write via mmap. We call file_update_time() during page fault so
> >ctime won't be completely wrong but still we should update it after block
> >is allocated during writeback to reflect that new block is allocated to
> >the inode.
> 
> Should we update ctime whenever a block is allocated?
  Since ctime should be updated whenever inode is changed, and allocating
block updates i_blocks (via dquot_alloc_block()), we should update ctime.

> If so, ordinary write in ext4 with indirect block mapping has the same problem
> due to the following patch, right?
> http://marc.info/?l=linux-ext4&m=124505184027078&w=4
  It's kind of the same problem. But things are more complicated by the
fact that ext4 also does delayed allocation so, as changelog of the patch
you reference says, it's kind of unexpected from users to see ctime
suddently update when VM decides to do writeout triggering block
allocation. I'd think updating ctime is a correct (although unexpected)
thing to do but I can understand Ted's position as well and he's ext4
maintainer :).

								Honza
--

-- 
Jan Kara <jack <at> suse.cz>
SUSE Labs, CR
--
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 | 1 comment |
headers
Andreas Dilger | 1 Feb 2012 18:47
Picon

Re: Delayed Extent Tree and Extent Lock Tree

On 2012-02-01, at 12:26 AM, Tao Ma wrote:
> On 02/01/2012 06:33 AM, Allison Henderson wrote:
>> Hi Yongqiang,
>> 
>> I've have been working on an extent lock implementation that uses an
>> rbtree to keep track of locked extents, and I think I will probably end
>> up with a something similar to the tree that you've already set up for
>> delayed extents.  So I wanted to send a note out to see what folks would
>> think about the idea of merging the two solutions.
>> 
>> If we did this, the tree would get a little more complex in that it
>> would have to keep track of more than just delayed extents. It would
>> have to keep track of all extents and the processes that are waiting on
>> them.  So I guess it would kind of turn into an extent status tree.  I
>> also realize that some folks wanted to see range locks go into /lib as
>> general purpose code so that other filesystems or kernel code could use
>> it too, but the advantage to this approach would be one less tree for
>> ext4 to keep track of.  Any thoughts?
> 
> We (Taobao) are very interested in this stuff and it should benefit
> several of our workload(It is on our todo list for a long time). I guess
> Yongqiang's solution is a little bit limited to the only delayed extent
> case, and your new solution at least has 2 more benefits:
> 1. improve the direct i/o read/write
> 2. speed up the extent search since now we only cache one in
> ei_cached_extent.

Another related usage is to use a tree to track free extents in the
block allocation bitmaps.  We already have a thread starting at mount
time to do itable_init, and it would be possible to have that same
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ric Wheeler | 1 Feb 2012 21:44
Picon

Re: Ext4 developer's workshop website is now up

On 01/31/2012 11:46 PM, Theodore Ts'o wrote:
> Hi there,
>
> I've put together a quick website for the ext4 developer's workshop:
>
> 	https://sites.google.com/site/ext4workshop2012/
>
> Please fill out the registration form on that site if you are planning
> on attending.
>
> Also, please note that the deadline for requesting an invite to the LSF
> Workshop is coming up quickly: this coming Sunday (February 5th).  So
> you should get your topic suggestions or request to attend to the LSF
> program committee this week!
>
> 						- Ted
>

Thanks for putting this together!

One question, any chance to pull it back closer in to LSF or have it on one of 
the collab summit days? Having it take place on the Friday adds several hotel 
nights I suspect for non-locals (and significant cost)....

Ric

--
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 | 2 comments |

Gmane