On Monday 23 August 2004 19:37, Jari Ruusu wrote:
> David Gümbel wrote:
> > So, no - unfortunately the patch doesn't fix the problem for me with
> > 2.6.8.1, loop-AES-2.1c (and mregparm enabled, although that shouldn't
> > matter). Kernel bootup parameters were "elevator=cfq" (like in the
> > tests before), in case that is of any importance. Anyway, thank you,
> > Jari, for your efforts so far. If you have any other ideas, please let
> > me know.
>
> I have tried to reproduce these error, with these settings:
>
> - 1 KB and 4 KB soft block size file systems.
> - Various IDE disk 'hdparm -m ? /dev/hdd' values.
> - Different I/O elevators: as, cfq, deadline
> - Disk write cache on and off.
> - Repartitioned disk with different partition layouts.
> - Small and large writes to files.
> - Two gcc versions 2.95.4 and 3.3.2
> - regparm off and regparm=3
>
> I haven't tested all possible combinations of above, but so far I have
> been unable reproduce these errors.
OK, I've done some further testing: I now use 2.6.7 with loop-AES 2.1c (2.1b
previously), just to see if the new version of loop-AES together with the
old kernel made any difference. It doesn't, my machine is running all fine.
In addition, I meditated a bit about the bug's behavior, and came up with
the following (partly speculative) points:
* it seems to appear faster when the system is under load, e.g I'm compiling
stuff while working. As the partition affected is /home, on which the file
system remains quiet when compiling (using "emerge"), this does bnot
neccessarily mean much, but:
* a pretty certain way to trigger it is to fire up my KMail and work with
it. I have a 1.4 GB ~/Mail, with some pretty large folders, some in mbox
(e.g. inbox, 86 MB or an archive of older inbox contents, ~350 MB)), some
in maildir format. So maybe it's somehow linked to access to large files on
encrypted ext3, and/or a larger number of open files.
* my understanding of lines like
> Aug 23 18:33:08 [kernel] EXT3-fs error (device loop0): ext3_readdir:
> directory #783444 contains a hole at offset 4096
is that "directory #" refers to the inode number, so the dir causing
problems can be found using find -inum. If that assumption is correct, the
two dirs having "triggered" the problem are:
- my ~/downloads dir, lots of files, a number of subdirs, the place I
unpack and compile e.g. WINE in. Total size of 1.3 GB.
"find downloads/ | wc -l" says 23402
- ~/Mail/Spamverdacht/new, part of a maildir folder containing mail that
is consindered spam by my filters, for review. The dir is currently
empty, but I think when the errors occurred, at least one time it was
pretty full (about 4000 messages, i.e. about 4000 small files).
This does make some sense, as KMail is pretty good at triggering the
problem.
I haved looked through the kernel Changelog from 2.6.7 to 2.6.8.1 but I
didn't see anything that looked suspicious to me. Maybe the information of
the above paragraph can provide some starting points or some ideas.
Regards,
David
Attachment:
pgpaDqj2w3aOE.pgp
Description: PGP signature
