we found that just growing the file got us performance advantages. ben
On Wed, May 25, 2011 at 11:08 AM, Vishal Kher <[email protected]> wrote: > Hi, > > I am working on a fix for ZOOKEEPER-1069. > > While going through the Util.PadLogFile() method, it is not clear to me why > this method is really needed. It will be nice if someone can clarify its > advantage. > > > private static final ByteBuffer fill = ByteBuffer.allocateDirect(1); > [...] > /** > * Grows the file to the specified number of bytes. This only happenes > if > * the current file position is sufficiently close (less than 4K) to end > of > * file. > * > * @param f output stream to pad > * @param currentSize application keeps track of the cuurent file size > * @param preAllocSize how many bytes to pad > * @return the new file size. It can be the same as currentSize if no > * padding was done. > * @throws IOException > */ > public static long padLogFile(FileOutputStream f,long currentSize, > long preAllocSize) throws IOException{ > long position = f.getChannel().position(); > if (position + 4096 >= currentSize) { > currentSize = currentSize + preAllocSize; > fill.position(0); > f.getChannel().write(fill, currentSize-fill.remaining()); > } > return currentSize; > } > > > It looks like the method was intended to *allocate* disk blocks in advance > to a) try to get sequential allocation b) avoid allocation during writes. > But the method is not doing that. It is just growing the file size. What is > the advantage of that? It is not achieving any of the above advantages. > > What am I missing here? > > Thanks, > -Vishal >
