Re: [PATCH] EXT3 extents against 2.6.0-test7
From: Ed Sweetman
Date: Fri Oct 17 2003 - 16:22:51 EST
Alex Tomas wrote:
On Fri, 17 Oct 2003 16:13:51 -0400
Ed Sweetman <ed.sweetman@xxxxxxxxx> wrote:
How am i supposed to know which directory in the fs this corruption
takes place in? I can tell you the size of the partitions that have
extents enabled, From that error message i dont even know which
partition it was. And judging by the dmesg last modified time, this
happened 2 days ago
OK. the question wasn't clear.
1) could you _estimate_ max directory size or number of entries in single
directory on your filesystems, please? had you large directories?
100, 300, 500 or more entries?
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.
outside of the two partitions with extents enabled though.... I'm not
sure if i have any seriously large directories in my other partitions.
And their inode size varies from 1KB to 4Kb depending on what type of
content they're expected to have .
2) did you use 2.6.0-test7+extents or some another patches?
The only other patches i have are related to fbdev and directfb.
Otherwise it's a vanilla 2.6.0-test7 + extents patch that you posted for it.
3) could you describe workload. knowing it I'd try to reproduce this
Workload on those partitions at the time? It cant be anything more than
mplayer reading a movie or writing a movie to disk. And the writes
would be at about 20MB/sec avg (ext3 to ext3 both with extents) from one
drive (the partitions happen to be on separate drives) to the other. The
transferrate spikes at 30MB/sec at start and stays at around 20MB/sec
for upwards up 1GB for a file.
Nothing else is done on those partitions. System wise though, what
caused the crash to occur was updatedb, which does a find on every
filesystem off of /. This is what was running when the error occured,
and it didn't happen this morning when it happened again, the error i
mean. I have dma enabled so updatedb doesn't cause significant
schedular issues due to cpu usage. That's all that was going on at the
time.
Isn't it possible though that this happened in one of the non-extents
enabled partitions though? Since they still have the ability to read
extents in files, they have to try and look them up every time for
everything dont they? Anyways, the two partitions above are the only
ones i actually enable extents on.
extents take place only if flag in inode->i_flags is set. that flag can
be set only during inode creation on extents-enabled filesystem.
with best wishes, Alex
-
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/