| 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. Brian > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs > |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 0/4 v2] Fix possible use after free with AIO, Joel Becker |
|---|---|
| Next by Date: | [PATCH] xfsdump: properly set Parent's PID, Carlos Maiolino |
| Previous by Thread: | Re: 50% more blocks allocated than needed, Stefan Ring |
| Next by Thread: | Пpopыв в Интеpнeт-Маркетинге, Кaк увеличить конверсию нa сайтe зa один мeсяц |
| Indexes: | [Date] [Thread] [Top] [All Lists] |