two problems using EXT3 htrees

two problems using EXT3 htrees

Post by Andrew_Purt.. » Thu, 10 Oct 2002 20:40:04



I recently patched my 2.4.19 kernel with EXT3 dir_index support and tried
it out on my 80GB EXT3 data partition. This partition is used to cache CVS
and BK checkouts from 17 or so different software projects, some of them
quite large (linux-kernel, GNOME2, and GNU src come to mind) and so it
contains thousands of directories and hundreds of thousands of files. I
serve this via NFS to a couple of clients. Using htrees on this file
system would seem to be a good idea in theory.

(First let me state that this kernel has also been patched with the
"International Kernel Patch" for 2.4.18 but I don't believe this patch
touches any of EXT3 or JBD.)

Setting the dir_index feature flag and running e2fsck -fD (1.30-WIP) went
without a hitch. However, my problems started almost immediately.

First, there is some interaction with knfsd and the nfsfs on the clients
(also 2.4.19) where a large directory can put the client into an endless
loop when iterating directory entries. I have an exported directory
that contains 849 Ogg Vorbis files that would lock 'ls' etc. every time.

Also, I encountered a problem when building GNOME2 using a script that
first unpacks a tarball of the module, does a CVS update, repacks the
updated module, then does a configure/build/install cycle, then removes
the working sources.

Intermittently this triggers a race where a file is deleted but the
directory metadata is not entirely updated, leading to a condition where a
file partially exists, e.g.

  # rm -rf some-large-project
  rm: some-large-project/CVS/Entries: Input/Ouput error.
  rm: some-large-project/CVS: Directory not empty.
  rm: some-large-project: Directory not empty.
  # cd some-large-project/CVS
  # ls
  Entries: Input/Output error.

I wrote a very simple utility that calls unlink() directly:

  # unlink Entries

This succeeds in clearing the bogus entry but EXT3 complains:

  kernel: EXT3-fs warning (device ide0(3,65)): ext3-unlink:
    Deleting nonexistent file (9012125), 0

Of these two problems the latter is only a nuisance but the former
rendered my NFS exports useless, so I had to revert the filesystem.
Clearing the dir_index feature flag and then running e2fsck did the trick.

If there is any additional information I can provide, please let me know.


Network Associates Technologies, Inc.                     Los Angeles, CA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

two problems using EXT3 htrees

Post by Daniel Phillip » Fri, 11 Oct 2002 15:20:04



Quote:> I recently patched my 2.4.19 kernel with EXT3 dir_index support and tried
> it out on my 80GB EXT3 data partition...

Could you please provide a pointer to the patch you used?

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

two problems using EXT3 htrees

Post by Andreas Dilge » Fri, 11 Oct 2002 19:10:08




> > I recently patched my 2.4.19 kernel with EXT3 dir_index support and tried
> > it out on my 80GB EXT3 data partition...

> Could you please provide a pointer to the patch you used?

A number of people have been getting this same bug under high load.  I
believe they are using the patches from Ted, and/or BK extfs.bkbits.net.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

two problems using EXT3 htrees

Post by Daniel Phillip » Fri, 11 Oct 2002 21:40:10





> > > I recently patched my 2.4.19 kernel with EXT3 dir_index support and tried
> > > it out on my 80GB EXT3 data partition...

> > Could you please provide a pointer to the patch you used?

> A number of people have been getting this same bug under high load.  I
> believe they are using the patches from Ted, and/or BK extfs.bkbits.net.

Does the Chris Lee flavor of the patch (before Ted's cleanups) exhibit the
same bug?  I suppose the pre-cleanup patch is incompatible with e2fsck
because of the hash function change, but that would be easy to fix.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

two problems using EXT3 htrees

Post by Daniel Phillip » Sat, 12 Oct 2002 02:10:06





> > > I recently patched my 2.4.19 kernel with EXT3 dir_index support and tried
> > > it out on my 80GB EXT3 data partition...

> > Could you please provide a pointer to the patch you used?

> A number of people have been getting this same bug under high load.  I
> believe they are using the patches from Ted, and/or BK extfs.bkbits.net.

OK, I've read through the patch and the original thread re this problem.
There are a few obvious things to try:

  - Does the problem come up when there is only one rsync running
    concurrently?  (If so, we have a SMP race.)

  - Is the behaviour the same before and after Ted's cleanups?  (Get
    the old version out of cvs...)

  - Does the problem manifest with Ext2?  (Somebody - me probably -
    has to dust off the Ext2 patch and add the new hash.)

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. ext3 htree brelse problems look to be fixed!

I just booted 2.5-bk current as of last night with the below patch1
(which was recently posted to ext3-users) that un-static-ifies a
struct dx_frame in namei.c.

I then did my best torture test for the brelse bug:  starting gnus
(3600+ nnmh folders2 with a total of XXX messages; it does a readdir
on each of those folders) while doing bk consistancy checks in 2.5
and/or 2.4 kernel trees.  All while fetchmail+procmail+spamd processes
a stream of incoming mail.

That load had never failed to generate a brelse in the syslog; each
occurance of brelse in the syslog correlated to a short readdir.  In
gnus the short readdir would result in temporarily missing mail; in bk
the consistancy check would fail.  If the bk check was the result of a
pull, a manual bk resync would be required to fix the tree.  (Or one
could remove the RESYNC and PENDING dirs and re-pull.)

The bug did not occur during the torture test.  Even with three bk
checks in parallel (2.5 current, 2.4 current and a clone of a clone of
2.5 as of yesterday.)

I beleive (with this patch) htree is now ready for prime time.

-JimC

2 one message per file in seq(1) order, ala old-style usenet spools


===== namei.c 1.15 vs edited =====
--- 1.15/fs/ext3/namei.c        Wed Oct  2 01:24:11 2002

        struct dx_hash_info hinfo;
        struct buffer_head *bh;
        struct ext3_dir_entry_2 *de, *top;
-       static struct dx_frame frames[2], *frame;
+       struct dx_frame frames[2], *frame;
        struct inode *dir;
        int block, err;
        int count = 0;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Attached Printer?

3. Corruption problem with ext3 and htree

4. This script don't work.

5. ext3 htree brelse problems look to be fixed!

6. pop3d for shadow passwords

7. Corruption problem with ext3 and htree

8. 7500 cdrom read errors on LinuxPPC CD?

9. Fix ext3 htree / NFS compatibility problems

10. VFS error in dmesg with ext3 htree

11. ext2/3 bugfix 4/6: Fix ext3 htree rename bug

12. [Bug 417] New: htree much slower than regular ext3