On Tuesday 10 August 2004 16:35, Misty Stanley-Jones wrote:
Shuffling does not ensue as you say. The filesystem (most modern ones at least) are perfectly capable of dealing with non-contiguous files. Dynamic filesystems such as Reiser, VxFS (probably the free version too), and I do believe ext3 are perfectly capable of defragmenting themselves as files grow. You are also perfectly allowed to adjust the block size of your filesystem if you are very paranoid about running out of inodes due to many small files.
While this is true, it wasn't the question at issue. If you have a number of blocks B[1...1000], and file 1 uses blocks B[1...5] and file 2 uses blocks B[6...10] then to grow file 1 you can just start using block B[11] with - as you point out - no need to shuffle anything. As most (if not all) file systems, including FAT, is basically a linked list of file system blocks, all systems should be able to handle this. The problem here arises because reiserfs stores tails of multiple files in a single block. It may be my ignorance, but I thought reiserfs was alone in doing this. In this scheme B[19] could have the last 500 bytes of file 1 *and* the last 1003 bytes of file 2, instead of storing those two "tails" in separate blocks, wasting blocksize-500+blocksize-1003 bytes. Now, I haven't looked at the implementations of this in reiser , but if you grow file 1, while not absolutely necessary, it seems on first inspection like a good idea to move those 500 bytes to a fresh block and start from there. My point about the shuffling then was that all you would ever have to move around are blocksize-1 I agree that the fragmentation that is caused by growing files is handled so well by the file systems that it hardly ever becomes significant for performance, except in the most extreme cases