Re: Agressive selective pre-allocation

["Bruce A. Mallett" <bam@NightStorm.com>]

It seems to me that it would be better to have the file system keep 
track of this itself.  If the following is known about each file:
   original creation date
   current file size
   number of times extended
 
then it might be possible to compute a growth policy.  For example when 
extending a small file, just move and extend it.  As the file and 
extention frequencies increase then create larger new extents.

But the problem really is that apps don't actually "grow"these files but 
instead rebuilds them.  Thus the file system sees a request to open a 
new file and not to extend an existing one.  This would make tracking 
the above parameters way beyond difficult.



Ragnar Kjørstad wrote:

>Hi
>
>
>A lot of filesystems have files that grow slowly over time, and this is
>causing serious fragmentation, and thus performance-problems in some
>situations.
>
>A defragmentation-utility could potentially solve this, but maybe there
>is a better way?
>
>Some files, for instance MBOX-type mailboxes and logfiles, are known to
>the user/administrator to grow over time. It is possible to preallocate
>diskspace by creating large files with just zeroes in them, but this is
>not very flexible and requires the application to be awere.
>
>An alternative would be the possibility to tell the fs about the
>properties of the files. Maybe an ioctl to notify the fs that for this
>particular file the fs should allocate X blocks at the time? That would
>ensure that the files only get limited fragmentation and performance
>stays optimal.
>
>Does the metadata-format support blocks beeing allocated but not used
>yet? Is it sufficient to add them to the extent-map, mark them free,
>without changing the size of the file?
>
>An even better way would be to mark the blocks as "preallocated" without
>assigning them to the file. This would allow preallocation without
>actually locking the blocks - so if the disk went full the allocator
>could override the preallocation and use them for other data. 
>
>Blocks are managed in extents in reiserfs4, right? So I assume there is
>an extent-list for free blocks? So maybe one could add an extra
>extent-list for "preallocated blocks", and the change the allocator to
>search that list if, and only if, it is appending to file on the
>previous block or if there are no blocks in the free-list?
>
>
>I have no time to try to implement this right now, but I just got the
>idea and figgured I should write it down while fresh in memory. Any
>reason why this wouldn't work? 
>
>Personally I think fragmentation is one of the most serious
>performance-problems for filesystems, and this could potentially help a
>lot at least for the slow-growing files like logfiles and mboxes.
>
>
>
>  
>