50% more blocks allocated than needed

50% more blocks allocated than needed

[Thomas Habets]

Hi.

I've had some files on an XFS filesystem that use way
more blocks than they need.

That is, st_size=50MB and st_blocks*512= about 68MB.

The files were downloaded with wget on a somewhat unreliable 3G
connection (50-500kBps) and sometimes defragging (xfs_fsr) fixes it,
but
sometimes not.

If st_blocks*512<st_size then it could be sparse files, but this is
the opposite. So... preallocation?

"df" before and after deleting a bunch of these files shows that the
st_blocks is what it cares about. Would the preallocation (if that's
what it is) be reclaimed if the fs started to run out of space?

If not preallocation, then what?

Note st_blocks is 134656 and xfs_bmap shows 97663 blocks.

$ ls -l foo
-rw-r--r-- 1 root root 50000000 Jan 29 01:32 foo
$ du -h foo
66M foo
$ stat foo
  File: `foo'
  Size: 50000000   Blocks: 134656     IO Block: 4096   regular file
Device: fe04h/65028d Inode: 68688483    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-01-30 18:56:18.603278346 +0000
Modify: 2013-01-29 01:32:51.000000000 +0000
Change: 2013-01-31 11:38:10.892330145 +0000
 Birth: -
$ xfs_bmap foo
foo:
0: [0..97663]: 44665840..44763503

--
typedef struct me_s {
 char name[]      = { "Thomas Habets" };
 char email[]     = { "thomas@habets.pp.se" };
 char kernel[]    = { "Linux" };
 char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt" };
 char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE  0945 286A E90A AD48 E854" };
 char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: 50% more blocks allocated than needed

[Brian Foster]

On 01/31/2013 06:43 AM, Thomas Habets wrote:
> Hi.
> 
> I've had some files on an XFS filesystem that use way
> more blocks than they need.
> 
> That is, st_size=50MB and st_blocks*512= about 68MB.
> 
> The files were downloaded with wget on a somewhat unreliable 3G
> connection (50-500kBps) and sometimes defragging (xfs_fsr) fixes it,
> but
> sometimes not.
> 
> If st_blocks*512<st_size then it could be sparse files, but this is
> the opposite. So... preallocation?
> 

Yes, here's a thread (one of probably several examples) that discusses
the behavior and how the extra space is not permanent, but can hang
around for a bit:

http://oss.sgi.com/archives/xfs/2012-03/msg00145.html

> "df" before and after deleting a bunch of these files shows that the
> st_blocks is what it cares about. Would the preallocation (if that's
> what it is) be reclaimed if the fs started to run out of space?
> 

I don't think so at the moment, but preallocation is throttled as the
filesystem free space becomes more limited. We've recently added
speculative prealloc tracking that performs background trimming on a
timer controlled via:

/proc/sys/fs/xfs/speculative_prealloc_lifetime

... and can be used in the future to explicitly reclaim extra space
lying around when the filesystem is full.

Brian

> If not preallocation, then what?
> 
> Note st_blocks is 134656 and xfs_bmap shows 97663 blocks.
> 
> $ ls -l foo
> -rw-r--r-- 1 root root 50000000 Jan 29 01:32 foo
> $ du -h foo
> 66M foo
> $ stat foo
>   File: `foo'
>   Size: 50000000   Blocks: 134656     IO Block: 4096   regular file
> Device: fe04h/65028d Inode: 68688483    Links: 1
> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 2013-01-30 18:56:18.603278346 +0000
> Modify: 2013-01-29 01:32:51.000000000 +0000
> Change: 2013-01-31 11:38:10.892330145 +0000
>  Birth: -
> $ xfs_bmap foo
> foo:
> 0: [0..97663]: 44665840..44763503
> 
> --
> typedef struct me_s {
>  char name[]      = { "Thomas Habets" };
>  char email[]     = { "thomas@habets.pp.se" };
>  char kernel[]    = { "Linux" };
>  char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt" };
>  char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE  0945 286A E90A AD48 E854" };
>  char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
> } me_t;
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: 50% more blocks allocated than needed

[Stefan Ring]

> I don't think so at the moment

Really? Even for closed files? I was almost sure that the space would
be reclaimed before running out of it. I have only slightly less than
1 year of XFS experience though...

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: 50% more blocks allocated than needed

[Brian Foster]

On 01/31/2013 01:28 PM, Stefan Ring wrote:
>> I don't think so at the moment
> 
> Really? Even for closed files? I was almost sure that the space would
> be reclaimed before running out of it. I have only slightly less than
> 1 year of XFS experience though...
> 

Note that in most cases preallocation is trimmed on file close. The
repeated open-write-close cycle is what causes it to hang around longer
(until inode reclaim).

Somebody else can chime in if I'm missing something, but my
understanding is that we currently run a flush to free up reserved
metadata blocks on ENOSPC and retry. The eofblocks functionality
provides a mechanism that the out of space conditions can use to free up
preallocation, but that part is a work-in-progress.

Brian

> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs