> Ok, here's the patch which changes it: it tries to alocate indirect
> blocks close to each other. This speeds up fsck 2 times and rm 3
> times, but may slow down other operations. Still it may be good idea
> when your critical server takes 4 hours to fsck.
>
> Please, take a look at this patch. I'm interested in two things:
>
> *) can patch like this cause data loss?
>
> *) is there any way to make this more efficient? It currently
> allocates indirect blocks closer to each other, but I feel it could do
> _much_ better.
As I posted earlier, I use 4k filesystems and get 1/2 the fsck times
that I do with 1k blocks. I applied the patch to 2.3.4, recompiled,
sync'd and powered the machine down. fsck on the root fs was 89 sec. I
ran the script to relocate all the files, sync'd and powered down. fsck
on root took 61 sec. So the combination of 4k blocks and your patch
results in a 3 fold improvement. I went from 3 min to 1 minute, and if
you count my other filesystems that would be more like 9 min to 3 min.
This is very nice. No signs of fs corruption yet. You mentioned that
this could hurt the performance of other filesystem operations. Can you
elaborate on that?
As drives get larger and larger, fsck times are going to become a bigger
issue. Can't wait for ext3 but if I don't run into a show stopper, this
will be a standard patch for me, whether or not it gets included into
the official kernel.
Thanks,
Steve ("I hate waiting for fscks") Bergman
-Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/