?) into 0.
So, existing xfs applications calling the xfs ioctl now will behave
differently, right? We can only keep the same ioctl number if the
calling semantics are the same. Keeping the same number but changing
the semantics is harmful, IMHO
-Eric
-
To unsubscribe from this list: send
number? If it was the latter, I guess we can put in
code into e2fsck to detect that case, and convert it back to a
singleton block number.
Eric informed me that the long symlinks were actually stored in extent
mapped blocks. That is not harmful, because it can only be a single
block
Theodore Tso wrote:
This looks good, but I assume that the bug was caused by some race
condition where if you try to call dm_task_get_info() while some other
process is creating or removing a snapshot, dm_task_get_info() is
returning some kind of EAGAIN, or some other Try again; we're busy
Theodore Tso wrote:
On Fri, Feb 22, 2008 at 09:02:56AM -0600, Eric Sandeen wrote:
Theodore Tso wrote:
This looks good, but I assume that the bug was caused by some race
condition where if you try to call dm_task_get_info() while some other
process is creating or removing a snapshot
Theodore Tso wrote:
On Fri, Feb 22, 2008 at 10:16:53AM -0600, Eric Sandeen wrote:
From a quick chat with agk, it sounds like outright failure is
appropriate. Sounds like most of the calls fail for reasons like ENOMEM
(but it might be nice if it returned that, eh?)
So the question
.
Thanks,
-Eric
-
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
into the
problem.
Should that be a raw image or a 'normal' one?
Raw, I think; that way you can compress it as well.
-Eric
-
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
Theodore Tso wrote:
On Wed, Feb 20, 2008 at 12:46:57PM -0600, Eric Sandeen wrote:
Theodore Tso wrote:
The big news here is that extents branch is sufficiently finished that
I've promoted it to the next branch.
Hey, that's great news. :)
Out of curiosity; what is the plan for behavior when
goto error handling / unwrapping, in the same style as
the device-mapper lib code itself.
Compile-tested only, but seems fine to me.
Thanks,
-Eric
Index: e2fsprogs-1.40.5/lib/blkid/devname.c
===
--- e2fsprogs-1.40.5.orig/lib/blkid
Aneesh Kumar K.V wrote:
ext4_find_next_zero_bit and ext4_find_next_bit needs a long aligned
address on x8_64. Add mb_find_next_zero_bit and mb_find_next_bit
and use them in the mballoc.
Fix: https://bugzilla.redhat.com/show_bug.cgi?id=433286
Eric Sandeen debugged the problem and suggested
Aneesh Kumar K.V wrote:
ext4_find_next_zero_bit and ext4_find_next_bit needs a long aligned
address on x8_64. Add mb_find_next_zero_bit and mb_find_next_bit
and use them in the mballoc.
Fix: https://bugzilla.redhat.com/show_bug.cgi?id=433286
Eric Sandeen debugged the problem and suggested
, they got
clobbered. Is that on the TODO before extents support goes live?
Thanks,
-Eric
-
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
but the mail news types have conflicting directives...
how will you define what an acceptable composite of subtypes will be?
Thanks,
-Eric
-
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
Theodore Tso wrote:
On Wed, Feb 20, 2008 at 12:51:21PM -0600, Eric Sandeen wrote:
Theodore Ts'o wrote:
The following patch is a work in progress, but I'm sending it out so
folks can take a look at it and comment on the general approach.
What this does is change how mke2fs -T works so it can
you mean to say print the UUID *with* the hyphens?
-Eric
-
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
Aneesh Kumar K.V wrote:
On Tue, Feb 19, 2008 at 10:39:52AM -0600, Eric Sandeen wrote:
Eric Sandeen wrote:
e2fsck doesn't expect to find char, block, fifo, or socket
files with the extent flag set, so clear that in ext4_mknod.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux
of the conditional, no? (and then there can be just one big test,
indentation can come out a bit...?)
But, the spirit of the patch looks right.
-Eric
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 23902ba..da942bc 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1771,7 +1771,6
Eric Sandeen wrote:
e2fsck doesn't expect to find char, block, fifo, or socket
files with the extent flag set, so clear that in ext4_mknod.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24/fs/ext4/namei.c
for
them. This will cause error later when we are verifying the extent header
Also we don't want to set extent flag for symlinks, char, block, fifo
or socket
Minor typo in comments, diretory, but otherwise:
Acked-by: Eric Sandeen [EMAIL PROTECTED]
Signed-off-by: Aneesh Kumar K.V [EMAIL
Eric Sandeen wrote:
Taking a cue from getfattr... if a string is mostly
printable characters, go ahead print as a string,
and escape what's left over.
Ted, ping on this? Since we use selinux a lot, it'd be nice to have
something readable in debugfs output.
If there's anything you don't like
Eric Sandeen wrote:
So this trips up on things like sockets, fifos, and block char nodes.
Just to demonstrate; doing this on ext4:
mknod mnt/block b 1 1
mknod mnt/char c 1 1
mknod mnt/fifo p
mksock mnt/sock
mkdir -p
mnt/verylongdir12345678901234567890/verylongdir12345678901234567890
set extents when we actually
get a block allocated to the file? That would also take care of this
from the kernel side I think.
-Eric
-
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
Theodore Tso wrote:
On Mon, Feb 18, 2008 at 11:56:53AM -0600, Eric Sandeen wrote:
So this trips up on things like sockets, fifos, and block char nodes.
Also this is unhappy:
@@ -137,7 +141,7 @@ int e2fsck_pass1_check_device_inode(ext2
* If the index flag is set, then this is a bogus
e2fsck doesn't expect to find char, block, fifo, or socket
files with the extent flag set, so clear that in ext4_mknod.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24/fs/ext4/namei.c
===
--- linux-2.6.24.orig
should probably be able to
repair that at some point...
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24/fs/ext4/namei.c
===
--- linux-2.6.24.orig/fs/ext4/namei.c
+++ linux-2.6.24/fs/ext4/namei.c
@@ -2223,7
Valerie Clement wrote:
Eric Sandeen wrote:
Valerie Clement wrote:
Fix kernel BUG at fs/ext4/mballoc.c:910!
From: Valerie Clement [EMAIL PROTECTED]
With the flex_bg feature enabled, a large file creation oopses the
kernel.
Valerie, what's the specific testcase for this?
Thanks,
-Eric
I
be fine as well, right? And I think Josef sent a patch...
-Eric
-
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
* Eric Sandeen ([EMAIL PROTECTED]) wrote:
Eric Sesterhenn wrote:
Eric ,
can you run the test with below patch and see if this makes any
difference ?. I know we are not fixing any bugs in the below patch.
ok, i checked out the old version again and applied both patches,
the BUG
that's not a issue any more.
I guess I should look into it. For now let's just drop the #ifdef
removal, it's not related anyway.
Would you like me to send a fresh patch?
Thanks,
-Eric
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL
Eric Sesterhenn wrote:
* Eric Sandeen ([EMAIL PROTECTED]) wrote:
Eric Sesterhenn wrote:
Eric ,
can you run the test with below patch and see if this makes any
difference ?. I know we are not fixing any bugs in the below patch.
ok, i checked out the old version again and applied both patches
.
Thanks!
-Eric
-
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
Eric ,
can you run the test with below patch and see if this makes any
difference ?. I know we are not fixing any bugs in the below patch.
ok, i checked out the old version again and applied both patches,
the BUG is gone (no surprise)
In the case where it would have hit the BUG i now get
in
modules.dep, /proc files, etc...
-Eric
-
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 the errors= mount option.
Eric Sandeen explained me the same on IRC. I was busy with the migrate
locking bug. That's why i didn't update here. Today i tried to reproduce
the problem using the image provided. But in my case it is not hitting
the BUG_ON (mostly due to single cpu). I did look
Eric Sesterhenn wrote:
Eric ,
can you run the test with below patch and see if this makes any
difference ?. I know we are not fixing any bugs in the below patch.
ok, i checked out the old version again and applied both patches,
the BUG is gone (no surprise)
In the case where it would have
is a no-op function w/o the config option.
Feel free to leave it in if you like though.
-Eric
-
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
Mingming Cao wrote:
On Thu, 2008-02-07 at 19:06 -0600, Eric Sandeen wrote:
Mingming Cao wrote:
Do you intend to remove the #ifdef CONFIG_PROC_FS, or it's a accident? I
think we need keep that to allow ext4 build without procfs configured.
Other than this, the patch looks fine to me.:)
oh
allocation failures or corrupted disks, I think it's ok.
Not that I've audited them all. :)
I asked about this early on, and got that answer... I'm reasonably
satisfied with it.
-Eric
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED
any other failures.
Comments?
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc6-mm1/fs/ext4/mballoc.c
===
--- linux-2.6.24-rc6-mm1.orig/fs/ext4/mballoc.c
+++ linux-2.6.24-rc6-mm1/fs/ext4/mballoc.c
@@ -419,6
* Aneesh Kumar K.V ([EMAIL PROTECTED]) wrote:
On Thu, Jan 31, 2008 at 04:42:07PM +0100, Eric Sesterhenn wrote:
* Eric Sesterhenn ([EMAIL PROTECTED]) wrote:
hi,
while running a modified version of fsfuzzer i triggered the BUG() in
ext4_mb_release_inode_pa(). Sadly I am not able
function as noinline, (although
the xfs situation was a little more dire) and I don't think they had
any noticeable performance impact.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-git9/fs/ext4/mballoc.c
a bit shocking how much this matters to the size of
ext4_mb_release_inode_pa etc; I've not yet found the
reason why.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-git9/fs/ext4/mballoc.c
===
--- linux-2.6.24
Eric Sandeen wrote:
It's a bit shocking how much this matters to the size of
ext4_mb_release_inode_pa etc; I've not yet found the
reason why.
Oh, well, duh - its' the big 108 byte allocation context on the
stack and if it's not used it gets optimized away.
I think it's worth looking
* Mingming Cao ([EMAIL PROTECTED]) wrote:
We need to check the error returns from journal_submit_commit_record()
and avoid calling journal_wait_on_commit_record() in the failure case.
Signed-off-by: Mingming Cao [EMAIL PROTECTED]
thanks, the patch works for me, i closed the bugzilla entry
-
information. The kernel is current git with
ext4-fix-null-pointer-deref-in-journal_wait_on_commit_record.patch
applied.
Greetings, Eric
[ 1570.971980] EXT4-fs error (device loop0) in ext4_reserve_inode_write:
Journal has aborted
[ 1570.972077] pa c6512330: logic 16, phys. 2337, len 16
[ 1570.972103
...
If you are able to reproduce this, could you please dump the inode and EA
block before fixing the problem.
Do you need instructions on doing that?
-Eric
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info
* Eric Sesterhenn ([EMAIL PROTECTED]) wrote:
hi,
while running a modified version of fsfuzzer i triggered the BUG() in
ext4_mb_release_inode_pa(). Sadly I am not able to reproduce this using
the generated image, but running the fuzzer will usually trigger this in
less than 40 attempts
/sda1
-Eric
# ext2/ext3 filesystems - Andreas Dilger [EMAIL PROTECTED]
0x438 leshort 0xEF53 Linux
0x44c lelong x rev %d
0x43e leshort x \b.%d
# No journal? ext2
0x45c lelong ^0x004 ext2 filesystem data
0x43a
going on with this?
No released e2fsprogs supports ext4 filesystems with new on-disk
features yet; that's partly what the dev on the end of ext4dev.ko is
for. Ted's working on it.
-Eric
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL
UUID
/dev/sda2 guOQGd-cOE3-IafC-m019-0XkP-ZTy5-fCEanQ
Bits liberally stolen from lvm2 userspace.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: e2fsprogs-1.40.5/lib/blkid/probe.h
-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc6-mm1/fs/ext4/inode.c
===
--- linux-2.6.24-rc6-mm1.orig/fs/ext4/inode.c
+++ linux-2.6.24-rc6-mm1/fs/ext4/inode.c
@@ -2750,13 +2750,7 @@ void ext4_read_inode(struct
:
selinux = 73 79 73 74 65 6d 5f 75 3a 6f 62 6a 65 63 74 5f 72 3a 72 6f 6f 74
5f 74 3a 73 30 00 (28)
(selinux includes the trailing null in len so it
never prints as a string today)
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: e2fsprogs-1.40.5/debugfs/debugfs.c
...
mkfs.xfs tries to do this, but it'd be silly to duplicate in every mkfs.
On my one of these days list is to get another cheap/used laptop so
I can try out the latest Fedora Core Rawhide without having to fire up
a huge (noisy) x86_64 box
Just partition... ;)
-Eric
-
To unsubscribe from
?
-Eric
-
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
with selinux, reboots = force
recheck of the entire filesystem, because the kernel wrote extended
attributes for selinux, but only to the primary superblock.
Solely having this set in primary but not in the backups should hardly
be a trigger for a full filesystem check, should it?
-Eric
set on the primary, really no damage is done, and if the backup is
used, but it doesn't have the flags set when it should, I'm pretty sure
e2fsck can cope with that.
I'll admit the patch below is not glamorous. Any comments, either
on the style(sic) or the intent of the patch?
Thanks,
-Eric
, and not with some pre-determined timeout?
-Eric
-
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
, but it doesn't have the flags set when it should, I'm pretty sure
e2fsck can cope with that.
I'll admit the patch below is not glamorous. Any comments, either
on the style(sic) or the intent of the patch?
Thanks,
-Eric
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: e2fsprogs-1.40.4
Returns ext4dev for now; will need to change to ext4 at the appropriate
time I guess.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: e2fsprogs-1.40.4/lib/blkid/probe.c
===
--- e2fsprogs-1.40.4.orig/lib/blkid/probe.c
,
+ and may take an argument which\n
+ \tis set off by an equals ('=') sign.\n\n
+ Valid extended options are:\n
+ \ttestfs\n));
help text doesn't match reality here, missing a _
-Eric
-
To unsubscribe from this list: send
?) I'm sure there is some history here, but why
build it all into the module, and then turn them off without some extra
magic passed in? What's the advantage to disabling user xattrs acls
at runtime by default?
Thanks just curious,
-Eric
-
To unsubscribe from this list: send the line
---BeginMessage---
http://bugzilla.kernel.org/show_bug.cgi?id=9732
Summary: oops in extent code via ext4_fallocate
Product: File System
Version: 2.5
KernelVersion: 2.6.24-rc7
Platform: All
OS/Version: Linux
Tree: Mainline
uuidd(8) man page had a typo, and a couple of stale defaults
documented.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: e2fsprogs-1.40.4/misc/uuidd.8.in
===
--- e2fsprogs-1.40.4.orig/misc/uuidd.8.in
+++ e2fsprogs-1.40.4
Eric Sandeen wrote:
uuidd(8) man page had a typo, and a couple of stale defaults
documented.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: e2fsprogs-1.40.4/misc/uuidd.8.in
===
--- e2fsprogs-1.40.4.orig/misc
||
+ sbi-s_stripe = sbi-s_blocks_per_group) {
Is stripe == s_blocks_per_group problematic?
Should we warn/printk in the case that the specified size is too big?
Thanks,
-Eric
+ sbi-s_stripe = le32_to_cpu(es-s_raid_stripe_width
fe_len.
changes anything that does groupno * EXT4_BLOCKS_PER_GROUP
or pa-pa_pstart + whatever to an ext4_fsblk_t
avoids 64-bit divides modulos, and...
fixes up any related formats
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc3/fs/ext4/mballoc.c
Andreas Dilger wrote:
On Jan 02, 2008 14:01 -0600, Eric Sandeen wrote:
This patch:
changes fe_len to an int, I don't think we need it to be a long,
looking at how it's used (should it be a grpblk_t?) Also change
anything assigned to return value of mb_find_extent, since it returns
fe_len
Andreas Dilger wrote:
On Jan 03, 2008 14:10 -0600, Eric Sandeen wrote:
@@ -1732,17 +1735,19 @@ static void ext4_mb_scan_aligned(struct
+/* find first stripe-aligned block in group */
+a = e4b-bd_group * EXT4_BLOCKS_PER_GROUP(sb)
+ le32_to_cpu(sbi-s_es-s_first_data_block
Eric Sandeen wrote:
Eric Sandeen wrote:
I ran into a potential overflow in ext4_mb_scan_aligned,
and went looking for others in mballoc. This patch hits a
few spots, compile-tested only at this point, comments welcome.
This patch:
... introduces a 64-bit divide. Oops
kernels in the first place. IMHO, it's reasonable to expect
the small minority of Linux users who want to compile their own kernels
to learn that EXPERIMENTAL means something.
Cheers,
Eric
signature.asc
Description: This is a digitally signed message part
options marked
EXPERIMENTAL, and see if they still should be marked as such, rather
than removing the option altogether.
init/Kconfig describes things in EXPERIMENTAL as alpha-test - I bet
there are a few things which have moved beyond this, but are still
marked as such.
-Eric
-
To unsubscribe from
);
}
to fix up too-large writes to these files in ext4_file_write().
This patch is currently living in the ext4 patch queue.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc3/fs/read_write.c
corruption.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc3/fs/ext3/namei.c
===
--- linux-2.6.24-rc3.orig/fs/ext3/namei.c
+++ linux-2.6.24-rc3/fs/ext3/namei.c
@@ -1049,6 +1049,9 @@ static struct dentry *ext3_lookup
corruption.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc3/fs/ext4/namei.c
===
--- linux-2.6.24-rc3.orig/fs/ext4/namei.c
+++ linux-2.6.24-rc3/fs/ext4/namei.c
@@ -1050,6 +1050,9 @@ static struct dentry *ext4_lookup
in ext4_file_write().
This patch is currently living in the ext4 patch queue.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc3/fs/read_write.c
===
--- linux-2.6.24-rc3.orig/fs/read_write.c
+++ linux-2.6.24-rc3/fs
...
Comments? (if it looks good I'll resubmit for ext*_lookup)
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc3/fs/ext3/namei.c
===
--- linux-2.6.24-rc3.orig/fs/ext3/namei.c
+++ linux-2.6.24-rc3/fs/ext3/namei.c
Andreas Dilger wrote:
On Dec 04, 2007 09:58 -0600, Eric Sandeen wrote:
+static loff_t ext4_max_size(int blkbits)
+{
+loff_t res;
+loff_t upper_limit = MAX_LFS_FILESIZE;
+
+/* small i_blocks in vfs inode? */
+if (sizeof(blkcnt_t) sizeof(u64)) {
It would probably be more
use 2 different maxbytes functions for bitmapped extent-based
files.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc3/fs/ext4/super.c
===
--- linux-2.6.24-rc3.orig/fs/ext4/super.c
+++ linux-2.6.24-rc3/fs
of the write to the maximum.
3 patches follow:
ext4_two_maxbytes_functions.patch - differentiate the maxbytes f'ns
ext4_bitmap_maxbytes_vfs.patch - export iov_shorten from kernel
ext4_bitmap_maxbytes.patch - store, and limit to, bitmap_maxbytes
Comments?
Thanks,
-Eric
-
To unsubscribe from this list
Crud, minor off-by-one in ext4_file_write. V2 below:
===
Calculate store the max offset for bitmapped files, and
catch too-large seeks, truncates, and writes in ext4, shortening
or rejecting as appropriate.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index
, block=%llu, max_blocks=%llu,
Need to change the returned 0! part of the error to returned %d!
then too, I guess?
-Eric
-
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
Accumulate jbd2 stats in jiffies not msecs, per akpm's suggestion.
Convert to msecs on when displayed.
jbd2_time_diff() should still be moved to a common header file.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc3/fs/jbd2/checkpoint.c
formatting changes
o size bdevname char arrays with BDEVNAME_SIZE
o use #ifdef vs. #if defined() for single test
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc3/fs/jbd2/journal.c
===
--- linux-2.6.24-rc3.orig/fs
to this, but thought I'd send it out for comment.
(BTW another option would be to convert old-format files when accessed, but
that has its own set of tradeoffs...)
Thanks,
-Eric
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc1/fs/buffer.c
the e2fsprogs developers to find
and fix the bugs more easily.
I don't see e2fsprogs on the website yet. Anyone care if I go ahead
ask that e2fsprogs be included?
-Eric
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list
a config
option; I tend to think it should, but it's fairly well sprinkled
through the code, so I'll see how well that works.
Also did we ever decided if this should go to debugfs?
Thanks,
-Eric
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL
ext4 calls inode_inc_iversion(), but it's not exported, so modular ext4
has trouble. Any reason not to just make it an inline, as below?
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc1/fs/inode.c
Builds with EXT4FS_DEBUG defined (to enable ext4_debug()) fail
without these changes. Clean up some format warnings too.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc1/fs/ext4/balloc.c
===
--- linux
is the right place to do this for now.
-Eric (remembering he has a bug to report, too)
-
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
to avoid an overflow
may be too clever... it could use an extra look I think.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc1/fs/ext4/mballoc.c
===
--- linux-2.6.23.orig/fs/ext4/mballoc.c
+++ linux-2.6.23/fs/ext4
Eric Sandeen wrote:
I ran into a potential overflow in ext4_mb_scan_aligned,
and went looking for others in mballoc. This patch hits a
few spots, compile-tested only at this point, comments welcome.
This patch:
... introduces a 64-bit divide. Oops... will fix that up resend.
-Eric
://bugzilla.kernel.org/show_bug.cgi?id=9329
I'll try to find time to look into this unless someone knows offhand
where the problem is...
Thanks,
-Eric
(p.s. should I get ext[234] bug mail routed to this list, or would that
be annoying?)
-
To unsubscribe from this list: send the line unsubscribe linux-ext4
Andreas Dilger wrote:
On my FC8 install, ismounted.c fails to build because open(O_CREAT) is
used without passing a mode. The following trivial patch fixes it.
You can add:
Acked-by: Eric Sandeen [EMAIL PROTECTED]
'cause it's an awful lot like the patch I sent for the same issue back
on 8/16
Andreas Dilger wrote:
On Nov 06, 2007 13:54 -0600, Eric Sandeen wrote:
Hmm bad news is when I add uninit_groups into the mix, it goes a little
south again, with some out-of-order extents. Not the end of the world,
but a little unexpected?
I think part of the issue is that by default
Eric Sandeen wrote:
When mounting an ext4 filesystem with corrupted s_first_data_block, things
can go very wrong and oops.
Because blocks_count in ext4_fill_super is a u64, and we must use do_div,
the calculation of db_count is done differently than on ext4.
Urgh... than on ext3
-Eric
seek penalties are probably not
too bad.
-Eric
-
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
some of this under a single head, rather than on
HW raid...
-Eric
-
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
Shapor Naghibzadeh wrote:
On Wed, Nov 07, 2007 at 04:42:59PM -0600, Eric Sandeen wrote:
Again this was on a decent HW raid so seek penalties are probably not
too bad.
You may want to verify that by doing a benchmark on the raw device. I
recently did some benchmarks doing random I/O
/xfs_4_thread_par_read.png
http://people.redhat.com/esandeen/seekwatcher/ext4_xfs_4_thread_par_read.png
-Eric
-
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
Eric Sandeen wrote:
Alex Tomas wrote:
thanks for the data. the attached patch should fix couple issues:
broken history output and policy in that smaller usable chunk to
be used. can you give it a spin, please?
Hi Alex -
This looks *much* better:
Hmm bad news is when I add uninit_groups
1 - 100 of 248 matches
Mail list logo
