| To: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: REVIEW: Fix for incore extent corruption. |
| From: | Russell Cattelan <cattelan@xxxxxxxxxxx> |
| Date: | Fri, 19 Sep 2008 08:15:34 -0700 |
| Cc: | lachlan@xxxxxxx, xfs@xxxxxxxxxxx |
| In-reply-to: | <48D3456A.9090808@sandeen.net> |
| References: | <48D19A83.4040608@thebarn.com> <48D1CD46.4010104@sgi.com> <48D1DCD5.7040502@thebarn.com> <48D218AE.9090400@sgi.com> <48D2C97A.1070703@thebarn.com> <63352.131.252.241.230.1221776406.squirrel@sandeen.net> <48D2F795.3080104@sgi.com> <48D31B9A.1080803@sgi.com> <48D3456A.9090808@sandeen.net> |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Thunderbird 2.0.0.6 (Macintosh/20070728) |
Eric Sandeen wrote:
Lachlan McIlroy wrote:Once I started looking at the pattern of extent buffer reductions before and after calling compact_page/full I noticed even when we did a partial move the number of total buffers didn't go down. I suppose you could end up with the stars and moon lining up just right and you would do enough partial moves to free up a page. Since this is all incore buffers space we are talking about all these space optimizations are moot once the inode goes inactive and is flushed from cache. I can't really think of a situation where not doing partial extent moves is really going to create an issue but I might be missing something.
(FWIW, compact_full *does* get called reasonably frequently, but the memmove case is what's hard to hit...) |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: REVIEW: Fix for incore extent corruption., Russell Cattelan |
|---|---|
| Next by Date: | Re: Hello., Alexina Megameno |
| Previous by Thread: | Re: REVIEW: Fix for incore extent corruption., Eric Sandeen |
| Next by Thread: | Re: REVIEW: Fix for incore extent corruption., Lachlan McIlroy |
| Indexes: | [Date] [Thread] [Top] [All Lists] |