Re: [PATCH] EXT3 extents against 2.6.0-test7

From: Ed Sweetman
Date: Fri Oct 17 2003 - 19:08:54 EST


Alex Tomas wrote:
On Fri, 17 Oct 2003 17:22:05 -0400
Ed Sweetman <ed.sweetman@xxxxxxxxx> wrote:


none of my directories have more than 60 or so entries. I keep everything very organized on my hdds. The largest directories would be the ones holding the largest files but that maxes out at around 60 file entries. i formatted those partitions with a 4KB inode size.


oh. this seems very confusing for me. extents crashed during readdir() syscall.
4k block may contain upto 60 entries with 60chars length. even if your dir was
larger I don't think it was >16k. so, I really do believe all the extents were
placed in inode body (zero tree depth). also, directory grows in linear manner
only. so, this code patch is very very simple and quite good tested. thus it really seems like a corruption, not an error in logic. let me cook a patch that
will show more info.

also, it's very interesting how is it difficult to reproduce on your box?

thanks!

--
with best regards, Alex
-

I've been getting dma errors and rtc irq's being missed since moving to test7. I'm really not impressed with it at all. Whatever happened between it and andrew morton's 4th patch to test4 really sucked things up with the kernel. I'm getting zombie processes now that access the filesystem (non-extent partitions). I'm inclined to believe that there is corruption, but i really have no idea where it's coming from. Too many things have been patched at the same time to get a feel for which one could be causing the problem. Andrew Morton's branch has been nicer to me than linus's for a while so i'm gonna go and patch to that one. Even if i wanted to stop using extents, It would be really hard to since i've already started using it and the process is not reversable....or is it?


Would i reverse the effect of using extents by copying a file that was written when extents were enabled to another location and then back again with all partitions mounted with extents not enabled but supported by the patch? Would i be able to fsck the partition without fear of fsck completely destroying the partition? and my other ones too for that matter.

has there been an ata commit or something?


And it's not so much that it's hard to replicate it's that the processes that cause it zombify and dont usually allow the program to be run a second time due to it still holding locks.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/