Re: Agressive selective pre-allocation

["Ragnar Kjørstad" <reiserfs@ragnark.vestdata.no>]

On Tue, Dec 10, 2002 at 08:26:36AM +0100, Russell Coker wrote:
> Yes.  Or even files that grow rapidly.  Consider the case of an application 
> which creates 10 files and starts appending data to each of them in turn in 
> chunks of a few K (slapd does this).  Your file system will be 100% 
> fragmented if you don't do something smart about allocation.

allocate on flush should handle this pretty well, don't you think?
Unless the writes are syncrounous.

But yes, the same principle applies. Files that grow over time (large
number of independent writes) is probably more accurate than slow-growing 
files.

> > 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.
> 
> Another possibility is that you have a file system created for a specific data 
> type.  When I create a file system for an LDAP directory I know ahead of time 
> that I will have a small number of large files that are all growing slowly.  
> An option to the mkfs and tunefs programs to set this would do for me (and 
> it's easy to implement and get included in the kernel).  If I could set my 
> LDAP partitions to have disk space allocation in chunks of 4M then I'd be 
> happy.

That would work very well on things like logs - and it's probably a lot easier
to do than pr-file allocation policy.

> > 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?
> 
> You shouldn't need anything in the meta-data if you just do it in allocation 
> algorithms, every time you are about to grow a file and you can't grow it 
> contiguously then you search for a large free region.

Hmm, so still only allocate 1 block, but do it at a location that has a larger
region available?

> > 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.
> 
> mbox's aren't an issue, if you have them then you probably don't care too much 
> about performance anyway.

I know some that do, because some old mail-clients don't support maildir.


-- 
Ragnar Kjørstad