On Wed, Jun 26, 2013 at 11:53:12AM -0700, Joseph D. Wagner wrote: > 1. Does not guarantee that memory will be available when ext4 needs > its. Memory might be available during this pre-check, but another > process might scoop it up between the pre-check and ext4's > allocation. This is the huge one. In some cases we might need to read potentially one or more disk blocks in the course of servicing the request. By the time we've read in the disk blocks, hundreds of milliseconds can have gone by. If there is a high speed network transfer coming in over the network, the networking stack can chew up a huge amount of memory surprisingly quickly (to say nothing of a JVM that might be starting up in parallel with reading in the allocation bitmaps, for example). This is also assuming we know in advance how much memory would be needed. Depending on how fragmented a file might be, the amount of memory required can vary significantly. And if the required metadata blocks are in memory, we won't know how much memory will be needed until we pull the necessary blocks into memory. The other problem with doing this is that the point at which we would do the check for the necessary memory is at the high-level portions of the ext4, and the places where we are doing the memory allocation are sometimes deep in the guts of ext4. So figuring this out would require some truly nasty abstraction violations. For the same reason, we can't just simply allocate the memory before we start the file system operation. There are places where we could do this, without doing severe violence to the surrounding code and without making things a total maintenance nightmare. But it's one of those things where we'd have to look at each place where we allocate memory and decide what's the best way to handle things. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
