Re: Reducing memory requirements for high extent xfs files

[Vlad Apostolov <vapo@sgi.com>]

David Chinner wrote:
> On Tue, Jun 05, 2007 at 03:23:50PM -0700, Michael Nishimoto wrote:
>   
>> David Chinner wrote:
>>     
>>> On Wed, May 30, 2007 at 09:49:38AM -0700, Michael Nishimoto wrote:
>>>       
>>>> Hello,
>>>>
>>>> Has anyone done any work or had thoughts on changes required
>>>> to reduce the total memory footprint of high extent xfs files?
>>>>         
> .....
>   
>>> Yes, it could, but that's a pretty major overhaul of the extent
>>> interface which currently assumes everywhere that the entire
>>> extent tree is in core.
>>>
>>> Can you describe the problem you are seeing that leads you to
>>> ask this question? What's the problem you need to solve?
>>>       
>> I realize that this work won't be trivial which is why I asked if anyone
>> has thought about all relevant issues.
>>
>> When using NFS over XFS, slowly growing files (can be ascii log files)
>> tend to fragment quite a bit.
>>     
>
> Oh, that problem.
>
> The issue is that allocation beyond EOF (the normal way we prevent
> fragmentation in this case) gets truncated off on file close.
>
> Even NFS request is processed by doing:
>
> 	open
> 	write
> 	close
>
> And so XFS truncates the allocation beyond EOF on close. Hence
> the next write requires a new allocation and that results in
> a non-contiguous file because the adjacent blocks have already
> been used....
>
> Options:
>
> 	- NFS server open file cache to avoid the close.
> 	- add detection to XFS to determine if the called is
> 	  an NFS thread and don't truncate on close.
> 	- use preallocation.
> 	- preallocation on the file once will result in the
> 	  XFS_DIFLAG_PREALLOC being set on the inode and it
> 	  won't truncate on close.
> 	- append only flag will work in the same way as the
> 	  prealloc flag w.r.t preventing truncation on close.
> 	- run xfs_fsr
>
> Note - i don't think extent size hints alone will help as they
> don't prevent EOF truncation on close.
>   
Dave,

I think extent hint should help in this situation. Here is an example
of writing 4 chars in a file with extent hint of 16Kb. The file ends
up with size of 4 and 8 basic blocks (512 bytes each) allocation in
one extent.

emu:/mnt/scratch1/temp # xfs_io -c "extsize 16384" -f foo
emu:/mnt/scratch1/temp # ls -al foo
-rw------- 1 root root 0 2007-06-06 12:33 foo
emu:/mnt/scratch1/temp # xfs_bmap -l -v foo
foo: no extents
emu:/mnt/scratch1/temp # echo "abc" > foo
emu:/mnt/scratch1/temp # ls -al foo
-rw------- 1 root root 4 2007-06-06 12:35 foo
emu:/mnt/scratch1/temp # xfs_bmap -l -v foo
foo:
 EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL
   0: [0..7]:          326088..326095    0 (326088..326095)     8

Just a warning that the extent hint works at the moment only for
contiguous files. There are problems for sparse files (with holes)
and extent hint.

Regards,
Vlad