[Top] [All Lists]

Re: 50% more blocks allocated than needed

To: Stefan Ring <stefanrin@xxxxxxxxx>
Subject: Re: 50% more blocks allocated than needed
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Thu, 31 Jan 2013 14:46:07 -0500
Cc: Linux fs XFS <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CAAxjCExedk+fWLpD1ypak9HK7b2domtc3aJuBRyEWsvXXsiSWA@xxxxxxxxxxxxxx>
References: <CA+kHd+eRifnCVkri6TPKS9UcUpBSW9nPnCEz0a412vO_Aw8=Xw@xxxxxxxxxxxxxx> <510AB2D5.2080600@xxxxxxxxxx> <CAAxjCExedk+fWLpD1ypak9HK7b2domtc3aJuBRyEWsvXXsiSWA@xxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
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.


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

<Prev in Thread] Current Thread [Next in Thread>