"A month of sundays ago ptb wrote:" > I agree. I modified the bitmap so that when a page can't be got to make > a mark on, then we count pending "writes" by summing one to a count > for every attempted write to the zone covered by the missing page > and subtracting one for every attempted clear. > > The bitmap reports "dirty" if the count is positive and the page for > that zone is absent. I put the present code up at > > ftp://oboe.it.uc3m.es/pub/Programs/fr1-2.6.tgz And if anybody cares, I put up a fr1-2.7.tgz in which the bitmap also has a page cache so that it has a bit of leeway when asking for pages to put into the map. I think I put lo/hi water mark at 2/7 by default. That means it will preallocate 7 pages, and when 5 of those have been used up it will ask for 5 more, and keep them ready. But even if it can't get 5 more it will still serve the 2 it has in reserve. I still have to put in subzone pending-write counters (for 256KB subzones) for when the page alloc fails completely. At the moment the pending-write counter is for a page, which is a whole 4MB zone ondisk. When a page is completely cleared it disconnects itself from the bitmap and puts itself in the page cache, unless the cache is already at hiwater, when it will kfree itself instead. But I did let the bitmap "heal itself". If it tries to mark a page that was unable to be allocated in the past (because of lack of memory) and which now has no pending writes on it, then it will be attempted to be re-alloced. This may not be a good strategy - I can envisage that some time needs to pass before retrying. So, all in all, I guess things get more advanced. As usual when architecture improves, I took out large snips of code. Peter - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
