Jeff Breidenbach: > Thank you for the response. I suspect this is primarily an algorithm > issue. The aufs directory read takes about 1 minute if the SSD > directory has 10,000 files. It takes only 30 seconds if the SSD > directory has 5000 files. It takes 1 second if the SSD directory has > 100 files. Does aufs look at the read-only branch, once for every file > in the writable branch? If so, why?
Aufs readdir builds a memory block called VDIR (virtial or vertical directory), - create two hash lists, one for regular entries and the other for whiteouts. - readdir for the first (top) branch, and store the entires into one of hash lists, judging by its name. - readdir fot the next lower branch, and store the entries to hash lists with comparing the existing entires in the list. if the same named entry existed in one of the lists, then the entry on the lower branch will be discarded. I guess this comparison takes long time in your case. The hashing is divided by 32 currently. Because you have many entires, the value should be enlarged. If you can, try changing the value which is defind in fs/aufs/dir.h. #define AuSize_NHASH 32 // todo: changeable How about 1024, for your case? > I've attached the relevant part of /var/log/messages. Again, aufs > speeds up if I remove files from the SSD directory. I have not > rebooted. I don't know why the message was produced (it was not OOPS actually). It looks like there plenty of memory left in your system. J. R. Okajima ------------------------------------------------------------------------------
