Theodore Tso wrote:
On Wed, Aug 30, 2006 at 01:18:21PM -0500, Eric Sandeen wrote:
new patchset series is at
http://people.redhat.com/esandeen/ext3/e2fsprogs-1.39-16T/e2fsprogs-hg-20060830-16T-patches.tar.gz
I've applied your patches (with a few minor changes in the
ChangeLogs
Dave Kleikamp wrote:
# From Mingming Cao
sector_t-jbd2.patch
I think this one needs to address the first, last variables in
journal_fail_superblock():
static int journal_reset(journal_t *journal)
{
journal_superblock_t *sb = journal-j_superblock;
- unsigned int first, last;
+
Andrew Morton wrote:
On Wed, 13 Sep 2006 15:25:19 -0500
Dave Kleikamp [EMAIL PROTECTED] wrote:
+void journal_do_submit_data(struct buffer_head **wbuf, int bufs)
Is there any reason this couldn't be static?
Nope.
With this change, journal_brelse_array can also be made static in
Badari Pulavarty wrote:
fsx got a segmentation fault and died. These are the messages in the
dmesg.
I've never seen fsx die that way before... can you get a coredump to see
where it was at?
-Eric
-
To unsubscribe from this list: send the line
Doing some rainy-day cleanup last night :)
I don't think there's any reason to keep these unused function args...
I'm also wondering about:
void
journal_release_buffer(handle_t *handle, struct buffer_head *bh)
{
BUFFER_TRACE(bh, entry);
}
why is this function there?
Hrm, guess now I
in these two cases, and made a couple other
tracepoint changes that I found useful in debugging this.
Thanks,
-Eric
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.18/fs/jbd/transaction.c
===
--- linux-2.6.18.orig/fs/jbd
Andreas Dilger wrote:
On Oct 18, 2006 16:11 -0500, Eric Sandeen wrote:
First, we had a corrupted index directory that was never checked
for consistency... it was corrupt, and pointed to another entry
of length 0. The for() loop looped forever, since the length
of ext3_next_entry(de) was 0
Andreas Dilger wrote:
On Oct 18, 2006 16:56 -0500, Eric Sandeen wrote:
Andreas Dilger wrote:
The directory leaf data is kept in
the page cache and there is a helper function ext2_check_page() to mark
the page checked. That means the page only needs to be checked once
after being read from
Andreas Dilger wrote:
On Oct 19, 2006 17:43 -0500, Eric Sandeen wrote:
Eric Sandeen wrote:
How about just tweaking the existing ext3_bread so that it lets the
caller know whether or not it found an uptodate buffer? Seems
conceivable that more than just the dir code might want to do a data
of bytes,
stop trying, and break out of the loop.
With these two changes fsfuzz test survives quite well on ext3.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.18/fs/ext3/namei.c
===
--- linux-2.6.18.orig/fs/ext3/namei.c
Alex Tomas wrote:
Theodore Tso (TT) writes:
TT On Mon, Oct 23, 2006 at 02:27:10PM +0200, Jan Kara wrote:
Hello,
I've written a simple patch implementing ext3 ioctl for file
relocation. Basically you call ioctl on a file, give it list of blocks
and it relocates the file into given
David Chinner wrote:
The allocation interface, OTOH, is anything but simple and is really
a filesystem specific interface. Seems logical to me to separate
the two.
And ext[234] preallocation would be a very nice feature in its own right.
-Eric
-
To unsubscribe from this list: send the line
Alex Tomas wrote:
3) scalable reservation
required for delayed allocation to avoid -ENOSPC at flush time.
current version uses per-sb spinlock.
Can you elaborate on this issue? Shouldn't delayed allocation decrement free
space immediately, and only the actual block location choice is
Eric Sandeen wrote:
Eric Sesterhenn / Snakebyte wrote:
hi,
after fsfuzz
(http://www.securityfocus.com/archive/1/449568/30/0/threaded) was
released i decided to give it a spin. So far I got two problematic
images:
http://www.cobra-basket.de/ext3_ls_prozzy_hog.img.bz2
which makes
the fsfuzzer has been keeping me busy lately ;-)
http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html
has an image with a corrupt directory inode - despite having only 4 blocks, it
has an extremely large i_size.
readdir lookup seem to behave differently when
progress.
Actually, I think Eric Sandeen was working on similar fixes already, and
instead of doing a per-item check each time we look at the entry it does
a full-block check the first time it is read (as ext2 does).
This fixes the problem described at:
http://projects.info-pull.com/mokb
...
Comments?
Thanks,
-Eric
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.19/fs/ext3/namei.c
===
--- linux-2.6.19.orig/fs/ext3/namei.c
+++ linux-2.6.19/fs/ext3/namei.c
@@ -1942,15 +1942,15 @@ int ext3_orphan_del(handle_t
worked in my testing. Comments or commit would be appreciated.
Thanks,
-Eric
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.19/fs/ext3/namei.c
===
--- linux-2.6.19.orig/fs/ext3/namei.c
+++ linux-2.6.19/fs/ext3
Alex Tomas wrote:
Valerie Clement (VC) writes:
VC Hi Alex,
VC I did the following test:
VC # mkfs /dev/sdc1
VC # mount -t ext4dev -o extents,mballoc,delalloc /dev/sdc1 /test
VC # dumpe2fs -h /dev/sdc1
VC # cp linux.tar /test
VC # tar xf /test/linux.tar
VC # dumpe2fs -h /dev/sdc1
VC
Andreas Dilger wrote:
On Dec 19, 2006 17:12 +0530, Amit K. Arora wrote:
I wrote a simple tool to test these patches. The tool takes four
arguments:
* command: It may have either of the two values - prealloc or write
* filename: This is the filename with relative path
* offset: The offset
Randy Dunlap wrote:
Please don't hide the goto; un-indent 1 tab stop.
Whoops, thanks Randy - it wasn't intentional. :)
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.19/fs/ext2/dir.c
===
--- linux-2.6.19.orig/fs
of unprocessed orphan inode list.
Please umount/remount instead.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.19/fs/ext3/super.c
===
--- linux-2.6.19.orig/fs/ext3/super.c
+++ linux-2.6.19/fs/ext3/super.c
@@ -2350,6 +2350,22
the list.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.19/fs/ext3/namei.c
===
--- linux-2.6.19.orig/fs/ext3/namei.c
+++ linux-2.6.19/fs/ext3/namei.c
@@ -2204,6 +2204,9 @@ retry:
inode-i_ctime
Alex Tomas wrote:
Eric Sandeen (ES) writes:
ES so I think it's possible that link can sneak in there find it after
ES the mutex is dropped...? Is this ok? :) It's certainly -happening-
ES anyway
yes, but it shouldn't allow to re-link such inode back, IMHO.
a filesystem may
Alex Tomas wrote:
Eric Sandeen (ES) writes:
ES I tend to agree, chatting w/ Al I think he does too. :) I'll test
ES a patch that kicks out ext3_link() with -ENOENT at the top, and resubmit
ES that if things go well.
shouldn't VFS do that?
Al says no and I'm not arguing
Dmitriy Monakhov wrote:
Eric Sandeen [EMAIL PROTECTED] writes:
I've been looking at a case where many threads are opening, unlinking, and
hardlinking files on ext3 .
How many concurent threads do you use and how long does it takes to trigger
this race? I've tried to reproduce this with two
raced with unlink and
i_nlink is 0. Doing otherwise has the potential to corrupt the
orphan inode list, because we'd wind up with an inode with a
non-zero link count on the list, and it will never get properly
cleaned up removed from the orphan list before it is freed.
Signed-off-by: Eric Sandeen
.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.19/fs/ext3/namei.c
===
--- linux-2.6.19.orig/fs/ext3/namei.c
+++ linux-2.6.19/fs/ext3/namei.c
@@ -2191,6 +2191,8 @@ static int ext3_link (struct dentry * ol
Vitez Gabor wrote:
Hi,
It would be really great if ext4 supported an xfs_freeze like operation.
On xfs it spared me a lot of headaches when I was playing with unstable
kernel features.
thanks
Gabor
Right now ext3 and ext4 -can- be frozen, but only via devicemapper,
because the
Andrew Morton wrote:
Begin forwarded message:
Date: Thu, 1 Feb 2007 16:44:39 +0800
From: Fengguang Wu [EMAIL PROTECTED]
To: LKML linux-kernel@vger.kernel.org
Subject: [BUG -mm] ext3_orphan_add() accessing corrupted list on a corrupted
ext3fs
I accidentally ran two qemu instances on
Andrew Morton wrote:
Sorry, we're seriously, seriously, seriously short on flags in the page
struct and this patch is going to need one heck of a good case for it to be
acceptable.
This was for the delayed allocation patchset, right; and by managing
this at the page level that means we can't
Andrew Morton wrote:
On Mon, 19 Feb 2007 10:52:42 +1100 Rusty Russell [EMAIL PROTECTED] wrote:
Hi all,
This happened on 2.6.20-rc6-mm3, so I upgraded to 2.6.20-git14, and
same thing happened. Doing a forced fsck on the (corrupted by
double-mounting I think) filesystem fixed it, but I
Adrian Bunk wrote:
On Mon, Feb 19, 2007 at 06:03:14PM -0500, Chuck Ebbert wrote:
This was dropped from 2.6.16-stable somehow:
http://lkml.org/lkml/2006/6/30/54
Thanks for forwarding it.
This patch didn't went in this form into Linus' tree, I'd therefore like
to get an ACK from the
Badari Pulavarty wrote:
Amit K. Arora wrote:
This is to give a heads up on few patches that we will be soon coming up
with. These patches implement a new system call sys_fallocate() and a
new inode operation fallocate, for persistent preallocation. The new
system call, as Andrew suggested,
Badari Pulavarty wrote:
BTW, what is the interface for finding out what is the size of the
pre-allocated file ?
With XFS at least, du, stat, etc tell you a little:
[EMAIL PROTECTED] test]# touch resvsp
[EMAIL PROTECTED] test]# xfs_io resvsp
xfs_io resvsp 0 10g
The file is 0 length, but is
Jan Kara wrote:
I am wondering if it is useful to add another mode to advise block
allocation policy? Something like indicating which physical block/block
group to allocate from (goal), and whether ask for strict contigous
blocks. This will help preallocation or reservation to choose the
Ulrich Drepper wrote:
Christoph Hellwig wrote:
fallocate with the whence argument and flags is already quite complicated,
I'd rather have another call for placement decisions, that would
be called on an fd to do placement decissions for any further allocations
(prealloc, write, etc)
Yes,
Jan Kara wrote:
On Tue 06-03-07 06:36:09, Ulrich Drepper wrote:
Christoph Hellwig wrote:
fallocate with the whence argument and flags is already quite complicated,
I'd rather have another call for placement decisions, that would
be called on an fd to do placement decissions for any further
Eric Sandeen wrote:
NR_CPUS is a config-time option that may be much more than your actual
count of runtime possible CPUs...
compile-tested.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Ted, I don't see this in the git tree yet.
Yea? Nay? Comments?
Thanks,
-Eric
-
To unsubscribe
raw_inode to get extra_isize
in EXT4_FITS_IN_INODE
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6-ext4/fs/ext4/inode.c
===
--- linux-2.6-ext4.orig/fs/ext4/inode.c
+++ linux-2.6-ext4/fs/ext4/inode.c
@@ -2784,7 +2784,7
Samuel Thibault wrote:
Hi,
Distribution installers usually try to probe OSes for building a suited
grub menu. Unfortunately, mounting an ext3 partition, even in read-only
mode, does perform some operations on the filesystem (log recovery).
This is not a good idea since it may silently garbage
Andreas Dilger wrote:
Try mke2fs -O lazy_bg XXX and be happy. Can be used on any kernel as
it is a COMPAT feature and marks all but first and last groups as full.
Ugh, how'd I miss that. :)
Thanks...
-Eric
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body
):4194272287-419427329
Unfortunately it also increases mkfs time a bit, as it must search
a huge string of unavailable blocks if it has to allocate in the
last bg. Ah well...
Thanks,
-Eric
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: e2fsprogs-1.39_ext4_hg/misc/mke2fs.c
If ext3 can do 16T, ext2 probably should be able to as well.
There are still int block containers in the block allocation path
that need to be fixed up.
Perhaps ext2 should get the ext2_fsblk_t/ext2_grpblk_t treatment
as ext3 did, for clarity...
Signed-off-by: Eric Sandeen [EMAIL PROTECTED
Andreas Dilger wrote:
On Apr 20, 2007 12:10 -0500, Eric Sandeen wrote:
If ext3 can do 16T, ext2 probably should be able to as well.
There are still int block containers in the block allocation path
that need to be fixed up.
Yeah, but who wants to do 16TB e2fsck on every boot? I think
Mingming Cao wrote:
On Fri, 2007-04-20 at 18:14 -0500, Eric Sandeen wrote:
It's a bug, today.
They are fixed in mm tree, as part of the patches which backports ext3
block reservation code to ext2. filesystem block numbers are all
ext2_fsblk_t type(i.e. unsigned long)(see ext2_new_blocks
Avantika Mathur wrote:
- large filesystem
- We would like to perform more testing on large (16TB) filesystems
- currently hardware limitations are preventing this testing. We
have tested 10TB raid dists, and 16TB loopback devices. Avantika will
look into creating very large sparse
mke2fs.conf and mke2fs.c into line for current
defaults...
Thanks,
-Eric
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: e2fsprogs-hg/misc/mke2fs.c
===
--- e2fsprogs-hg.orig/misc/mke2fs.c
+++ e2fsprogs-hg/misc/mke2fs.c
@@ -1288,7
40700 (2) 0 0 12288 7-May-2007 11:57 lost+found
The attached patch creates inode_uid() and inode_gid() macros to accommodate
the high bits when reading uid/gid, on platforms that support it.
It also accommodates large UID/GID at mkfs time.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED
Theodore Tso wrote:
On Mon, May 07, 2007 at 11:31:22AM -0500, Eric Sandeen wrote: One of
our testers filed a bug that said mkfs.ext3 is much slower when
mke2fs.conf is missing...
This is because the shipped defaults in mke2fs.conf do not match the
shipped defaults in the mkfs code itself; he
Valerie Clement wrote:
Jose R. Santos wrote:
I think this has more to do with the fact that I'm on a 32bit
architecture and there are still a couple places where blocks are
represented using unsigned long. I'm trying to get access to a 64bit
arch to confirm this.
-JRS
Oh, I didn't catch
Jose R. Santos wrote:
On Wed, 09 May 2007 10:21:44 -0500
Eric Sandeen [EMAIL PROTECTED] wrote:
Jose, you mentioned that some blocks are still unsigned long on
32-bits... they shouldn't be, the LBD work should have fixed all those
long ago. But there is still the 16TB page cache limit
Valerie Clement wrote:
Get the new version of e2fsprogs at
ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs-interim/e2fsprogs-1.39-tyt3
and apply the patchset in attachment.
Hope this helps,
Valérie
Valérie, this looks a bit odd in 02_use_64bit_io, in debugfs.c:
@@
Brian D. Behlendorf wrote:
Lawrence Livermore National Labs recently ran the source code
analysis tool Coverity over the e2fsprogs-1.39 source to see
if it would identify any significant bugs. The analysis
turned up 38 mostly minor issues which are enumerated here
with patches. We went
Theodore Tso wrote:
On Tue, May 29, 2007 at 03:56:44PM -0500, Eric Sandeen wrote:
I still have it in my apply atop 1.39-WIP series, so it appears not
to have made it into Ted's repo. I'm including the patch again for
posterity.
Thanks Andreas - near as I can tell, it never made it to the list
Vasily Averin wrote:
Customers claims to ext3-related errors, investigation showed that ext3 orphan
list has been corrupted and have the reference to non-ext3 inode. The following
debug helps to understand the reasons of this issue.
Vasily, does your customer have this patch in place?
Vasily Averin wrote:
After ext3 orphan list check has been added into ext3_destroy_inode() (please
see my previous patch) the following situation has been detected:
EXT3-fs warning (device sda6): ext3_unlink: Deleting nonexistent file
(37901290), 0
Inode 0101a15b7840: orphan list check
Karsten Hopp wrote:
Hello,
I've already posted this at the e2fsprogs sourceforge site, but our
e2fsprogs maintainer
suggested that I should post it here as well for a review:
Attached is a patch to add cryptsetup-luks UUID detection in libblkid.so
This is required when we want to use UUIDs
Avantika Mathur wrote:
Hi Andreas,
I have ported your uninitialized block group kernel patch to mainline
2.6.22-rc3, included below.
I will also be posting the ported e2fsprogs patches. I had trouble
testing the patches because of inconsistency in the block_group
structure in e2fsprogs - which
ext[234]_get_group_desc only sets the bh argument if it is non-null,
and several callers pass in a bh which is not subsequently used -
it may as well be NULL.
Compiled booted lightly tested.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.22-rc3/fs/ext3/ialloc.c
assigned to desc but then we return without using either. Looks like
it can just be removed.
Compiled booted lightly tested.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.22-rc3/fs/ext2/ialloc.c
===
--- linux
Aneesh Kumar K.V wrote:
Hi,
In block reservation code while rebalancing the free blocks why are we not
looking at the reservation slots that have no free blocks left. Rebalancing
the free blocks equally across all the reservation slots will make sure
we have less chances of failure later
Use zero_user_page() in cifs, ocfs2, ext4, and gfs2 where possible.
Compile tested, reviews welcome.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.22-rc4-mm2/fs/cifs/inode.c
===
--- linux-2.6.22-rc4-mm2.orig/fs
Andreas Dilger wrote:
Ted,
the attached patch adds an extra validity test in check_ext_attr(). If
an attribute's e_value_size is zero the current code does not allocate
a region for it and as a result the e_value_offs value is not verified.
However, if e_value_offs is very large then the
sftf wrote:
Hi!
IMHO this test is not 100% correct.
ext3 | data=writeback
ext4 | data=writeback,extents,delalloc
xfs | defaults is ordered !
So you have compared ext's in writeback (which fastest mode) vs xfs in
ordered.
Actually xfs's default (only) mode is more like
Michal Piotrowski wrote:
Hi all,
My insane file system test triggered a few bugs in ext3 image. Anyone
interested?
Not yet; all the errors below are ext3 properly coping with the
corrupted image, no? But if you can make it oops, that's more
interesting. :)
-Eric
[40859.103232] SELinux:
... how about the following patch...)
-Eric
-
Fix build warning on x86_64 due to comparison of __u32 and ULONG_MAX
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: e2fsprogs-1.40.2/misc/badblocks.c
===
--- e2fsprogs-1.40.2.orig
; the expected output is
actually a mkfs failure - but a proper failure instead of the
allocator catching the problem at the last minute)
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: e2fsprogs-1.40.2/lib/ext2fs/initialize.c
throughout the ext filesystems...)
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.22-rc4/fs/ext2/super.c
===
--- linux-2.6.22-rc4.orig/fs/ext2/super.c
+++ linux-2.6.22-rc4/fs/ext2/super.c
@@ -579,7 +579,7 @@ static int
ext[234]_get_group_desc never tests the bh argument, and only sets
it if it is passed in; it is perfectly happy with a NULL bh argument.
But, many callers send one in and never use it. May as well call with
NULL like other callers who don't use the bh.
Signed-off-by: Eric Sandeen [EMAIL
Theodore Tso wrote:
On Fri, Jul 20, 2007 at 04:47:14PM -0500, Eric Sandeen wrote:
For some odd geometries*, mkfs will try to allocate inode tables off
the end of the block group and fail, rather than warning that too
many inodes have been requested.
This is because when ext2fs_initialize
Andreas Dilger wrote:
On Aug 02, 2007 17:55 +0800, Coly Li wrote:
These days, when I read the source code of mke2fs, I found an option -f
to set the fragment size.
But I can not find any explaining for ext3/4 framgment from google,
excepting someone saying ext2/3 does not support this
Eric Sandeen wrote:
A corrupt ondisk hash dir limit will trip an assert in dx_probe,
which calls BUG(). Instead, we can just issue the warning and
fail dx_probe like the other 3 tests just before it. Thanks
to aviro for suggesting this...
BTW this type of corruption is apparently quite
Andreas Dilger wrote:
On Aug 09, 2007 17:41 -0500, Eric Sandeen wrote:
Eric Sandeen wrote:
A corrupt ondisk hash dir limit will trip an assert in dx_probe,
which calls BUG(). Instead, we can just issue the warning and
fail dx_probe like the other 3 tests just before it. Thanks
to aviro
Andreas Dilger wrote:
On Aug 10, 2007 11:08 -0500, Eric Sandeen wrote:
Andreas Dilger wrote:
I'd like to see the actual corruption, to find out why the hash-type
check didn't find it. If it is because LDISKFS_DX_HASH_LEGACY hash
type is zero, I think we can disable that hash type
Joe Perches wrote:
On Mon, 2007-08-13 at 11:19 -0400, Theodore Tso wrote:
Yep, agreed.
OK. saved in my tree as
EXT4 FILE SYSTEM
P: Ted Ts'o
M:[EMAIL PROTECTED]
P:Eric Sandeen
M:[EMAIL PROTECTED]
Close... try [EMAIL PROTECTED], now :)
Andreas should still
F8 is catching opens with O_CREAT flags and no mode now, and refusing
to build them...
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: e2fsprogs-git/lib/ext2fs/ismounted.c
===
--- e2fsprogs-git.orig/lib/ext2fs/ismounted.c
Tried out Ted's git tree + all pending patches today, and
immediately oopsed on a mkdir thanks to this in
ext4_mb_new_group_pa()
BUG_ON(!S_ISREG(ac-ac_inode-i_mode));
(there are 54 BUGs and BUG_ONs in this file...!)
I think something like this patch is needed?
Signed-off-by: Eric
Ugh, scratch that, taking out some other debugging printk's I had and I
see the oops again... guess I'll have to look more closely. :)
EXT4-fs: file extents enabled
EXT4-fs: mballoc enabled
EXT4-fs: mballoc: 0 blocks 0 reqs (0 success)
EXT4-fs: mballoc: 0 extents scanned, 0 goal hits, 0 2^N hits,
...!)
I think something like this patch is needed?
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: ext4.git/fs/ext4/extents.c
===
--- ext4.git.orig/fs/ext4/extents.c
+++ ext4.git/fs/ext4/extents.c
@@ -2535,7 +2535,10 @@ int
Andreas Dilger wrote:
(there are 54 BUGs and BUG_ONs in this file...!)
Yes, we like lots of assertions in our code, because it is exceedingly
complex to debug otherwise.
But wouldn't error recovery be a better choice? You could macro-ize it
to BUG for development purposes if you wanted, I
Jeffrey W. Baker wrote:
On Thu, 2007-08-30 at 13:57 -0500, Eric Sandeen wrote:
barrier seems to hurt badly on xfs, too. Note: barrier is off by
default on ext[34], so if you want apples to apples there, you need to
change one or the other filesystem's mount options. If your write cache
helpful. Applies to the bottom of the
patch stack - should some of these mballoc patches get rolled together by
now?
-Eric
Make checkpatch happier with mballoc.c
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: ext4.git/fs/ext4/mballoc.c
Andreas Dilger wrote:
On Aug 31, 2007 16:28 -0500, Eric Sandeen wrote:
Here's a patch for mballoc.c, to make checkpatch happier with it.
I was about as pedantic as I could be, except for a few things it
complained about which I just could not agree with. :)
I'm happy
Alex Tomas wrote:
Eric Sandeen wrote:
+/*
+ * default stripe size = 1MB
+ */
+#define MB_DEFAULT_STRIPE 256
agree, though seems we'd better make it blocksize-insensitive
Well, for now this isn't even used at *all* so might as well just remove it.
+static int mb_find_extent
any common cases and issuing new warnings...?
ThAnks!
-Eric
-
Convert asserts (BUGs) in dx_probe from bad on-disk data to recoverable
errors with helpful warnings. With help catching other asserts
from Duane Griffin [EMAIL PROTECTED]
Signed-off-by: Eric Sandeen
. With help catching other asserts
from Duane Griffin [EMAIL PROTECTED]
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Acked-by: Duane Griffin [EMAIL PROTECTED]
Index: linux-2.6.22-rc4/fs/ext3/namei.c
===
--- linux-2.6.22-rc4.orig/fs
Andrew Morton wrote:
Ted is dir_index maintainer ;)
That's a nice-looking bug report, btw. Thanks.
Begin forwarded message:
Date: Fri, 01 Jun 2007 13:01:07 +0900
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: ext3 dir_index causes an
Goswin von Brederlow wrote:
Eric Sandeen [EMAIL PROTECTED] writes:
Eric Sandeen wrote:
Andrew Morton wrote:
Ted is dir_index maintainer ;)
...
[1.] One line summary of the problem:
ext3 dir_index causes an error
I'm looking at this now, FWIW... pretty easy to reproduce on ppc64,
though
Andreas Dilger wrote:
@@ -141,6 +141,7 @@ struct dx_map_entry
{
u32 hash;
u32 offs;
+u32 size;
};
Hmm, there was something about the size of the dx_map_entry, because
it is actually built at the end of the target block, that we don't
want to make it too large.
Yep,
Andreas Dilger wrote:
On Sep 15, 2007 22:46 -0500, Eric Sandeen wrote:
* calculate the minimum rec_len when generating the map, vs.
just storing the current rec_len.
Well, we already do this when moving the entries, so in theory we
should do it when checking how many entries to move
-ext4 list, ext3 dir_index causes an error
Thanks to Andreas Dilger for discussing the problem solution with me.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: linux-2.6.22-rc4/fs/ext3/namei.c
===
--- linux-2.6.22-rc4.orig/fs
Eric Sandeen wrote:
The do_split() function for htree dir blocks is intended to split a
leaf block to make room for a new entry. It sorts the entries in the
original block by hash value, then moves the last half of the entries to
the new block - without accounting for how much space
We talked last week about needing a place to hold ext4 bugs, at least
eventually. There is now an ext4 category on bugzilla.kernel.org.
Should we send all unassigned bug traffic to this list? Otherwise,
individuals will need to have an account on the above bugzilla, and set
it to watch [EMAIL
filesystem. ...
Granted, asking for fsck of a bind mount in the fstab is a bit odd,
but it doesn't seem like it should stop the boot process if you make
this mistake.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: e2fsprogs-1.40.2/misc/fsck.c
Andreas Dilger wrote:
It isn't possible to build an e2fsprogs via make rpm on SuSE and have it
install cleanly, because they split out some of the libraries into separate
packages.
We've got the current patch to the .spec file, but I'm open to discussion
if it is more desirable to change
Theodore Tso wrote:
On Wed, Sep 19, 2007 at 03:20:14PM -0500, Eric Sandeen wrote:
An entry like this in /etc/fstab:
/foo /barext3bind,defaults 1 3
will stop boot, as fsck.ext3 tries to check it and fails:
e2fsck 1.40.2 (12-Jul-2007)
fsck.ext3: Is a directory while trying to open
be tried?
Finally, I'm curious, the utility ignores anything that's not a link,
regular file, or dir, but the kernel code doesn't have these checks.
Should it?
Comments?
Thanks,
-Eric
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Index: e2fsprogs-1.40.2/misc/chattr.c
Andreas Dilger wrote:
On Sep 19, 2007 20:41 -0500, Eric Sandeen wrote:
Andreas Dilger wrote:
It isn't possible to build an e2fsprogs via make rpm on SuSE and have it
install cleanly, because they split out some of the libraries into separate
packages.
We've got the current patch
Theodore Tso wrote:
On Mon, Sep 24, 2007 at 11:25:39AM +0200, Karel Zak wrote:
Nope, there isn't much rationale unless we also split out fsck, so
util-linux-ng is open for fsck :-)
It's something I'm considering, but at the moment I've got some higher
priority (ext4) work that I'm focusing
1 - 100 of 227 matches
Mail list logo
