Re: reiser4: first impression (vs xfs and jfs)

[PFC <lists@peufeu.com>]

>>     Do the file copying programs open their output files with
>> O_SEQUENTIAL ?  If so, there is information to exploit...
>>
>>
> You can change them to do so....

	I rather meant : if a program opens a file for write with O_SEQUENTIAL  
(which should be done when copying files), will reiser4 exploit the  
information by flushing sooner, and in a more "streaming" fashion ? Or  
will it use the default algorithm, flushing under memory pressure ?

	The current behaviour of reiser4, flushing dirty pages late in case they  
are modified again before being written, is excellent for many use cases  
(random writes, small file writes, temporary files, copying files inside a  
single spindle etc) ; but it isn't optimal for writing large amounts of  
data in sequential fashion, like copying large files between disks, for  
instance. Adapting this would be quite tricky I guess...

	Consider the two following scenarios :

	- A database is doing an UPDATE query on a table. It will issue a lot of  
reads and writes, probably in random order. In this case, if the working  
set fits in RAM, it pays big time to flush as late as possible, ideally  
when the query is finished, because some pages may be written to multiple  
times. Also, delayed allocation will reduce fragmentation of the files.
	It's the same thing for doing a Make, unzipping an archive, copying many  
small files, etc.

	- A process acquires audio or video in realtime and streams it to disk,  
or copies files from one disk to another. In this case it is better to  
stream the data directly to disk, especially if the files are large.

	Guessing is a pain in the ass. How can the application inform the  
filesystem of its intentions ?