| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
Hi all, FYI, as mentioned in IRC meeting, I've stripped down and simplified a lot of the search stuff in blklist.c, and got it to work last night. It's a bit faster than the current code (saves 1 or more seconds in approx 30-second tar -xvzf linux-2.4.21.tar.gz), and much easier to understand. It always uses the AVL tree for random searches by block number, and tries to use rnum (rgrp index, i.e. which rgrp within the fs) via a pointer array, whenever possible (which is often). No linked list any more. I'm going to try it here a few more times, then check it in today if it keeps working well (even though the fs-full bug's not fixed yet). Using a small fs as a test bed is helpful. Tip o' the hat to Stefan's bug report on that. Remakes the fs in an instant, and easy to over-fill to test the fs behavior on that end. BTW, I keep thinking that there's no reason for more than a few hundred rgrps in a filesystem, at least in terms of cluster node contention, but I may not see the whole picture. Has anyone else thought about that? The only limitation that I can see is that current on-disk structures (ogfs_dinode, di_goal_* fields) limit the number of blocks *within a single rgrp* to being described by a 32-bit number. That's 4 GBlocks. 16 TBytes when using 4096-byte blocks. So 64 rgrps like that would give us 1 PByte, if my math is correct. -- Ben -- Opinions are mine, not Intel's
<<winmail.dat>>