Re: [RFC] [PATCH] Flex_BG ialloc awareness V2.
On Dec 07, 2007 09:52 -0600, Jose R. Santos wrote:
Andreas Dilger [EMAIL PROTECTED] wrote:
There is no particular reason that this ratio needs to be *100, it could
just as easily be a fraction of 256 and make the multiply into a shift.
The free_block_ratio would be 26 in that case.
The idea here is to reserve 10% (free_block_ratio) of free blocks in a
flexbg for allocation of new files and expansion of existing one. The
*100 make the math here easy but this still something that need to be
tune further. I'm sure we can do this in a series of shifts, just
haven't spent the time thinking of a clever way to do this.
This is a common misconception for code to have 10% mean 10 / 100. It
is just as good to have 26/256
@@ -622,7 +631,9 @@ struct ext4_super_block {
__le16 s_mmp_interval; /* # seconds to wait in MMP checking */
__le64 s_mmp_block;/* Block for multi-mount protection */
__le32 s_raid_stripe_width;/* blocks on all data disks (N*stride)*/
- __u32 s_reserved[163];/* Padding to the end of the block */
+ __le16 s_flex_bg_size; /* FLEX_BG group size */
Shouldn't this be s_flex_bg_bits?
I debated whether to store this as the s_flex_bg_size and calculate the
bits during the filesystem mount time or just stored the bit in the
super block to begging with. The reason I stored the size is that it
seemed more in line with the other fields in the super block. I don't
mind either way since this is more of a style issue, although saving an
extra 8bits in the super block may be good enough reason to change it.
I'd think being able to avoid the divide for every inode allocation is more
important than 8 bits in the superblock.
My preference would be to have if (EXT2_HAS_INCOMPAT...) { ... } else {
(i.e. add { } for the first part) since there are { } on the second part,
and it is just easier to read.
Mine too, but checkpatch complained about this. :)
Time to fix checkpatch it would seem.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
-
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
Re: [RFC] [PATCH] Flex_BG ialloc awareness V2.
On Tue, 11 Dec 2007 04:00:33 -0700
Andreas Dilger [EMAIL PROTECTED] wrote:
On Dec 07, 2007 09:52 -0600, Jose R. Santos wrote:
Andreas Dilger [EMAIL PROTECTED] wrote:
There is no particular reason that this ratio needs to be *100, it could
just as easily be a fraction of 256 and make the multiply into a shift.
The free_block_ratio would be 26 in that case.
The idea here is to reserve 10% (free_block_ratio) of free blocks in a
flexbg for allocation of new files and expansion of existing one. The
*100 make the math here easy but this still something that need to be
tune further. I'm sure we can do this in a series of shifts, just
haven't spent the time thinking of a clever way to do this.
This is a common misconception for code to have 10% mean 10 / 100. It
is just as good to have 26/256
I understand that part, but my point is that changing the multiply to
256 doesn't do anything to eliminate the divide by blocks_per_flex.
Give that is more common to have an arch with no divide instruction
than one with no multiply, it seems more important to take care of the
divide by blocks_per_flex rather than the multiply by 100.
We could store the blocks_per_flex_bits in the sbi to do this but the
last flexbg is not guarantied to be the same size as the other flexbg
so it needs to be treated differently.
Hum... Now that I think of it, the last flexbg is not treated
differently on the current patch either. Looks like I found a bug. :)
@@ -622,7 +631,9 @@ struct ext4_super_block {
__le16 s_mmp_interval; /* # seconds to wait in MMP
checking */
__le64 s_mmp_block;/* Block for multi-mount
protection */
__le32 s_raid_stripe_width;/* blocks on all data disks
(N*stride)*/
- __u32 s_reserved[163];/* Padding to the end of the
block */
+ __le16 s_flex_bg_size; /* FLEX_BG group size */
Shouldn't this be s_flex_bg_bits?
I debated whether to store this as the s_flex_bg_size and calculate the
bits during the filesystem mount time or just stored the bit in the
super block to begging with. The reason I stored the size is that it
seemed more in line with the other fields in the super block. I don't
mind either way since this is more of a style issue, although saving an
extra 8bits in the super block may be good enough reason to change it.
I'd think being able to avoid the divide for every inode allocation is more
important than 8 bits in the superblock.
We already avoid the divide since what we store in the sbi IS the bits
which are calculated at mount time for each fs. Base on the other
fields in the super block struct, I decided to put explicit size of the
flexbg in the super block. The kernel code can decide how best to use
that number which in this case its used to calculate the number of bits
in order to avoid doing divides.
So this is really a styling issue in how to record data in the super
block. The only technical issue with this is whether it's important to
save those extra 8 bits in the super block struct.
My preference would be to have if (EXT2_HAS_INCOMPAT...) { ... } else {
(i.e. add { } for the first part) since there are { } on the second part,
and it is just easier to read.
Mine too, but checkpatch complained about this. :)
Time to fix checkpatch it would seem.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
-JRS
-
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
Re: [Bug 9546] New: Huge latency in concurrent I/O when using data=ordered
(switching to email - please respond via emailed reply-to-all, not via the bugzilla web interface) On Tue, 11 Dec 2007 11:36:39 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9546 Summary: Huge latency in concurrent I/O when using data=ordered Product: File System Version: 2.5 KernelVersion: 2.6.24-rc4 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: ext3 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: Unknown, certainly not a regression, but something specific to ext3 algorithm Distribution: Bluewhite64 12 (Slackware 12 64 bits port) and Slackware 12 Hardware Environment: Athlon 64 3000+laptop IDE 5400 80GB+1.2GB RAM Athlon 64X2 4200+SATA 7200 200GB drive+1GB Athlon 2800+IDE 7200 40GB drive+512MB Software Environment: dd, cp, konqueror/KDE, mount/tune2fs Problem Description: When the system does heavy input/output operations on big files, small files access from other applications are always not served for very long time. This can cause huge latencies. The system is really not usable at all, even with all the recent improvements done to increase interactivity on desktop. This behaviour is very visible with the simple following test case: 1. Build a DVD structure from big MPEG+PS files with dvdauthor (it copies the files in the DVD stucture, then pass on them to fix VOBUs, but this part is not very long so this is not the main problem). 2. While the computer is doing this, try to open a web browser such as konqueror. Then open a page from bookmark. Then open a new tab, then open another page from bookmark. Switch bak to first page. What I get is: 35 seconds to open Konqueror. 8 seconds to open the bookmark menu. Incredible. 30 seconds to open the web page (DSL/10GBits). 5 seconds to open the second tab. 6 seconds to reopen the menu. 36 seconds to open the second page. 14 seconds to come back to first tab. This is unbelievable! The system is completely trashed, with more than 1GB RAM, whatever the hardware configuration is used. Of course, I investigated the problem... First, DMA is OK. Second, I thought cache would make memory swapped. So I used echo 0 swapiness. Then (of course, the system was not swapping at all), I thought TEXT sections from software discarded (that would be simply stupid, but who knows?). I then tried to make the writing process throttled with dirty_background_ratio (say 10%) while reserving a greater RAM portion for the rest of the system with dirty_ratio (say 70%). No way. Then I launched top, and looked at the WCHAN to see what was the problem for the frozen process (ie: konqueror). The I saw the faulty guy: log_wait_commit! So I concluded there is unfair access to the filesystem journal. So I tried other journaling options than the default ordered data mode. The results were really different: 5s, 2s, 4s, etc., both with journal and write back mode! I therefore think there is a great lock and even maybe a priority inversion in log_wait_commit of the ext3 filesystem. I think that, even if it is throttled, the writing process always get access to the journal in ordered mode, simply because it writes many pages at a time and because the ordered mode indeed implies... ordering of requests (as I understand it). It's sad this is the default option that gives the worst interactivity problems. Indeed, this messes all previous work done to enhance desktop experience I think, too bad! Btw, I've also seen on Internet that some people reported that journal data mode gives better performance. I think the problem was indeed related to latency rather than performance (timing the writing process effectively shows a output rate halved with journal data mode, and twice the time to process). Steps to reproduce: I did a simple script: #!/bin/bash SRC1=src1.bin SRC2=src2.bin DEST_DIR=tmpdir DST1=dst.bin # First, create the source files: if [ ! -e $SRC1 ] ; then dd if=/dev/zero of=$SRC1 bs=10k count=15 fi if [ ! -e $SRC2 ] ; then dd if=/dev/zero of=$SRC2 bs=10k count=15 fi mkdir $DEST_DIR /dev/null 21 sync # Do the test: echo Trashing the system... rm $DEST_DIR/$DST1 /dev/null 21 cp $SRC1 $DEST_DIR/$DST1 cat $SRC2 $DEST_DIR/$DST1 echo 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 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 ext2 also doesn't exhibit the problem. Interesting that data=writeback helped this. You don't
Re: [Bug 9546] New: Huge latency in concurrent I/O when using data=ordered
OK for reply to all. I'm using the first mail received. Interesting that data=writeback helped this. You don't give a lot of details, but I assume that data=writeback made a large difference here? Well, my measures were taken by counting seconds from the desktop clock, so the precision is roughly 1s. Here are the effective results from the 3 journaling modes I have done yesterday : Times in seconds: ordered mode : 17 5 38 19 33 journal mode : 6 1 5 6 5 writeback mode :4 1 7 6 8 I do not remember exactly the operation sequence, but the beginning was opening Konqueror, opening the bookmarks menu, loading a page, and opening another tab. As you can see anyway, ordered is completely broken, opening the menu is near 1s in journal and writeback mode, which is perfectly acceptable for a user (after all, the computer is loaded, and interactivity is not simply running interactive tasks at real time priority, so the the user can understand it reacts slower). Launching Konqueror in 4 to 6 seconds is a good time, given that the cache is poisoned by the writing process. Opening another tab or a web page is tolerable within 5-6s, even if this is still a little too long, specially for opening another tab of an already running process (2-3s would be a perfect value I think, but this is another story to get this). Certainly 5-6s of latency is due to the block size used by the writing process, and tuning the kernel to get lower results would be dangerous for general performances. I could do tests by asking dd to write more but smaller blocks to check this idea. As far as writeback is concerned, the latency reduction was not clear as you can see, at least with my mesurement procedure. For performance of the **writing process**, it was nearly the same as ordered. I havn't written the timings results for the writing process, since I was still investigating at that time. But I used : time dowrite.sh to time it, and I got real time, as well as dd output (records written, MB/s, and journal was half as ordered). So writeback and ordered seemed the same at this level, and journal mode was effectively twice slower. It was clear there was twice as most write operations, that was the expected behaviour. I could redo the tests, with a more formal approach (that is: fixing the operations order done in Konqueror, and noting the times for the writing process), it's easy. In fact, I'm considering doing another script simulating Konqueror / user activities and timing them automatically, just to get a reproduceable benchmark suite. Please note that not all programs are affected (for instance kmail was quite quick), so the kernel does a good job to run programs that do not many I/Os when the fs is stressed by another process. The difference with konqueror is it is opening several files (block dump says), so my guess is that processes doing small I/O operations are not given journal access fairly enough in ordered mode. Indeed, I imagine (without knowing any internals of course) that the data writing is indeed scheduled correctly by the disk scheduler, and that the writing process is throttled, but the priority informations are lost when metadata are written in ordered mode, because all I/Os are mixed for metadata. Therefore, the writing process manages to fill the journal quite easily. With journal and writeback mode, all data may be written sequentially, in the context of the issuing process, so priorities may be tracked on the whole writing process. Then the writing process is prempted correctly to the benefits of Konqueror. This is of course just black box hypothesis... CC - 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
Re: [RFC] [PATCH] Flex_BG ialloc awareness V2.
On Dec 11, 2007 10:08 -0600, Jose R. Santos wrote: I'd think being able to avoid the divide for every inode allocation is more important than 8 bits in the superblock. We already avoid the divide since what we store in the sbi IS the bits which are calculated at mount time for each fs. Base on the other fields in the super block struct, I decided to put explicit size of the flexbg in the super block. The kernel code can decide how best to use that number which in this case its used to calculate the number of bits in order to avoid doing divides. So this is really a styling issue in how to record data in the super block. The only technical issue with this is whether it's important to save those extra 8 bits in the super block struct. Well, if it is stored in the superblock as a non-power-of-two value, then there always exists the possibility that it is set incorrectly (maybe by a version of mke2fs that doesn't verify this) and the code will not do the right thing. Storing it in bits (as is done with e.g. s_log_block_size and s_log_frag_size) ensures there is no possibility of a value that isn't a power-of-two. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. - 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
+ ext-use-ext_get_group_desc.patch added to -mm tree
The patch titled
ext[234]: use ext[234]_get_group_desc()
has been added to the -mm tree. Its filename is
ext-use-ext_get_group_desc.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 what to do about this
--
Subject: ext[234]: use ext[234]_get_group_desc()
From: Akinobu Mita [EMAIL PROTECTED]
Use ext[234]_get_group_desc() to get group descriptor from group number.
Cc: linux-ext4@vger.kernel.org
Signed-off-by: Akinobu Mita [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
fs/ext2/super.c | 12
fs/ext3/super.c | 13 -
fs/ext4/super.c | 14 --
3 files changed, 12 insertions(+), 27 deletions(-)
diff -puN fs/ext2/super.c~ext-use-ext_get_group_desc fs/ext2/super.c
--- a/fs/ext2/super.c~ext-use-ext_get_group_desc
+++ a/fs/ext2/super.c
@@ -617,27 +617,24 @@ static int ext2_setup_super (struct supe
return res;
}
-static int ext2_check_descriptors (struct super_block * sb)
+static int ext2_check_descriptors(struct super_block *sb)
{
int i;
- int desc_block = 0;
struct ext2_sb_info *sbi = EXT2_SB(sb);
unsigned long first_block = le32_to_cpu(sbi-s_es-s_first_data_block);
unsigned long last_block;
- struct ext2_group_desc * gdp = NULL;
ext2_debug (Checking group descriptors);
- for (i = 0; i sbi-s_groups_count; i++)
- {
+ for (i = 0; i sbi-s_groups_count; i++) {
+ struct ext2_group_desc *gdp = ext2_get_group_desc(sb, i, NULL);
+
if (i == sbi-s_groups_count - 1)
last_block = le32_to_cpu(sbi-s_es-s_blocks_count) - 1;
else
last_block = first_block +
(EXT2_BLOCKS_PER_GROUP(sb) - 1);
- if ((i % EXT2_DESC_PER_BLOCK(sb)) == 0)
- gdp = (struct ext2_group_desc *)
sbi-s_group_desc[desc_block++]-b_data;
if (le32_to_cpu(gdp-bg_block_bitmap) first_block ||
le32_to_cpu(gdp-bg_block_bitmap) last_block)
{
@@ -667,7 +664,6 @@ static int ext2_check_descriptors (struc
return 0;
}
first_block += EXT2_BLOCKS_PER_GROUP(sb);
- gdp++;
}
return 1;
}
diff -puN fs/ext3/super.c~ext-use-ext_get_group_desc fs/ext3/super.c
--- a/fs/ext3/super.c~ext-use-ext_get_group_desc
+++ a/fs/ext3/super.c
@@ -1252,28 +1252,24 @@ static int ext3_setup_super(struct super
}
/* Called at mount-time, super-block is locked */
-static int ext3_check_descriptors (struct super_block * sb)
+static int ext3_check_descriptors(struct super_block *sb)
{
struct ext3_sb_info *sbi = EXT3_SB(sb);
ext3_fsblk_t first_block = le32_to_cpu(sbi-s_es-s_first_data_block);
ext3_fsblk_t last_block;
- struct ext3_group_desc * gdp = NULL;
- int desc_block = 0;
int i;
ext3_debug (Checking group descriptors);
- for (i = 0; i sbi-s_groups_count; i++)
- {
+ for (i = 0; i sbi-s_groups_count; i++) {
+ struct ext3_group_desc *gdp = ext3_get_group_desc(sb, i, NULL);
+
if (i == sbi-s_groups_count - 1)
last_block = le32_to_cpu(sbi-s_es-s_blocks_count) - 1;
else
last_block = first_block +
(EXT3_BLOCKS_PER_GROUP(sb) - 1);
- if ((i % EXT3_DESC_PER_BLOCK(sb)) == 0)
- gdp = (struct ext3_group_desc *)
- sbi-s_group_desc[desc_block++]-b_data;
if (le32_to_cpu(gdp-bg_block_bitmap) first_block ||
le32_to_cpu(gdp-bg_block_bitmap) last_block)
{
@@ -1306,7 +1302,6 @@ static int ext3_check_descriptors (struc
return 0;
}
first_block += EXT3_BLOCKS_PER_GROUP(sb);
- gdp++;
}
sbi-s_es-s_free_blocks_count=cpu_to_le32(ext3_count_free_blocks(sb));
diff -puN fs/ext4/super.c~ext-use-ext_get_group_desc fs/ext4/super.c
--- a/fs/ext4/super.c~ext-use-ext_get_group_desc
+++ a/fs/ext4/super.c
@@ -1447,7 +1447,7 @@ int ext4_group_desc_csum_verify(struct e
}
/* Called at mount-time, super-block is locked */
-static int ext4_check_descriptors (struct super_block * sb)
+static int ext4_check_descriptors(struct super_block *sb)
{
struct ext4_sb_info *sbi = EXT4_SB(sb);
ext4_fsblk_t first_block = le32_to_cpu(sbi-s_es-s_first_data_block);
@@ -1455,8 +1455,6 @@ static int ext4_check_descriptors (struc
ext4_fsblk_t block_bitmap;
ext4_fsblk_t inode_bitmap;
ext4_fsblk_t inode_table;
- struct ext4_group_desc * gdp = NULL;
- int desc_block =
+ ext-fix-comment-for-nonexistent-variable.patch added to -mm tree
The patch titled
ext[234]: fix comment for nonexistent variable
has been added to the -mm tree. Its filename is
ext-fix-comment-for-nonexistent-variable.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 what to do about this
--
Subject: ext[234]: fix comment for nonexistent variable
From: Akinobu Mita [EMAIL PROTECTED]
The comment in ext[234]_new_blocks() describes about i. But there is no
local variable called i in that scope. I guess it has been renamed to
group_no.
Cc: linux-ext4@vger.kernel.org
Signed-off-by: Akinobu Mita [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
fs/ext2/balloc.c |4 ++--
fs/ext3/balloc.c |2 +-
fs/ext4/balloc.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff -puN fs/ext2/balloc.c~ext-fix-comment-for-nonexistent-variable
fs/ext2/balloc.c
--- a/fs/ext2/balloc.c~ext-fix-comment-for-nonexistent-variable
+++ a/fs/ext2/balloc.c
@@ -1315,8 +1315,8 @@ retry_alloc:
smp_rmb();
/*
-* Now search the rest of the groups. We assume that
-* i and gdp correctly point to the last group visited.
+* Now search the rest of the groups. We assume that
+* group_no and gdp correctly point to the last group visited.
*/
for (bgi = 0; bgi ngroups; bgi++) {
group_no++;
diff -puN fs/ext3/balloc.c~ext-fix-comment-for-nonexistent-variable
fs/ext3/balloc.c
--- a/fs/ext3/balloc.c~ext-fix-comment-for-nonexistent-variable
+++ a/fs/ext3/balloc.c
@@ -1572,7 +1572,7 @@ retry_alloc:
/*
* Now search the rest of the groups. We assume that
-* i and gdp correctly point to the last group visited.
+* group_no and gdp correctly point to the last group visited.
*/
for (bgi = 0; bgi ngroups; bgi++) {
group_no++;
diff -puN fs/ext4/balloc.c~ext-fix-comment-for-nonexistent-variable
fs/ext4/balloc.c
--- a/fs/ext4/balloc.c~ext-fix-comment-for-nonexistent-variable
+++ a/fs/ext4/balloc.c
@@ -1703,7 +1703,7 @@ retry_alloc:
/*
* Now search the rest of the groups. We assume that
-* i and gdp correctly point to the last group visited.
+* group_no and gdp correctly point to the last group visited.
*/
for (bgi = 0; bgi ngroups; bgi++) {
group_no++;
_
Patches currently in -mm which might be from [EMAIL PROTECTED] are
git-net.patch
git-battery.patch
fs-use-hlist_unhashed.patch
fs-use-list_for_each_entry_reverse-and-kill-sb_entry.patch
ext-fix-comment-for-nonexistent-variable.patch
ext-use-ext_get_group_desc.patch
ext-remove-unused-argument-for-ext_find_goal.patch
-
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
+ ext-cleanup-ext_bg_num_gdb.patch added to -mm tree
The patch titled
ext[234]: cleanup ext[234]_bg_num_gdb()
has been added to the -mm tree. Its filename is
ext-cleanup-ext_bg_num_gdb.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 what to do about this
--
Subject: ext[234]: cleanup ext[234]_bg_num_gdb()
From: Akinobu Mita [EMAIL PROTECTED]
Use ext[234]_bg_has_super() to remove duplicate code.
Signed-off-by: Akinobu Mita [EMAIL PROTECTED]
Cc: linux-ext4@vger.kernel.org
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
fs/ext2/balloc.c |5 +
fs/ext3/balloc.c |6 +-
fs/ext4/balloc.c |6 +-
3 files changed, 3 insertions(+), 14 deletions(-)
diff -puN fs/ext2/balloc.c~ext-cleanup-ext_bg_num_gdb fs/ext2/balloc.c
--- a/fs/ext2/balloc.c~ext-cleanup-ext_bg_num_gdb
+++ a/fs/ext2/balloc.c
@@ -1533,9 +1533,6 @@ int ext2_bg_has_super(struct super_block
*/
unsigned long ext2_bg_num_gdb(struct super_block *sb, int group)
{
- if (EXT2_HAS_RO_COMPAT_FEATURE(sb,EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER)
- !ext2_group_sparse(group))
- return 0;
- return EXT2_SB(sb)-s_gdb_count;
+ return ext2_bg_has_super(sb, group) ? EXT2_SB(sb)-s_gdb_count : 0;
}
diff -puN fs/ext3/balloc.c~ext-cleanup-ext_bg_num_gdb fs/ext3/balloc.c
--- a/fs/ext3/balloc.c~ext-cleanup-ext_bg_num_gdb
+++ a/fs/ext3/balloc.c
@@ -1848,11 +1848,7 @@ static unsigned long ext3_bg_num_gdb_met
static unsigned long ext3_bg_num_gdb_nometa(struct super_block *sb, int group)
{
- if (EXT3_HAS_RO_COMPAT_FEATURE(sb,
- EXT3_FEATURE_RO_COMPAT_SPARSE_SUPER)
- !ext3_group_sparse(group))
- return 0;
- return EXT3_SB(sb)-s_gdb_count;
+ return ext3_bg_has_super(sb, group) ? EXT3_SB(sb)-s_gdb_count : 0;
}
/**
diff -puN fs/ext4/balloc.c~ext-cleanup-ext_bg_num_gdb fs/ext4/balloc.c
--- a/fs/ext4/balloc.c~ext-cleanup-ext_bg_num_gdb
+++ a/fs/ext4/balloc.c
@@ -2017,11 +2017,7 @@ static unsigned long ext4_bg_num_gdb_met
static unsigned long ext4_bg_num_gdb_nometa(struct super_block *sb,
ext4_grpnum_t group)
{
- if (EXT4_HAS_RO_COMPAT_FEATURE(sb,
- EXT4_FEATURE_RO_COMPAT_SPARSE_SUPER)
- !ext4_group_sparse(group))
- return 0;
- return EXT4_SB(sb)-s_gdb_count;
+ return ext4_bg_has_super(sb, group) ? EXT4_SB(sb)-s_gdb_count : 0;
}
/**
_
Patches currently in -mm which might be from [EMAIL PROTECTED] are
git-net.patch
git-battery.patch
fs-use-hlist_unhashed.patch
fs-use-list_for_each_entry_reverse-and-kill-sb_entry.patch
ext-fix-comment-for-nonexistent-variable.patch
ext-use-ext_get_group_desc.patch
ext-remove-unused-argument-for-ext_find_goal.patch
ext-cleanup-ext_bg_num_gdb.patch
-
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
