Bug#654206: [PATCH] ext4: Report max_batch_time option correctly
On 1/2/12 8:13 AM, Ben Hutchings wrote:
Currently the value reported for max_batch_time is really the
value of min_batch_time.
Reported-by: Russell Coker russ...@coker.com.au
Signed-off-by: Ben Hutchings b...@decadent.org.uk
whoops, yep!
Reviewed-by: Eric Sandeen sand...@redhat.com
---
fs/ext4/super.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 3e1329e..410e993 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1096,7 +1096,7 @@ static int ext4_show_options(struct seq_file *seq,
struct vfsmount *vfs)
}
if (sbi-s_max_batch_time != EXT4_DEF_MAX_BATCH_TIME) {
seq_printf(seq, ,max_batch_time=%u,
-(unsigned) sbi-s_min_batch_time);
+(unsigned) sbi-s_max_batch_time);
}
/*
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f0322d0.2070...@redhat.com
Bug#423562: problems with XFS on armel
On Nov 24, 2009, at 5:50 PM, Aníbal Monsalve Salazar ani...@debian.org wrote: On Tue, Nov 24, 2009 at 10:41:31PM +, Martin Michlmayr wrote: On Tue, Nov 24, 2009 at 06:02:02PM -0400, Mark J. Small wrote: My kernel is linux-image-2.6.30-2-kirkwood_2.6.30-8+orion1_armel.deb from http://people.debian.org/~tbm/orion/. I'll happily supply any other info that would help track this down. Please help me get reliable XFS on this armel box. I'm sorry but XFS is known to be broken on ARM. A fix was proposed recently but it doesn't seem to work: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423562 Maybe the XFS folks could help. Mark's post is available at: http://lists.debian.org/debian-arm/2009/11/msg00103.html The never ending arm vs xfs battle... And arm keeps winning :) I hope to be able to look into this next week... -Eric -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Martin Michlmayr wrote: Eric, Do you know what the status is of your XFS patch to make it work on ARM (old ABI)? It was just recently added to the xfs cvs tree. Message to the list was TAKE 982930 - fix dir2 shortform structures on ARM old ABI -Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: Info received (Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm)
Lennert Buytenhek wrote: Yep. Padding rules on old-ABI ARM systems are 'special', but still spec-compliant. See: Thanks, I've read up a bit since, and I think I grok it now :) So, adding __attribute__((packed)) to xfs_dir2_sf_off_t, xfs_dir2_sf_hdr_t, and perhaps also xfs_dir2_sf_entry_t might fix things? The xfstest suite is pretty good, if anyone would like to run through it on arm with the above packed structures... -Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Root cause seems to be gcc misaligning the xfs shortform directory
structures. In the example below, bar.parent has offset 4, while
boo.parent has offset 2. The union seems to cause extra padding - I
believe c should be at offset 2 in both structures.
This is leading to trouble in xfs_dir2_sf_hdr_t and others, and is
unfortunately leading to on-disk corruption, I think. The patch that's
been floating around to fix this probably only masks the problem, by
accommodating the extra padding when calculating sizes.
#include stdio.h
struct bar {
unsigned char a;
unsigned char b;
union {
unsigned char x;
unsigned char y;
} c;
};
struct boo {
unsigned char a;
unsigned char b;
unsigned char c;
};
#define offsetof(TYPE, MEMBER) ((size_t) ((TYPE *)0)-MEMBER)
int main(int argc, char ** argv) {
printf(a: %d\n, offsetof(struct bar, a));
printf(b: %d\n, offsetof(struct bar, b));
printf(c: %d\n, offsetof(struct bar, c));
printf(a: %d\n, offsetof(struct boo, a));
printf(b: %d\n, offsetof(struct boo, b));
printf(c: %d\n, offsetof(struct boo, c));
return 0;
}
[EMAIL PROTECTED]:~$ ./gcc-test
a: 0
b: 1
c: 4
a: 0
b: 1
c: 2
[EMAIL PROTECTED]:~$ gcc -v
Using built-in specs.
Target: arm-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
arm-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
[EMAIL PROTECTED]:~$ uname -a
Linux all6500-arm 2.6.18-4-iop32x #1 Thu Feb 22 03:51:25 UTC 2007
armv5tel GNU/Linux
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: Info received (Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm)
Maybe the alignment isn't broken; it's just special - I guess there are no actual rules on how the structure must be aligned... hmm... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414932: linux-image-2.6.18-4-ixp4xx: xfs partition from x86 system can not be used on arm
Martin Michlmayr wrote: Eric, We at Debian received a bug report about XFS on ARM (see below). I noticed your posting at http://oss.sgi.com/archives/xfs/2007-03/msg00053.html in which you said that this was a known issue. I cannot find the workaround you mentioned in your message. Do you know where I can find it? I think you also mentioned not having access to any ARM hardware. If I can give you an account on an ARM machine, do you think you could invetigate this issue in more detail? It would be great to have a small testcase that could be sent to the GCC folks. I think this was the fix: http://www.spinics.net/lists/arm-kernel/msg18479.html yeah, somebody should get to the bottom of this... sure, if I can log into an arm machine that demonstrates the bug, I could try to come up with a compact gcc testcase. Well, from looking at this patch I suppose anyone could, but I'll try to find some time. :) Thanks, -Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
